[PATCH v2 0/2] Fix traceNoC probe issue on Kaanapali

[PATCH v2 0/2] Fix traceNoC probe issue on Kaanapali

[Jie Gan]

Patch 1 changes the binding to allow the TraceNoC device accepts
arm,primecell-periphid property.

Patch 2 fixes the deferred probe issue for the TraceNoC device by
adding the arm,primecell-periphid property to bypass the AMBA check.

Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v2:
- address the ATID issue reported by Sashiko.
- update binding to accept arm,primecell-periphid property.
- Link to v1: https://lore.kernel.org/r/20260624-fix-tracenoc-probe-issue-v1-1-bcc785198fc5@oss.qualcomm.com

---
Jie Gan (2):
      dt-bindings: arm: qcom,coresight-tnoc: allow arm,primecell-periphid
      arm64: dts: qcom: kaanapali: fix traceNoC probe issue

 Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml | 5 ++++-
 arch/arm64/boot/dts/qcom/kaanapali.dtsi                        | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260624-fix-tracenoc-probe-issue-c6429da28df4

Best regards,
-- 
Jie Gan <jie.gan@oss.qualcomm.com>

[PATCH v2 1/2] dt-bindings: arm: qcom,coresight-tnoc: allow arm,primecell-periphid

[Jie Gan]

The TNOC device is an AMBA primecell and may carry the standard
arm,primecell-periphid property, which is used to supply the
peripheral ID when it cannot be read from the device registers.

Reference primecell.yaml and set additionalProperties to true so the
binding accepts arm,primecell-periphid along with the other common
primecell properties.

Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
index ef648a15b806..9624fc0adfdc 100644
--- a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
@@ -32,6 +32,9 @@ select:
   required:
     - compatible
 
+allOf:
+  - $ref: /schemas/arm/primecell.yaml#
+
 properties:
   $nodename:
     pattern: "^tn(@[0-9a-f]+)$"
@@ -78,7 +81,7 @@ required:
   - in-ports
   - out-ports
 
-additionalProperties: false
+additionalProperties: true
 
 examples:
   - |

-- 
2.34.1

Re: [PATCH v2 1/2] dt-bindings: arm: qcom,coresight-tnoc: allow arm,primecell-periphid

[Krzysztof Kozlowski]

On Wed, Jun 24, 2026 at 05:49:25PM +0800, Jie Gan wrote:
> The TNOC device is an AMBA primecell and may carry the standard
> arm,primecell-periphid property, which is used to supply the
> peripheral ID when it cannot be read from the device registers.
> 
> Reference primecell.yaml and set additionalProperties to true so the
> binding accepts arm,primecell-periphid along with the other common
> primecell properties.
> 
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
> index ef648a15b806..9624fc0adfdc 100644
> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
> @@ -32,6 +32,9 @@ select:
>    required:
>      - compatible
>  
> +allOf:
> +  - $ref: /schemas/arm/primecell.yaml#
> +
>  properties:
>    $nodename:
>      pattern: "^tn(@[0-9a-f]+)$"
> @@ -78,7 +81,7 @@ required:
>    - in-ports
>    - out-ports
>  
> -additionalProperties: false
> +additionalProperties: true

Nope, it is not allowed. Explicitly mentioned in writing bindings and
all DT introductory talks by me.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: arm: qcom,coresight-tnoc: allow arm,primecell-periphid

[Jie Gan]

On 6/25/2026 3:24 PM, Krzysztof Kozlowski wrote:
> On Wed, Jun 24, 2026 at 05:49:25PM +0800, Jie Gan wrote:
>> The TNOC device is an AMBA primecell and may carry the standard
>> arm,primecell-periphid property, which is used to supply the
>> peripheral ID when it cannot be read from the device registers.
>>
>> Reference primecell.yaml and set additionalProperties to true so the
>> binding accepts arm,primecell-periphid along with the other common
>> primecell properties.
>>
>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>> ---
>>   Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml | 5 ++++-
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
>> index ef648a15b806..9624fc0adfdc 100644
>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-tnoc.yaml
>> @@ -32,6 +32,9 @@ select:
>>     required:
>>       - compatible
>>   
>> +allOf:
>> +  - $ref: /schemas/arm/primecell.yaml#
>> +
>>   properties:
>>     $nodename:
>>       pattern: "^tn(@[0-9a-f]+)$"
>> @@ -78,7 +81,7 @@ required:
>>     - in-ports
>>     - out-ports
>>   
>> -additionalProperties: false
>> +additionalProperties: true
> 
> Nope, it is not allowed. Explicitly mentioned in writing bindings and
> all DT introductory talks by me.

