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

Jie Gan jie.gan at oss.qualcomm.com
Tue Jun 30 01:42:39 PDT 2026


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




More information about the linux-arm-kernel mailing list