On Fri, Dec 19, 2025 at 09:50:18AM +0800, yuanfang zhang wrote:
[...]
It is due to the particular characteristics of the CPU cluster power domain. Runtime PM for CPU devices works little different, it is mostly used to manage hierarchical CPU topology (PSCI OSI mode) to talk with genpd framework to manage the last CPU handling in cluster. It doesn’t really send IPI to wakeup CPU device (It don’t have .power_on/.power_off) callback implemented which gets invoked from .runtime_resume callback. This behavior is aligned with the upstream Kernel.
Just for easier understanding, let me give an example:
funnel0: funnel@10000000 { compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; reg = <0x10000000 0x1000>;
clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; clock-names = "apb_pclk", "atclk"; power-domains = <&cluster0_pd>; }
If funnel0 is bound to cluster's power domain, kernel's genPD will automatically enable cluster power domain before access registers.
My understanding is your driver or firmware fails to turn on a cluster power domain without waking up a CPU (and without sending IPI). It is not a kernel issue or limitation, and no any incorrect in PSCI OSI.
As Suzuki said, you might directly reply Sudeep's questions. We would confirm if any flaw in common code.
P.s., currently you can use "taskset" as a temporary solution without any code change, something like:
taskset -c 0 echo 1 > /sys/bus/coresight/devices/etm0/enable_source
This can address the runtime issue, but it does not resolve the problem during the probe phase.
Indeed. If you insmod mode, you might can temporarily disable idle states?
exec 3<> /dev/cpu_dma_latency; echo 0 >&3 insmod exec 3<>-
Thanks, Leo