Yes, I am totally wrong with this and I should add:
unevaluatedProperties: false

and remove
additionalProperties: false

Thanks,
Jie

> 
> Best regards,
> Krzysztof
> 

[PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Jie Gan]

The AMBA bus attempts to read the CID/PID of a device before invoking
its probe function if the arm,primecell-periphid property is absent.
This causes a deferred probe issue for the TraceNoC device, as the
CID/PID cannot be read from the periphid register.
Add the arm,primecell-periphid property to bypass the AMBA bus
check and resolve the probe issue.

Fixes: f73959d86c15 ("arm64: dts: qcom: kaanapali: add coresight nodes")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kaanapali.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7aa9653bd456..25820f7c04cd 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -5009,6 +5009,7 @@ tn@111b8000 {
 
 			clocks = <&aoss_qmp>;
 			clock-names = "apb_pclk";
+			arm,primecell-periphid = <0x000f0c00>;
 
 			in-ports {
 				#address-cells = <1>;

-- 
2.34.1

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Konrad Dybcio]

On 6/24/26 11:49 AM, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.

Why does it probe defer?

And is this required for all TNOC devices?

Konrad

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Jie Gan]

On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
> On 6/24/26 11:49 AM, Jie Gan wrote:
>> The AMBA bus attempts to read the CID/PID of a device before invoking
>> its probe function if the arm,primecell-periphid property is absent.
>> This causes a deferred probe issue for the TraceNoC device, as the
>> CID/PID cannot be read from the periphid register.
> 
> Why does it probe defer?
> 

For an AMBA device, the periphid is mandatory for probing. In the 
amba_match function, AMBA attempts to read the periphid from the CID/PID 
registers if the arm,primecell-periphid property is absent in the device 
tree. If this read fails, it returns -EPROBE_DEFER, and the probe 
ultimately fails.
Most AMBA devices expose valid CID/PID registers, so specifying 
arm,primecell-periphid in the device tree is usually unnecessary. 
However, for the TraceNoC device in this case, AMBA cannot reliably read 
the periphid from the corresponding registers.

> And is this required for all TNOC devices?

So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali 
platforms, and all exhibit probe failures due to the same root cause.

I prefer to fix it on Kaanapali first.

Thanks,
Jie

> 
> Konrad

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Suzuki K Poulose]

On 24/06/2026 14:48, Jie Gan wrote:
> 
> 
> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>> On 6/24/26 11:49 AM, Jie Gan wrote:
>>> The AMBA bus attempts to read the CID/PID of a device before invoking
>>> its probe function if the arm,primecell-periphid property is absent.
>>> This causes a deferred probe issue for the TraceNoC device, as the
>>> CID/PID cannot be read from the periphid register.
>>
>> Why does it probe defer?
>>
> 
> For an AMBA device, the periphid is mandatory for probing. In the 
> amba_match function, AMBA attempts to read the periphid from the CID/PID 
> registers if the arm,primecell-periphid property is absent in the device 
> tree. If this read fails, it returns -EPROBE_DEFER, and the probe 
> ultimately fails.

Why does it fail ? power management ? hw broken ? Is it really AMBA or 
do you pretend that to be an AMBA device by faking the CID/PID?

Suzuki


> Most AMBA devices expose valid CID/PID registers, so specifying 
> arm,primecell-periphid in the device tree is usually unnecessary. 
> However, for the TraceNoC device in this case, AMBA cannot reliably read 
> the periphid from the corresponding registers.
> 
>> And is this required for all TNOC devices?
> 
> So far, the TNOC device has been added to sm8750, Glymur, and Kaanapali 
> platforms, and all exhibit probe failures due to the same root cause.
> 
> I prefer to fix it on Kaanapali first.
> 
> Thanks,
> Jie
> 
>>
>> Konrad
> 

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Jie Gan]

