[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