[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