On 6/24/2026 9:51 PM, Suzuki K Poulose wrote:
> On 24/06/2026 14:48, Jie Gan wrote:
>>
>>
>> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>>> On 6/24/26 11:49 AM, Jie Gan wrote:
>>>> The AMBA bus attempts to read the CID/PID of a device before invoking
>>>> its probe function if the arm,primecell-periphid property is absent.
>>>> This causes a deferred probe issue for the TraceNoC device, as the
>>>> CID/PID cannot be read from the periphid register.
>>>
>>> Why does it probe defer?
>>>
>>
>> For an AMBA device, the periphid is mandatory for probing. In the 
>> amba_match function, AMBA attempts to read the periphid from the CID/ 
>> PID registers if the arm,primecell-periphid property is absent in the 
>> device tree. If this read fails, it returns -EPROBE_DEFER, and the 
>> probe ultimately fails.
> 
> Why does it fail ? power management ? hw broken ? Is it really AMBA or 
> do you pretend that to be an AMBA device by faking the CID/PID?

The CID reads as 0 from the register, which I suspect is a hardware 
design issue. I have not yet confirmed this with the hardware team. As a 
workaround, I provided a fake periphid via a DT property to bypass 
amba_read_periphid.


Leo commented in other thread:
 >>tnoc.c registers both an AMBA driver and a platform driver. Shouldn't 
 >>it
 >>be registered as a platform device instead?

The platform driver is intended for the interconnect TraceNoC device and 
is not designed to allocate an ATID. The issue is that the TPDM device 
borrows the ATID from the TraceNoC device, resulting in the ATID always 
being 0 when associated with an interconnect NoC device.

However, I believe it is acceptable to allocate an ATID for the itNoC 
device and the issue can be fixed with this way.

Thanks,
Jie

> 
> Suzuki
> 
> 
>> Most AMBA devices expose valid CID/PID registers, so specifying 
>> arm,primecell-periphid in the device tree is usually unnecessary. 
>> However, for the TraceNoC device in this case, AMBA cannot reliably 
>> read the periphid from the corresponding registers.
>>
>>> And is this required for all TNOC devices?
>>
>> So far, the TNOC device has been added to sm8750, Glymur, and 
>> Kaanapali platforms, and all exhibit probe failures due to the same 
>> root cause.
>>
>> I prefer to fix it on Kaanapali first.
>>
>> Thanks,
>> Jie
>>
>>>
>>> Konrad
>>
> 

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Leo Yan]

On Wed, Jun 24, 2026 at 11:08:32PM +0800, Jie Gan wrote:

[...]

> > Why does it fail ? power management ? hw broken ? Is it really AMBA or
> > do you pretend that to be an AMBA device by faking the CID/PID?
> 
> The CID reads as 0 from the register, which I suspect is a hardware design
> issue. I have not yet confirmed this with the hardware team. As a
> workaround, I provided a fake periphid via a DT property to bypass
> amba_read_periphid.
> 
> 
> Leo commented in other thread:
> >>tnoc.c registers both an AMBA driver and a platform driver. Shouldn't >>it
> >>be registered as a platform device instead?
> 
> The platform driver is intended for the interconnect TraceNoC device and is
> not designed to allocate an ATID. The issue is that the TPDM device borrows
> the ATID from the TraceNoC device, resulting in the ATID always being 0 when
> associated with an interconnect NoC device.
> 
> However, I believe it is acceptable to allocate an ATID for the itNoC device
> and the issue can be fixed with this way.

I think so.

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Jie Gan]

On 6/24/2026 11:16 PM, Leo Yan wrote:
> On Wed, Jun 24, 2026 at 11:08:32PM +0800, Jie Gan wrote:
> 
> [...]
> 
>>> Why does it fail ? power management ? hw broken ? Is it really AMBA or
>>> do you pretend that to be an AMBA device by faking the CID/PID?
>>
>> The CID reads as 0 from the register, which I suspect is a hardware design
>> issue. I have not yet confirmed this with the hardware team. As a
>> workaround, I provided a fake periphid via a DT property to bypass
>> amba_read_periphid.
>>
>>
>> Leo commented in other thread:
>>>> tnoc.c registers both an AMBA driver and a platform driver. Shouldn't >>it
>>>> be registered as a platform device instead?
>>
>> The platform driver is intended for the interconnect TraceNoC device and is
>> not designed to allocate an ATID. The issue is that the TPDM device borrows
>> the ATID from the TraceNoC device, resulting in the ATID always being 0 when
>> associated with an interconnect NoC device.
>>
>> However, I believe it is acceptable to allocate an ATID for the itNoC device
>> and the issue can be fixed with this way.
> 
> I think so.

Hi Suzuki/Leo

