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@xxxxxxxxxx> > >> Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > >> --- > >> 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&data=04%7C01%7Cdipenp%40nvidia.com%7C5793b3be05fd48a97ad108da11db79a7%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637841931589163420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oyeG06oNMukYew%2Bkji%2FlXsDyGwIIrIvwxLHKxaiFBto%3D&reserved=0 > >> +$schema: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=04%7C01%7Cdipenp%40nvidia.com%7C5793b3be05fd48a97ad108da11db79a7%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637841931589163420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JOY3MmZlMo6Mopr5dwjUky%2BaQX4b0QSiDt8zo3mSu1k%3D&reserved=0 > >> + > >> +title: Hardware timestamp providers > >> + > >> +maintainers: > >> + - Dipen Patel <dipenp@xxxxxxxxxx> > >> + > >> +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&data=04%7C01%7Cdipenp%40nvidia.com%7C5793b3be05fd48a97ad108da11db79a7%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637841931589319655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0f1FFB1IotZESaxDlXX5mo9YyMN25BlFAyq%2FOQJtVoE%3D&reserved=0 > >> +$schema: https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=04%7C01%7Cdipenp%40nvidia.com%7C5793b3be05fd48a97ad108da11db79a7%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637841931589319655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=B%2FvVGGwp9JghUpT33cGk0EZHDRlaOAzCbtv93Z%2Fa9YY%3D&reserved=0 > >> + > >> +title: HTE Consumer Device Tree Bindings > >> + > >> +maintainers: > >> + - Dipen Patel <dipenp@xxxxxxxxxx> > >> + > >> +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. Rob
