[PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
Jie Gan
jie.gan at oss.qualcomm.com
Sun Jun 28 19:08:17 PDT 2026
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
More information about the linux-arm-kernel
mailing list