Which solution do you prefer to address the issue?
The interconnect traceNoC platform driver is intended for the itnoc 
device, implying that no TPDM devices are connected to it. So, if I 
modify it to allocate an ATID, I think it would be better to rename the 
“itnoc” node accordingly? Or it's ok to leave it as-is?

BTW, the traceNoC device definitely is an AMBA device with CID/PID 
registers.

Thanks,
Jie

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Leo Yan]

On Thu, Jun 25, 2026 at 09:01:18AM +0800, Jie Gan wrote:

[...]

> > > However, I believe it is acceptable to allocate an ATID for the itNoC device
> > > and the issue can be fixed with this way.
> > 
> > I think so.
> 
> Hi Suzuki/Leo
> 
> Which solution do you prefer to address the issue?

I will leave this to Suzuki.

> The interconnect traceNoC platform driver is intended for the itnoc device,
> implying that no TPDM devices are connected to it. So, if I modify it to
> allocate an ATID, I think it would be better to rename the “itnoc” node
> accordingly? Or it's ok to leave it as-is?
> 
> BTW, the traceNoC device definitely is an AMBA device with CID/PID
> registers.

Just to share a bit thoughts on the driver's design.

I think it would be better to keep the probe function generic. The AMBA
probe should not be specific to TraceNoC, and the platform probe should
not be only dedicated to the interconnect TraceNoC. The probe function
should simply handle a device that appears on either the AMBA bus or the
platform bus.

So the question is: if allocat an ATID for all traceNoC devices, do you
still need to distinguish TraceNoC types? If no, then the code can be
unified.

Thanks,
Leo

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Jie Gan]

On 6/25/2026 4:56 PM, Leo Yan wrote:
> On Thu, Jun 25, 2026 at 09:01:18AM +0800, Jie Gan wrote:
> 
> [...]
> 
>>>> However, I believe it is acceptable to allocate an ATID for the itNoC device
>>>> and the issue can be fixed with this way.
>>>
>>> I think so.
>>
>> Hi Suzuki/Leo
>>
>> Which solution do you prefer to address the issue?
> 
> I will leave this to Suzuki.
> 
>> The interconnect traceNoC platform driver is intended for the itnoc device,
>> implying that no TPDM devices are connected to it. So, if I modify it to
>> allocate an ATID, I think it would be better to rename the “itnoc” node
>> accordingly? Or it's ok to leave it as-is?
>>
>> BTW, the traceNoC device definitely is an AMBA device with CID/PID
>> registers.
> 
> Just to share a bit thoughts on the driver's design.
> 
> I think it would be better to keep the probe function generic. The AMBA
> probe should not be specific to TraceNoC, and the platform probe should
> not be only dedicated to the interconnect TraceNoC. The probe function
> should simply handle a device that appears on either the AMBA bus or the
> platform bus.
> 
> So the question is: if allocat an ATID for all traceNoC devices, do you
> still need to distinguish TraceNoC types? If no, then the code can be
> unified.
> 

Hi Leo,

To be honest, I would prefer not to modify the interconnect platform 
driver. On some Qualcomm platforms, multiple itnoc devices reside within 
small blocks(one or more than one for each block) and are connected to a 
dummy source. In such cases, two ATIDs are allocated for a path (the 
dummy source and the itnoc), which is inefficient. This is why the itnoc 
platform driver created to avoid this waste.

The TraceNoC (called as AG TraceNoC) is a generic TraceNoC device which 
connected to multiple source and link devices, aggregating data from all 
source devices into a single output path.

This device is implemented as an AMBA device but lacks proper hardware 
configuration. As a result, it must be handled in the driver as a 
workaround, which unfortunately breaks the original design intent.

Thanks,
Jie

> Thanks,
> Leo

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Leo Yan]

Hi Jie,

On Fri, Jun 26, 2026 at 10:03:41AM +0800, Jie Gan wrote:

[...]

> Hi Leo,
> 
> To be honest, I would prefer not to modify the interconnect platform driver.
> On some Qualcomm platforms, multiple itnoc devices reside within small
> blocks(one or more than one for each block) and are connected to a dummy
> source. In such cases, two ATIDs are allocated for a path (the dummy source
> and the itnoc), which is inefficient. This is why the itnoc platform driver
> created to avoid this waste.
> 
> The TraceNoC (called as AG TraceNoC) is a generic TraceNoC device which
> connected to multiple source and link devices, aggregating data from all
> source devices into a single output path.

