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

[Imran Shaik <imran.shaik@oss.qualcomm.com>]

On 27-10-2026 08:49 pm, Krzysztof Kozlowski wrote:
> On 26/10/2026 13:55, Imran Shaik wrote:
>>>
>>>>
>>>> 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/
> 
> How is it independent? I see no resources, except address space. A
> channel of some device does not mean it is a separate device.
> 

Sure, got it.

> 
>> 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>;
> 
> Why this is not continuous? The slices are all fixed in the hardware. I
> don't get why do you list some of them.
> 

The slices are fixed and contiguous in hardware (e.g. QDU1000 has 16 ETU
slices, 0-15), and accordingly will describe the bindings. But based on
vendor/target board requirements, the slice configuration can use all 16
or only a few, and might not be continuous.

If the board requirement is to get the external hardware event sourced
via certain GPIOs based on the availability, then accordingly, the ETU
slice and respective event sel needs to be configured. In the example,
slice 1, 5 and 6 are used to route TOD PPS, GPS PPS and hardsync PPS
pins respectively on QDU1000 SoC, and the remaining slices are not used.

Thanks,
Imran