Re: [PATCH 3/4] arm64: dts: qcom: kaanapali: Add CoreSight nodes for APSS debug block

[Jie Gan <jie.gan@oss.qualcomm.com>]

On 10/13/2026 8:49 PM, Konrad Dybcio wrote:
> On 9/22/26 12:35 PM, Jie Gan wrote:
>> The APSS debug block is built with CoreSight devices like ETE,
>> replicator, funnel and TMC ETF. Add dt nodes for these devices to enable
>> ETM trace.
>>
>> The replicator, funnel and TMC ETF nodes in this block are physically
>> powered by the CPU cluster power rail rather than by a dedicated always-on
>> rail. Add a power-domains property referencing the cluster_pd domain to
>> each of these nodes, so their power state is tied to the CPU cluster
>> domain and the runtime PM core can power the domain on before the
>> devices are accessed and let it be powered off otherwise.
>>
>> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>> ---
>>   arch/arm64/boot/dts/qcom/kaanapali.dtsi | 567 ++++++++++++++++++++++++++++++++
>>   1 file changed, 567 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> index 131fd2a16c54..d9313de53ee5 100644
>> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
>> @@ -218,6 +218,110 @@ domain_ss3: domain-sleep-0 {
>>   		};
>>   	};
>>   
>> +	ete-0 {
>> +		compatible = "arm,embedded-trace-extension";
> 
> No power-domains for these too?

ETM/ETE device is the debug device of the CPU, no power-domain property 
attached to the device and the power management operations relies on the 
CPU itself.

I missed qcom,skip-power-up; for those nodes, ETE device should not 
check the power state of the device.

Will send new version to address it.

> 
> [...]
> 
>> +		tmc@1d029000 {
>> +			compatible = "arm,coresight-tmc", "arm,primecell";
>> +			reg = <0x0 0x1d029000 0x0 0x1000>;
>> +
>> +			clocks = <&aoss_qmp>;
>> +			clock-names = "apb_pclk";
>> +			power-domains = <&cluster_pd>;
> 
> Is there only being a single cluster_pd a mistake on kaanapali?
> 

 From psci map, KNP only has one cluster_pd shared among all CPUs.

Hi Jingyi,

Can you please help to comment this part?

Thanks,
Jie

> The CPUs have a different Aff1 value in the MPIDR register, so one
> would think there's 2 (also according to the cpu-map)
> 
> Konrad