As I said, it may be fragile to couple a specific device property (ATID)
to the AMBA driver.

You're now facing a case where a device cannot be registered as an AMBA
device, so it cannot use ATID. Likewise, I can imagine in future where a
device is registered as an AMBA device, but you don't want ATID.

> This device is implemented as an AMBA device but lacks proper hardware
> configuration. As a result, it must be handled in the driver as a
> workaround, which unfortunately breaks the original design intent.

Seems to me, it is not reasonable to pretend an AMBA device but AMBA
ID registers are absent.

How about add a new DT property ("qcom,tnoc-enable-atid") to force
enabling ATID?

Thanks,
Leo

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Jie Gan]

Hi Leo,

On 6/26/2026 6:30 PM, Leo Yan wrote:
> Hi Jie,
> 
> On Fri, Jun 26, 2026 at 10:03:41AM +0800, Jie Gan wrote:
> 
> [...]
> 
>> Hi Leo,
>>
>> To be honest, I would prefer not to modify the interconnect platform driver.
>> On some Qualcomm platforms, multiple itnoc devices reside within small
>> blocks(one or more than one for each block) and are connected to a dummy
>> source. In such cases, two ATIDs are allocated for a path (the dummy source
>> and the itnoc), which is inefficient. This is why the itnoc platform driver
>> created to avoid this waste.
>>
>> The TraceNoC (called as AG TraceNoC) is a generic TraceNoC device which
>> connected to multiple source and link devices, aggregating data from all
>> source devices into a single output path.
> 
> As I said, it may be fragile to couple a specific device property (ATID)
> to the AMBA driver.
> 
> You're now facing a case where a device cannot be registered as an AMBA
> device, so it cannot use ATID. Likewise, I can imagine in future where a
> device is registered as an AMBA device, but you don't want ATID.
> 

Agree. That's possible.

>> This device is implemented as an AMBA device but lacks proper hardware
>> configuration. As a result, it must be handled in the driver as a
>> workaround, which unfortunately breaks the original design intent.
> 
> Seems to me, it is not reasonable to pretend an AMBA device but AMBA
> ID registers are absent.
> 
> How about add a new DT property ("qcom,tnoc-enable-atid") to force
> enabling ATID?

That's a good proposal.

I have another proposal: what if we allocate the ATID in trace_noc_id() 
when the device does not already have a valid ATID?

Possible scenarios:

If the itnoc device is connected to a TPDM device (which has no ATID), 
trace_noc_id() will be invoked via coresight_path_assign_trace_id(), and 
a valid ATID can be allocated for the path.

If the itnoc device is connected to sources other than TPDM, 
trace_noc_id() will never be invoked, and therefore no ATID will be 
allocated for the device, saving resources.

Thanks,
Jie

> 
> Thanks,
> Leo

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Leo Yan]

On Fri, Jun 26, 2026 at 08:09:58PM +0800, Jie Gan wrote:

[...]

> I have another proposal: what if we allocate the ATID in trace_noc_id() when
> the device does not already have a valid ATID?
> 
> Possible scenarios:
> 
> If the itnoc device is connected to a TPDM device (which has no ATID),
> trace_noc_id() will be invoked via coresight_path_assign_trace_id(), and a
> valid ATID can be allocated for the path.
> 
> If the itnoc device is connected to sources other than TPDM, trace_noc_id()
> will never be invoked, and therefore no ATID will be allocated for the
> device, saving resources.

TBH, I'm not sure I can make a judgement here, as I don't have enough
knowledge of the topology. And I'm not sure whether the listed
connections cover all possible cases.

I also found commit 5799dee92dc2:

 | This patch adds platform driver support for the CoreSight Interconnect
 | TNOC, Interconnect TNOC is a CoreSight link that forwards trace data
 | from a subsystem to the Aggregator TNOC. Compared to Aggregator TNOC,
 | it does not have aggregation and ATID functionality.

With your proposal, wouldn't ATID be allocated for the interconnect
TNOC while being skipped for the Aggregator TNOC? That seems to
contradict the commit log.

Thanks,
Leo

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Jie Gan]

Hi Leo/Suzuki,

On 6/26/2026 11:49 PM, Leo Yan wrote:
> On Fri, Jun 26, 2026 at 08:09:58PM +0800, Jie Gan wrote:
> 
> [...]
> 
>> I have another proposal: what if we allocate the ATID in trace_noc_id() when
>> the device does not already have a valid ATID?
>>
>> Possible scenarios:
>>
>> If the itnoc device is connected to a TPDM device (which has no ATID),
>> trace_noc_id() will be invoked via coresight_path_assign_trace_id(), and a
>> valid ATID can be allocated for the path.
>>
>> If the itnoc device is connected to sources other than TPDM, trace_noc_id()
>> will never be invoked, and therefore no ATID will be allocated for the
>> device, saving resources.
> 
> TBH, I'm not sure I can make a judgement here, as I don't have enough
> knowledge of the topology. And I'm not sure whether the listed
> connections cover all possible cases.
> 
> I also found commit 5799dee92dc2:
> 
>   | This patch adds platform driver support for the CoreSight Interconnect
>   | TNOC, Interconnect TNOC is a CoreSight link that forwards trace data
>   | from a subsystem to the Aggregator TNOC. Compared to Aggregator TNOC,
>   | it does not have aggregation and ATID functionality.
> 
> With your proposal, wouldn't ATID be allocated for the interconnect
> TNOC while being skipped for the Aggregator TNOC? That seems to
> contradict the commit log.

The ATID is allocated to the Aggregator TNOC during probe. The "WA" in 
driver definitely break the original design.


Can I fix the issue by adding "arm,primecell-periphid" property. That's 
would be the best temp solution as it avoids breaking the original 
design of both the TraceNoC AMBA driver and interconnect TraceNoC 
platform driver.

The TraceNoC device here must be treated as an AMBA device and I am 
continuing to investigate the issue with our hardware team. We aim to 
fix it from hardware perspetive for existing platforms if possible and 
ensure it is fixed in future platforms.

Thanks,
Jie

> 
> Thanks,
> Leo

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Leo Yan]

On Mon, Jun 29, 2026 at 10:08:17AM +0800, Jie Gan wrote:

[...]

> Can I fix the issue by adding "arm,primecell-periphid" property. That's
> would be the best temp solution as it avoids breaking the original design of
> both the TraceNoC AMBA driver and interconnect TraceNoC platform driver.

Before proceeding with the "arm,primecell-periphid" property, could you
clarify a bit:

  - For an interconnect TraceNoC, what would be the consequence of
    enabling ATID? Would it simply be a no-op, or are there any side
    effects? Or is the concern that the trace IDs could be exhausted?

  - How can you guarantee that a interconnect TraceNoC will never
    require ATID in the future?

> The TraceNoC device here must be treated as an AMBA device and I am
> continuing to investigate the issue with our hardware team.

> We aim to fix it from hardware perspetive for existing platforms if possible
> and ensure it is fixed in future platforms.

I'm concerned that all of use end up repeatedly fixing similar issues
whenever hardware configurations change or modules are reused in
different topologies.

For example, if future platforms may require ATID support for an
interconnect TraceNoC, then the issue will pop up again.

Thanks,
Leo

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Jie Gan]

On 6/29/2026 10:28 PM, Leo Yan wrote:
> On Mon, Jun 29, 2026 at 10:08:17AM +0800, Jie Gan wrote:
> 
> [...]
> 
>> Can I fix the issue by adding "arm,primecell-periphid" property. That's
>> would be the best temp solution as it avoids breaking the original design of
>> both the TraceNoC AMBA driver and interconnect TraceNoC platform driver.
> 
> Before proceeding with the "arm,primecell-periphid" property, could you
> clarify a bit:
> 
>    - For an interconnect TraceNoC, what would be the consequence of
>      enabling ATID? Would it simply be a no-op, or are there any side
>      effects? Or is the concern that the trace IDs could be exhausted?
> 

TPDM0(or ATB source) -> interconnect TraceNoC0 -> Aggregator TraceNoc -> 
sink
TPDM1(or ATB source) -> interconnect TraceNoC1 -> Aggregator TraceNoc -> 
sink

We only have one Aggregator TraceNoC and many interconnect TraceNoC 
devices for one platform. All interconnect TraceNoC devices are 
connected to Aggregator TraceNoC devices in the topology, so the itnoc 
doesnt need an ATID.

That's the design purpose from hardware perspective.


>    - How can you guarantee that a interconnect TraceNoC will never
>      require ATID in the future?
> 

