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-07-2026 09:20 pm, Krzysztof Kozlowski wrote:
> On 27/07/2026 16:10, Imran Shaik wrote:
>> Add Devicetree bindings for the Timestamp Counter Subsystem (TSCSS) found
>> on Qualcomm Lemans and Monaco SoCs.
>>
>> TSCSS is a time synchronization subsystem composed of two main blocks:
>> Timestamp Counter (TSC) and Event Timestamp Unit (ETU). The TSC block
>> provides a continuously running counter used for timekeeping, while the
>> ETU captures timestamps for external hardware event triggers.
>>
>> Co-developed-by: Taniya Das <taniya.das@oss.qualcomm.com>
>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
>> ---
>>   .../devicetree/bindings/ptp/qcom,lemans-tscss.yaml | 198 +++++++++++++++++++++
>>   1 file changed, 198 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/ptp/qcom,lemans-tscss.yaml b/Documentation/devicetree/bindings/ptp/qcom,lemans-tscss.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..4cbe4b00ff7dcacbd8cc111e2b4b61ebce7104aa
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ptp/qcom,lemans-tscss.yaml
>> @@ -0,0 +1,198 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/ptp/qcom,lemans-tscss.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Timestamp Counter Subsystem (TSCSS) on Qualcomm Lemans and Monaco SoCs
>> +
>> +maintainers:
>> +  - Imran Shaik <imran.shaik@oss.qualcomm.com>
>> +  - Taniya Das <taniya.das@oss.qualcomm.com>
>> +
>> +description: |
>> +  Qualcomm TSCSS is a time synchronization subsystem composed of two main
>> +  blocks - the Time Stamp Counter (TSC) and the Event Timestamp Unit (ETU).
>> +
>> +  The TSC block is a timestamp generator that maintains a running counter used
>> +  for system timekeeping, and is functional with just the AHB and counter
>> +  clocks.
>> +  The ETU block is optional and captures TSC timestamps for external
>> +  hardware events, each ETU slice binding a slice identifier to an external
>> +  event selector. Support for the ETU block requires the additional ETU
>> +  clock along with the summary interrupt and slice subnodes.
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - const: qcom,lemans-tscss
> 
> There is no such SoC upstream.
> 
> 
>> +      - items:
>> +          - const: qcom,monaco-tscss
> 
> Neither this one.
> 

Apologies for the late response.

Sure, will update the SoC names to sa8775p and qcs8300 respectively.

> 
>> +          - const: qcom,lemans-tscss
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  reg-names:
>> +    items:
>> +      - const: tsc
> 
> Drop names, not really useful.
> 

Sure, will drop in the next version.

>> +
> 
>> +  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.

>> +    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.

>> +
>> +  "#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.

>> +
>> +      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.

>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> +    required:
>> +      - reg
>> +      - qcom,etu-event-sel
>> +      - qcom,etu-slice
>> +      - pinctrl-0
>> +      - pinctrl-names
>> +    unevaluatedProperties: false
> 
> Please read writing bindings.
> 

Sure, will drop this and use additionalProperties.

>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - reg-names
>> +  - clocks
>> +  - clock-names
>> +
>> +allOf:
>> +  - if:
>> +      properties:
>> +        clock-names:
>> +          contains:
>> +            const: etu
> 
> etu is third clock, what is the point of it?
> 

As mentioned above the TSC clock can be functional individually. If we
need the ETU sub block to be functional, then we need the ETU clock. To
make the sub node properties mandatory, we are using the ETU clock to
distinguish.

>> +    then:
>> +      properties:
>> +        clocks:
>> +          minItems: 3
>> +        clock-names:
>> +          minItems: 3
>> +      required:
>> +        - interrupts
>> +        - interrupt-names
>> +        - "#address-cells"
>> +        - "#size-cells"
>> +        - ranges
>> +
>> +unevaluatedProperties: false
> 
> Please read writing bindings.

Sure, will drop this and use additionalProperties.

>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
>> +
>> +    soc {
>> +      #address-cells = <2>;
>> +      #size-cells = <2>;
>> +
>> +      tscss@1c80000 {
>> +        compatible = "qcom,lemans-tscss";
>> +        reg = <0x0 0x01c80000 0x0 0x2000>;
>> +        reg-names = "tsc";
>> +
>> +        clocks = <&gcc GCC_TSCSS_AHB_CLK>,
>> +                 <&gcc GCC_TSCSS_GLOBAL_CNTR_CLK>;
>> +        clock-names = "ahb", "cntr";
>> +
>> +        assigned-clocks = <&gcc GCC_TSCSS_GLOBAL_CNTR_CLK>;
>> +        assigned-clock-rates = <15625000>;
>> +      };
>> +    };
>> +
>> +  - |
>> +    #include <dt-bindings/clock/qcom,sa8775p-gcc.h>
>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +
>> +    soc {
>> +      #address-cells = <2>;
>> +      #size-cells = <2>;
>> +
>> +      tscss@1c80000 {
> 
> This is the same node as previous.
> 
> I don't understand this DTS.
> 

I kept two different examples with and without ETU slice sub nodes, as
TSC standalone block can be functional.

> 
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> If you cannot find a name matching your device, please check in kernel
> sources for similar cases or you can grow the spec (via pull request to
> DT spec repo).
> 

The recommended DT generic names, doesn't have the node names related to
PTP/PHC. I found that other existing DTS nodes has the ptp/ptp-timer/phc
naming convention used.

Please confirm if we can use the "ptp" name. Accordingly, I can raise
the PR to DT spec repo as well.

Thanks,
Imran