On Thu, Nov 03, 2022 at 10:45:20AM -0700, Dipen Patel wrote: > Added timestamp provider support for the Tegra234 in devicetree > bindings. > > Signed-off-by: Dipen Patel <dipenp@xxxxxxxxxx> > --- > .../timestamp/nvidia,tegra194-hte.yaml | 44 +++++++++++++++++-- > 1 file changed, 40 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml > index c31e207d1652..158dbe58c49f 100644 > --- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml > +++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml > @@ -4,7 +4,7 @@ > $id: http://devicetree.org/schemas/timestamp/nvidia,tegra194-hte.yaml# > $schema: http://devicetree.org/meta-schemas/core.yaml# > > -title: Tegra194 on chip generic hardware timestamping engine (HTE) > +title: Tegra on chip generic hardware timestamping engine (HTE) provider > > maintainers: > - Dipen Patel <dipenp@xxxxxxxxxx> > @@ -23,6 +23,8 @@ properties: > enum: > - nvidia,tegra194-gte-aon > - nvidia,tegra194-gte-lic > + - nvidia,tegra234-gte-aon > + - nvidia,tegra234-gte-lic How is the h/w in this chip different from the existing one? I'm assuming it must be because you don't have a fallback compatible. > > reg: > maxItems: 1 > @@ -43,9 +45,8 @@ properties: > description: > HTE lines are arranged in 32 bit slice where each bit represents different > line/signal that it can enable/configure for the timestamp. It is u32 > - property and depends on the HTE instance in the chip. The value 3 is for > - GPIO GTE and 11 for IRQ GTE. > - enum: [3, 11] > + property and the value depends on the HTE instance in the chip. If this statement was true, then this property makes sense... > + enum: [3, 11, 17] > > '#timestamp-cells': > description: > @@ -55,6 +56,41 @@ properties: > mentioned in the nvidia GPIO device tree binding document. > const: 1 > > +allOf: > + - if: > + properties: > + compatible: > + contains: > + enum: > + - nvidia,tegra194-gte-aon > + - nvidia,tegra234-gte-aon > + then: > + properties: > + nvidia,slices: > + const: 3 > + > + - if: > + properties: > + compatible: > + contains: > + enum: > + - nvidia,tegra194-gte-lic > + then: > + properties: > + nvidia,slices: > + const: 11 > + > + - if: > + properties: > + compatible: > + contains: > + enum: > + - nvidia,tegra234-gte-lic > + then: > + properties: > + nvidia,slices: > + const: 17 However, if there is only one possible value for each compatible, then being per instance can't really be true. I guess 'aon' or 'lic' define the instance? That's not normal practice. Are there other differences? It seems like 'nvidia,slices' should be implied from the compatible string. Rob