The interconnect TraceNoC is primarily introduced to reduce routing 
complexity in the hardware design. It is typically deployed as an 
intermediate TraceNoC that connects to an Aggregator TraceNoC (AG TraceNoC).

For example, a modem subsystem may contain many TPDM devices. Directly 
connecting every TPDM to the AG TraceNoC would result in significant 
wiring complexity. Instead, an itnoc is placed within the modem 
subsystem to locally aggregate the TPDM connections. All TPDMs first 
connect to the itnoc, and the itnoc then connects to the system-level AG 
TraceNoC.

 From a hardware perspective, there is no fundamental difference between 
an itnoc and an AG TraceNoC. They use the same TraceNoC hardware 
implementation and share the same AMBA bus type. The distinction is 
purely functional: an itnoc is used for local trace aggregation within a 
subsystem, whereas an AG TraceNoC serves as the top-level aggregation 
point for the SoC.

Thanks,
Jie

>> The TraceNoC device here must be treated as an AMBA device and I am
>> continuing to investigate the issue with our hardware team.
> 
>> We aim to fix it from hardware perspetive for existing platforms if possible
>> and ensure it is fixed in future platforms.
> 
> I'm concerned that all of use end up repeatedly fixing similar issues
> whenever hardware configurations change or modules are reused in
> different topologies.
> 
> For example, if future platforms may require ATID support for an
> interconnect TraceNoC, then the issue will pop up again.
> 
> Thanks,
> Leo

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Leo Yan]

Hi Jie,

On Tue, Jun 30, 2026 at 09:03:52AM +0800, Jie Gan wrote:

[...]

> >    - How can you guarantee that a interconnect TraceNoC will never
> >      require ATID in the future?

> From a hardware perspective, there is no fundamental difference between an
> itnoc and an AG TraceNoC. They use the same TraceNoC hardware implementation
> and share the same AMBA bus type. The distinction is purely functional: an
> itnoc is used for local trace aggregation within a subsystem, whereas an AG
> TraceNoC serves as the top-level aggregation point for the SoC.

I'm still not convinced that adding "arm,primecell-periphid" is the
right approach.

From the description above, I'd expect either the hardware to expose
bits in a register to distinguish these two module types, or as I
suggested earlier, to use a DT property to indicate the module type (or
whether ATID is required).

Or have you tried to detect the last tnoc on a path and allocate ID for
it? (You can retrieve csdev->path).

Thanks,
Leo

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Jie Gan]

Hi Leo,

On 6/30/2026 4:10 PM, Leo Yan wrote:
> Hi Jie,
> 
> On Tue, Jun 30, 2026 at 09:03:52AM +0800, Jie Gan wrote:
> 
> [...]
> 
>>>     - How can you guarantee that a interconnect TraceNoC will never
>>>       require ATID in the future?
> 
>>  From a hardware perspective, there is no fundamental difference between an
>> itnoc and an AG TraceNoC. They use the same TraceNoC hardware implementation
>> and share the same AMBA bus type. The distinction is purely functional: an
>> itnoc is used for local trace aggregation within a subsystem, whereas an AG
>> TraceNoC serves as the top-level aggregation point for the SoC.
> 
> I'm still not convinced that adding "arm,primecell-periphid" is the
> right approach.
> 

I agree we shouldn't need to add arm,primecell-periphid for the AMBA 
bus, as the hardware provides the necessary registers to read the 
peripheral ID. I used it as a temporary workaround to resolve the issue, 
but I believe that solution is not correct.

>  From the description above, I'd expect either the hardware to expose
> bits in a register to distinguish these two module types, or as I
> suggested earlier, to use a DT property to indicate the module type (or
> whether ATID is required).
> 

I wanna distinguish the aggregator traceNoC and interconnect traceNoC, 
even probe with platform driver, but the existing compatible is too 
specific to the interconnect traceNoC device(coresight-itnoc), that's 
why I didnt try the DT property proposal.

> Or have you tried to detect the last tnoc on a path and allocate ID for
> it? (You can retrieve csdev->path).

As Suzuki mentioned in the other thread, I think it would be better to 
add separate compatibles in the of_match_table to distinguish between 
Aggregator TraceNoC and Interconnect TraceNoC when probing with the 
platform driver. This would allow us to allocate an ATID only for 
Aggregator TraceNoC during probe, which is consistent with our original 
design.

Thanks,
Jie

> 
> Thanks,
> Leo

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Leo Yan]

