All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dipen Patel <dipenp@nvidia.com>
To: Rob Herring <robh@kernel.org>
Cc: thierry.reding@gmail.com, jonathanh@nvidia.com,
	smangipudi@nvidia.com, linux-kernel@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-gpio@vger.kernel.org,
	linus.walleij@linaro.org, bgolaszewski@baylibre.com,
	warthog618@gmail.com, devicetree@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH v5 04/11] dt-bindings: Add HTE bindings
Date: Wed, 6 Apr 2022 18:40:45 -0700	[thread overview]
Message-ID: <35e1a5da-a35a-cbaa-f70b-44c2f98c63ac@nvidia.com> (raw)
In-Reply-To: <YkRtzJjHQvmYNlK8@robh.at.kernel.org>


On 3/30/22 7:48 AM, Rob Herring wrote:
> On Tue, Mar 29, 2022 at 05:19:10PM -0700, Dipen Patel wrote:
>> Hi,
>>
>> On 3/29/22 4:25 PM, Rob Herring wrote:
>>> On Mon, Mar 28, 2022 at 10:45:14PM -0700, Dipen Patel wrote:
>>>> Introduces HTE devicetree binding details for the HTE subsystem. It
>>>> includes examples for the consumers, binding details for the providers
>>>> and specific binding details for the Tegra194 based HTE providers.
>>>>
>>>> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
>>>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>>> ---
>>>> Changes in v2:
>>>> - Replace hte with hardware-timestamp for property names
>>>> - Renamed file
>>>> - Removed example from the common dt binding file.
>>>>
>>>> Changes in v3:
>>>> - Addressed grammatical errors.
>>>> - Removed double plural from the respective properties.
>>>> - Added dual license.
>>>> - Prefixed "nvidia" in nvidia specific properties.
>>>>
>>>> Changes in v4:
>>>> - Corrected make dt_binding_check error.
>>>>
>>>> Changes in v5:
>>>> - Addressed review comments.
>>>>
>>>>  .../hte/hardware-timestamps-common.yaml       | 29 +++++++
>>>>  .../devicetree/bindings/hte/hte-consumer.yaml | 43 ++++++++++
>>>>  .../bindings/hte/nvidia,tegra194-hte.yaml     | 82 +++++++++++++++++++
>>>>  3 files changed, 154 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/hte/hardware-timestamps-common.yaml
>>>>  create mode 100644 Documentation/devicetree/bindings/hte/hte-consumer.yaml
>>>>  create mode 100644 Documentation/devicetree/bindings/hte/nvidia,tegra194-hte.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/hte/hardware-timestamps-common.yaml b/Documentation/devicetree/bindings/hte/hardware-timestamps-common.yaml
>>>> new file mode 100644
>>>> index 000000000000..e8a69ceccd56
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/hte/hardware-timestamps-common.yaml
>>>> @@ -0,0 +1,29 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fhte%2Fhardware-timestamps-common.yaml%23&amp;data=04%7C01%7Cdipenp%40nvidia.com%7C0e094f6ae7b642c970f308da125c64d4%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637842485301457320%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4UcTV375zNF44HeIpQcDV%2Bp3VJXdtjomZYGWWsUJf%2FA%3D&amp;reserved=0
>>>> +$schema: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23&amp;data=04%7C01%7Cdipenp%40nvidia.com%7C0e094f6ae7b642c970f308da125c64d4%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637842485301457320%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=fGoLuKpVFMNOsh%2BbJ6dLhpky63Y6zQ1oNkiOHDQ%2Bud0%3D&amp;reserved=0
>>>> +
>>>> +title: Hardware timestamp providers
>>>> +
>>>> +maintainers:
>>>> +  - Dipen Patel <dipenp@nvidia.com>
>>>> +
>>>> +description:
>>>> +  Some devices/SoCs have hardware time stamping engines which can use hardware
>>>> +  means to timestamp entity in realtime. The entity could be anything from
>>>> +  GPIOs, IRQs, Bus and so on. The hardware timestamp engine (HTE) present
>>>> +  itself as a provider with the bindings described in this document.
>>>> +
>>>> +properties:
>>>> +  $nodename:
>>>> +    pattern: "^hardware-timestamp(@.*|-[0-9a-f])?$"
>>>> +
>>>> +  "#hardware-timestamp-cells":
>>>> +    description:
>>>> +      Number of cells in a HTE specifier.
>>>> +
>>>> +required:
>>>> +  - "#hardware-timestamp-cells"
>>>> +
>>>> +additionalProperties: true
>>>> diff --git a/Documentation/devicetree/bindings/hte/hte-consumer.yaml b/Documentation/devicetree/bindings/hte/hte-consumer.yaml
>>>> new file mode 100644
>>>> index 000000000000..be69f63aa8c3
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/hte/hte-consumer.yaml
>>>> @@ -0,0 +1,43 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fhte%2Fhte-consumer.yaml%23&amp;data=04%7C01%7Cdipenp%40nvidia.com%7C0e094f6ae7b642c970f308da125c64d4%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637842485301457320%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=E3fspCvDDE5%2F6opK%2FdtpaY5%2FscsPURvDV7O7%2B%2FdbtEQ%3D&amp;reserved=0
>>>> +$schema: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23&amp;data=04%7C01%7Cdipenp%40nvidia.com%7C0e094f6ae7b642c970f308da125c64d4%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637842485301457320%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=fGoLuKpVFMNOsh%2BbJ6dLhpky63Y6zQ1oNkiOHDQ%2Bud0%3D&amp;reserved=0
>>>> +
>>>> +title: HTE Consumer Device Tree Bindings
>>>> +
>>>> +maintainers:
>>>> +  - Dipen Patel <dipenp@nvidia.com>
>>>> +
>>>> +select: true
>>>> +
>>>> +description:
>>>> +  HTE properties should be named "hardware-timestamps". The exact meaning of
>>>> +  each hardware-timestamps property must be documented in the device tree
>>> The meaning of the cells needs to be documented. You are documenting the 
>>> meaning of 'hardware-timestamps' here.
>> This is for the consumer side, meaning of the cells will be documented in the provider
>>
>> binding document.
> Right cells are opaque to the consumer. What bothered me is 
> hardware-timestamps already has an 'exact meaning'. You need to me more 
> exact as to what should be documented. We don't want what 
> 'hardware-timestamps' is described again. What needs to be documented is 
> how many entries, what each entry is (for the consumer), and the order.
>
>
>>>> +  binding for each device. An optional property "hardware-timestamp-names" may
>>>> +  contain a list of strings to label each of the HTE devices listed in the
>>>> +  "hardware-timestamps" property.
>>>> +
>>>> +properties:
>>>> +  hardware-timestamps:
>>> I'm wondering if we should just drop 'hardware'. What other kind of 
>>> timestamps are we going to have in DT? software-timestamps? No.
>> I believe this makes it explicit and leaves no room for second guess. If
>>
>> only timestamps, ambiguity then will be which timestamp it is i.e. through hardware
>>
>> engine, pps, ptp and so on...
> Those aren't hardware timestamps, too? If those needed a similar 
> binding, couldn't they use this binding? PTP at least is sometimes an 
> separate, external chip IIRC.

