Netdev List
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Imran Shaik <imran.shaik@oss.qualcomm.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Richard Cochran <richardcochran@gmail.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>
Cc: Ajit Pandey <ajit.pandey@oss.qualcomm.com>,
	Taniya Das <taniya.das@oss.qualcomm.com>,
	Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 1/6] dt-bindings: ptp: Document the TSCSS on Qualcomm Lemans and Monaco SoCs
Date: Tue, 27 Oct 2026 16:19:38 +0100	[thread overview]
Message-ID: <8fdc66b2-6047-4f3d-932f-1e6883e370bc@kernel.org> (raw)
In-Reply-To: <237b2f74-4a9b-4df2-a0fe-a7b783ed5267@oss.qualcomm.com>

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.


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


Best regards,
Krzysztof

  reply	other threads:[~2026-10-27 15:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27 14:10 [PATCH 0/6] Add support for Qualcomm TSCSS hardware Imran Shaik
2026-07-27 14:10 ` [PATCH 1/6] dt-bindings: ptp: Document the TSCSS on Qualcomm Lemans and Monaco SoCs Imran Shaik
2026-07-27 15:50   ` Krzysztof Kozlowski
2026-09-01  6:31     ` Imran Shaik
2026-09-01  6:40       ` Krzysztof Kozlowski
2026-10-13 11:49         ` Imran Shaik
2026-10-23  9:39           ` Krzysztof Kozlowski
2026-10-26 12:55             ` Imran Shaik
2026-10-27 15:19               ` Krzysztof Kozlowski [this message]
2026-07-27 14:10 ` [PATCH 2/6] dt-bindings: ptp: Document TSCSS hardware on Qualcomm QDU1000 SoC Imran Shaik
2026-07-27 15:51   ` Krzysztof Kozlowski
2026-09-01  6:31     ` Imran Shaik
2026-07-27 14:10 ` [PATCH 3/6] ptp: qcom: Add PTP driver for the Qualcomm TSC hardware Imran Shaik
2026-07-27 15:53   ` Krzysztof Kozlowski
2026-07-30 10:58     ` Imran Shaik
2026-07-27 23:20   ` Jakub Kicinski
2026-07-30 10:56     ` Imran Shaik
2026-07-27 14:11 ` [PATCH 4/6] arm64: defconfig: Enable Qualcomm TSC driver Imran Shaik
2026-07-27 14:11 ` [PATCH 5/6] arm64: dts: qcom: lemans: Add support for TSCSS node Imran Shaik
2026-07-27 14:44   ` Konrad Dybcio
2026-09-01  6:41     ` Imran Shaik
2026-09-02 15:58       ` Konrad Dybcio
2026-07-27 14:11 ` [PATCH 6/6] arm64: dts: qcom: qdu1000: " Imran Shaik
2026-07-27 15:54   ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8fdc66b2-6047-4f3d-932f-1e6883e370bc@kernel.org \
    --to=krzk@kernel.org \
    --cc=ajit.pandey@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=imran.shaik@oss.qualcomm.com \
    --cc=jagadeesh.kona@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    --cc=robh@kernel.org \
    --cc=taniya.das@oss.qualcomm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox