Re: [PATCH 1/6] dt-bindings: ptp: Document the TSCSS on Qualcomm Lemans and Monaco SoCs

[Imran Shaik]

On 01-09-2026 12:10 pm, Krzysztof Kozlowski wrote:
> On 01/09/2026 08:31, Imran Shaik wrote:
> > > > +  clocks:
> > > > +    minItems: 2
> > > > +    items:
> > > > +      - description: TSC AHB configuration clock.
> > > > +      - description: TSC global counter clock.
> > > > +      - description: TSC ETU clock.
> > > > +
> > > > +  clock-names:
> > > > +    minItems: 2
> > >
> > > Why is this flexible?
> >
> > Actually, the TSC block can standalone work without the ETU support as
> > well. This ETU clock is require only when we add the ETU slice sub
> > nodes. Hence, keeping the minItems to 2, excluding the ETU clock.
>
> Hardware either has them or not. Whether they are necessary to
> prepared/enabled is independent thing and job for the driver.

Sure, will drop that flexible logic.

> > > > +    items:
> > > > +      - const: ahb
> > > > +      - const: cntr
> > > > +      - const: etu
> > > > +
> > > > +  interrupts:
> > > > +    description: Summary interrupt raised based on external event for any of the ETU slices.
> > >
> > > Please follow Linux coding style.
> >
> > Sure, will update.
> >
> > > > +    maxItems: 1
> > > > +
> > > > +  interrupt-names:
> > > > +    items:
> > > > +      - const: etu_summary
> > > > +
> > > > +  assigned-clocks: true
> > > > +  assigned-clock-rates: true
> > >
> > > Drop. From where did you take it?
> >
> > Actually, we need these properties to be present in the DTS to take care
> > of the clock rate requirements.
> >
> > Please suggest on how to handle such requirements.
>
> Why does this binding has to be different than ALL other bindings in the
> kernel? I am not talking about DTS now.

Sure, will check and drop.

> > > > +
> > > > +  "#address-cells":
> > > > +    const: 2
> > > > +
> > > > +  "#size-cells":
> > > > +    const: 2
> > > > +
> > > > +  ranges: true
> > > > +
> > > > +patternProperties:
> > > > +  "^etu-slice@[0-9a-f]+$":
> > > > +    type: object
> > > > +    description: ETU slice configuration
> > > > +    properties:
> > > > +      reg:
> > > > +        maxItems: 1
> > > > +
> > > > +      pinctrl-0: true
> > > > +
> > > > +      pinctrl-names:
> > > > +        items:
> > > > +          - const: default
> > >
> > > Heh? Which code do you copy?
> >
> > Each ETU slice has its own external event pin config, so kept pinctrl-0
> > and pinctrl-names on the slice subnode. Please suggest if you prefer
> > otherwise.
>
> No, from where did you get this code? Why are you sending bindings which
> are different then all other bindings?

I was referring to the example in [1] when adding the pinctrl properties
under the etu-slice sub node.

[1] - 
Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml

On checking further, I found that our etu-slice sub node deviates from
that example, since we don't have a compatible string for the sub node.

Please let me know if we should move the pinctrl properties under the
tscss node with per-slice names, or instead keep them under the
etu-slice sub node and add a compatible there.

> > > > +
> > > > +      qcom,etu-event-sel:
> > > > +        description: Event selection value for this slice.
> > > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > > +
> > > > +      qcom,etu-slice:
> > > > +        description: ETU slice identifier.
> > >
> > > You do not get identifiers. Please read writing bindings.
> >
> > In general, any ETU slice can function with any ETU event sel, and this
> > might not be 1-1 always. Also, these ETU slices can be configured by the
> > vendors based on the requirements of the GPIOs on the board. Hence, this
> > etu-slice identifier will provide the flexibility to configure
> > accordingly.
>
> 'reg' defines which ETU slice is this, no?

Yes, will drop qcom,etu-slice property.

> Best regards,
> Krzysztof