I am fine with this idea of dropping "hardware" prefix, will update the patch.

I believe this will be applicable to all other properties for example hardware-timestamp-cell

as well, right?

>
> Rob

  reply	other threads:[~2022-04-07  1:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29  5:45 [PATCH v5 00/11] Intro to Hardware timestamping engine Dipen Patel
2022-03-29  5:45 ` [PATCH v5 01/11] Documentation: Add HTE subsystem guide Dipen Patel
2022-03-29 13:16   ` Bagas Sanjaya
2022-03-29 15:27     ` Jonathan Corbet
2022-03-29 22:38       ` Dipen Patel
2022-03-29 22:36     ` Dipen Patel
2022-03-29  5:45 ` [PATCH v5 02/11] drivers: Add hardware timestamp engine (HTE) Dipen Patel
2022-03-29  5:45 ` [PATCH v5 03/11] hte: Add tegra194 HTE kernel provider Dipen Patel
2022-03-29  5:45 ` [PATCH v5 04/11] dt-bindings: Add HTE bindings Dipen Patel
2022-03-29 23:25   ` Rob Herring
2022-03-30  0:19     ` Dipen Patel
2022-03-30 14:48       ` Rob Herring
2022-04-07  1:40         ` Dipen Patel [this message]
2022-03-29  5:45 ` [PATCH v5 05/11] hte: Add Tegra194 IRQ HTE test driver Dipen Patel
2022-03-29  5:45 ` [PATCH v5 06/11] gpiolib: Add HTE support Dipen Patel
2022-03-29  5:45 ` [PATCH v5 07/11] gpio: tegra186: Add HTE in gpio-tegra186 driver Dipen Patel
2022-03-29  5:45 ` [PATCH v5 08/11] gpiolib: cdev: Add hardware timestamp clock type Dipen Patel
2022-03-29  5:45 ` [PATCH v5 09/11] tools: gpio: Add new hardware " Dipen Patel
2022-03-29  5:45 ` [PATCH v5 10/11] hte: Add tegra GPIO HTE test driver Dipen Patel
2022-03-29  5:45 ` [PATCH v5 11/11] MAINTAINERS: Added HTE Subsystem Dipen Patel
2022-04-19 22:46 ` [PATCH v5 00/11] Intro to Hardware timestamping engine Linus Walleij
2022-04-20 13:47   ` Thierry Reding
2022-04-20 21:23     ` Linus Walleij
2022-04-22 22:52   ` Dipen Patel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35e1a5da-a35a-cbaa-f70b-44c2f98c63ac@nvidia.com \
    --to=dipenp@nvidia.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=smangipudi@nvidia.com \
    --cc=thierry.reding@gmail.com \
    --cc=warthog618@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.