Hi,
On Thu, Dec 18, 2025 at 12:09:40AM -0800, Coresight ML wrote:
[...]
- Utilizing `smp_call_function_single()` to ensure register accesses (initialization, enablement, sysfs reads) are always executed on a powered CPU within the target cluster.
This is concerned as Mike suggested earlier.
Let me convert to a common question: how does the Linux kernel manage a power domain shared by multiple hardware modules?
A general solution is to bind a power domain (let's say PD1) to both module A (MOD_A) and module B (MOD_B). Each time before accessing MOD_A or MOD_B, PD1 must be powered on first via the pm_runtime APIs, with its refcount increased accordingly.
My understanding is the problem in your case is that the driver fails to create a relationship between the funnel/replicator modules and the cluster power domain. Instead, you are trying to use the CPUs in the same cluster as a delegate for power operations - when you want to access MOD_B, your wake up MOD_A which sharing the same power domain, only to turn on the PD_A in order to access MOD_B.
Have you discussed with the firmware and hardware engineers whether it is feasible to provide explicit power and clock control interfaces for the funnel and replicator modules? I can imagine the cluster power domain's design might differ from other device power domains, but should not the hardware provide a sane design that allows software to control power for the access logic within it?
General speaking, using smp_call_function_single() makes sense if only when accessing logics within the CPU boundary.
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
Thanks, Leo