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

[Imran Shaik]

On 23-10-2026 03:09 pm, Krzysztof Kozlowski wrote:
> On 13/10/2026 13:49, Imran Shaik wrote:
> > > > > > +
> > > > > > +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.
>
> Just drop both pinctrl properties, because you should not need them. You
> define them only if they are different than default.

Thanks for the feedback, will drop this in next series.

> > > 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
>
> That's like 13 years old device binding, so unfortunately likely
> antipattern.
>
>
>
> > 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.
>
> etu-slice does not feel like device at all unfortunately. I see only
> address space, so one resource, which might be enough but lack of
> description for the subnode is not helping. I have doubts that separate
> subnodes should be there in the first place, but if they stay, describe
> the child node fully - what sort of device it is. Just because there is
> independent timestamping counter does not make it separate device, just
> like independent interrupt in GIC is not itself an independent device.

The ETU is an independent hardware block within TSCSS that captures/
snapshots the TSC timestamp in response to an external hardware
event trigger, for each slice individually. Hence the subnodes approach
was followed and will capture these details in the description as well.

If we drop the subnodes and add everything into the parent TSCSS node
instead, then all the arrays here must stay index aligned as per slice
mapping. Example DTS node looks like this (QDU1000, 3 slices):

ptp@1da0000 {
	compatible = "qcom,qdu1000-tscss";
	reg = <0x0 0x01da0000 0x0 0x2000>,
	      <0x0 0x01db0000 0x0 0x10000>;
	reg-names = "tsc", "etu";
	
	...

	interrupts = <GIC_SPI 329 IRQ_TYPE_EDGE_RISING>,
		     <GIC_SPI 333 IRQ_TYPE_EDGE_RISING>,
		     <GIC_SPI 334 IRQ_TYPE_EDGE_RISING>;
	interrupt-names = "slice1", "slice5", "slice6";
	
	pinctrl-0 = <&tod_pps>;
	pinctrl-1 = <&gps_pps>;
	pinctrl-2 = <&hardsync_pps>;
	pinctrl-names = "slice1", "slice5", "slice6";
	
	qcom,etu-slice = <1 5 6>;
	qcom,etu-event-sel = <1 3 2>;
};

Please help suggest which approach to follow here. Accordingly, I will
update the bindings in next series.

Thanks,
Imran