On Tue, Jun 30, 2026 at 04:42:39PM +0800, Jie Gan wrote:

[...]

> As Suzuki mentioned in the other thread, I think it would be better to add
> separate compatibles in the of_match_table to distinguish between Aggregator
> TraceNoC and Interconnect TraceNoC when probing with the platform driver.
> This would allow us to allocate an ATID only for Aggregator TraceNoC during
> probe, which is consistent with our original design.

Makes sense for me!

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Suzuki K Poulose]

On 30/06/2026 02:03, Jie Gan wrote:
> 
> 
> On 6/29/2026 10:28 PM, Leo Yan wrote:
>> On Mon, Jun 29, 2026 at 10:08:17AM +0800, Jie Gan wrote:
>>
>> [...]
>>
>>> Can I fix the issue by adding "arm,primecell-periphid" property. That's
>>> would be the best temp solution as it avoids breaking the original 
>>> design of
>>> both the TraceNoC AMBA driver and interconnect TraceNoC platform driver.
>>
>> Before proceeding with the "arm,primecell-periphid" property, could you
>> clarify a bit:
>>
>>    - For an interconnect TraceNoC, what would be the consequence of
>>      enabling ATID? Would it simply be a no-op, or are there any side
>>      effects? Or is the concern that the trace IDs could be exhausted?
>>
> 
> TPDM0(or ATB source) -> interconnect TraceNoC0 -> Aggregator TraceNoc -> 
> sink
> TPDM1(or ATB source) -> interconnect TraceNoC1 -> Aggregator TraceNoc -> 
> sink
> 
> We only have one Aggregator TraceNoC and many interconnect TraceNoC 
> devices for one platform. All interconnect TraceNoC devices are 
> connected to Aggregator TraceNoC devices in the topology, so the itnoc 
> doesnt need an ATID.
> 
> That's the design purpose from hardware perspective.
> 
> 
>>    - How can you guarantee that a interconnect TraceNoC will never
>>      require ATID in the future?
>>
> 
> The interconnect TraceNoC is primarily introduced to reduce routing 
> complexity in the hardware design. It is typically deployed as an 
> intermediate TraceNoC that connects to an Aggregator TraceNoC (AG 
> TraceNoC).


You can always distinguish one from the other by checking the
"compatibles"  or even add a custom data field to the of_device_id
table for the platform driver. Personally, I think it is better to
keep things away from AMBA framework, when we get everything from
platform driver.

Cheers
Suzuki


> 
> For example, a modem subsystem may contain many TPDM devices. Directly 
> connecting every TPDM to the AG TraceNoC would result in significant 
> wiring complexity. Instead, an itnoc is placed within the modem 
> subsystem to locally aggregate the TPDM connections. All TPDMs first 
> connect to the itnoc, and the itnoc then connects to the system-level AG 
> TraceNoC.
> 
>  From a hardware perspective, there is no fundamental difference between 
> an itnoc and an AG TraceNoC. They use the same TraceNoC hardware 
> implementation and share the same AMBA bus type. The distinction is 
> purely functional: an itnoc is used for local trace aggregation within a 
> subsystem, whereas an AG TraceNoC serves as the top-level aggregation 
> point for the SoC.
> 
> Thanks,
> Jie
> 
>>> The TraceNoC device here must be treated as an AMBA device and I am
>>> continuing to investigate the issue with our hardware team.
>>
>>> We aim to fix it from hardware perspetive for existing platforms if 
>>> possible
>>> and ensure it is fixed in future platforms.
>>
>> I'm concerned that all of use end up repeatedly fixing similar issues
>> whenever hardware configurations change or modules are reused in
>> different topologies.
>>
>> For example, if future platforms may require ATID support for an
>> interconnect TraceNoC, then the issue will pop up again.
>>
>> Thanks,
>> Leo
> 

Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue

[Leo Yan]

On Wed, Jun 24, 2026 at 05:49:26PM +0800, Jie Gan wrote:
> The AMBA bus attempts to read the CID/PID of a device before invoking
> its probe function if the arm,primecell-periphid property is absent.
> This causes a deferred probe issue for the TraceNoC device, as the
> CID/PID cannot be read from the periphid register.
> Add the arm,primecell-periphid property to bypass the AMBA bus
> check and resolve the probe issue.

tnoc.c registers both an AMBA driver and a platform driver. Shouldn't it
be registered as a platform device instead?

Thanks,
Leo