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

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

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