This patch series adds support for CoreSight components local to CPU clusters,
including funnel, replicator, and TMC, which reside within CPU cluster power
domains. These components require special handling due to power domain
constraints.

Unlike system-level CoreSight devices, these components share the CPU cluster's
power domain. When the cluster enters low-power mode (LPM), their registers
become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster
out of LPM, making standard register access unreliable.

To address this, the series introduces:
- Identifying cluster-bound devices via a new `qcom,cpu-bound-components`
  device tree property.
- Implementing deferred probing: if associated CPUs are offline during
  probe, initialization is deferred until a CPU hotplug notifier detects
  the CPU coming online.
- Utilizing `smp_call_function_single()` to ensure register accesses
  (initialization, enablement, sysfs reads) are always executed on a
  powered CPU within the target cluster.
- Extending the CoreSight link `enable` callback to pass the `cs_mode`.
  This allows drivers to distinguish between SysFS and Perf modes and
  apply mode-specific logic.

Jie Gan (1):
  arm64: dts: qcom: hamoa: add Coresight nodes for APSS debug block

Yuanfang Zhang (11):
  dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property
  coresight: Pass trace mode to link enable callback
  coresight-funnel: Support CPU cluster funnel initialization
  coresight-funnel: Defer probe when associated CPUs are offline
  coresight-replicator: Support CPU cluster replicator initialization
  coresight-replicator: Defer probe when associated CPUs are offline
  coresight-replicator: Update management interface for CPU-bound devices
  coresight-tmc: Support probe and initialization for CPU cluster TMCs
  coresight-tmc-etf: Refactor enable function for CPU cluster ETF support
  coresight-tmc: Update management interface for CPU-bound TMCs
  coresight-tmc: Defer probe when associated CPUs are offline

Verification:

This series has been verified on sm8750.

Test steps for delay probe:

1. limit the system to enable at most 6 CPU cores during boot.
2. echo 1 >/sys/bus/cpu/devices/cpu6/online.
3. check whether ETM6 and ETM7 have been probed.

Test steps for sysfs mode:

echo 1 >/sys/bus/coresight/devices/tmc_etf0/enable_sink
echo 1 >/sys/bus/coresight/devices/etm0/enable_source
echo 1 >/sys/bus/coresight/devices/etm6/enable_source
echo 0 >/sys/bus/coresight/devices/etm0/enable_source
echo 0 >/sys/bus/coresight/devicse/etm6/enable_source
echo 0 >/sys/bus/coresight/devices/tmc_etf0/enable_sink

echo 1 >/sys/bus/coresight/devices/tmc_etf1/enable_sink
echo 1 >/sys/bus/coresight/devcies/etm0/enable_source
cat /dev/tmc_etf1 >/tmp/etf1.bin
echo 0 >/sys/bus/coresight/devices/etm0/enable_source
echo 0 >/sys/bus/coresight/devices/tmc_etf1/enable_sink

echo 1 >/sys/bus/coresight/devices/tmc_etf2/enable_sink
echo 1 >/sys/bus/coresight/devices/etm6/enable_source
cat /dev/tmc_etf2 >/tmp/etf2.bin
echo 0 >/sys/bus/coresight/devices/etm6/enable_source
echo 0 >/sys/bus/coresight/devices/tmc_etf2/enable_sink

Test steps for sysfs node:

cat /sys/bus/coresight/devices/tmc_etf*/mgmt/*

cat /sys/bus/coresight/devices/funnel*/funnel_ctrl

cat /sys/bus/coresight/devices/replicator*/mgmt/*

Test steps for perf mode:

perf record -a -e cs_etm//k -- sleep 5

Signed-off-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>
---
Changes in v2:
- Use the qcom,cpu-bound-components device tree property to identify devices
  bound to a cluster.
- Refactor commit message.
- Introduce a supported_cpus field in the drvdata structure to record the CPUs
  that belong to the cluster where the local component resides.
- Link to v1: https://lore.kernel.org/r/20251027-cpu_cluster_component_pm-v1-0-31355ac588c2@oss.qualcomm.com

---
Jie Gan (1):
      arm64: dts: qcom: hamoa: Add CoreSight nodes for APSS debug block

Yuanfang Zhang (11):
      dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property
      coresight-funnel: Support CPU cluster funnel initialization
      coresight-funnel: Defer probe when associated CPUs are offline
      coresight-replicator: Support CPU cluster replicator initialization
      coresight-replicator: Defer probe when associated CPUs are offline
      coresight-replicator: Update management interface for CPU-bound devices
      coresight-tmc: Support probe and initialization for CPU cluster TMCs
      coresight-tmc-etf: Refactor enable function for CPU cluster ETF support
      coresight-tmc: Update management interface for CPU-bound TMCs
      coresight-tmc: Defer probe when associated CPUs are offline
      coresight: Pass trace mode to link enable callback

 .../bindings/arm/arm,coresight-dynamic-funnel.yaml |   5 +
 .../arm/arm,coresight-dynamic-replicator.yaml      |   5 +
 .../devicetree/bindings/arm/arm,coresight-tmc.yaml |   5 +
 arch/arm64/boot/dts/qcom/hamoa.dtsi                | 926 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/purwa.dtsi                |  12 +
 drivers/hwtracing/coresight/coresight-core.c       |   7 +-
 drivers/hwtracing/coresight/coresight-funnel.c     | 258 +++++-
 drivers/hwtracing/coresight/coresight-replicator.c | 341 +++++++-
 drivers/hwtracing/coresight/coresight-tmc-core.c   | 387 +++++++--
 drivers/hwtracing/coresight/coresight-tmc-etf.c    | 106 ++-
 drivers/hwtracing/coresight/coresight-tmc.h        |  10 +
 drivers/hwtracing/coresight/coresight-tnoc.c       |   3 +-
 drivers/hwtracing/coresight/coresight-tpda.c       |   3 +-
 include/linux/coresight.h                          |   3 +-
 14 files changed, 1902 insertions(+), 169 deletions(-)
---
base-commit: 008d3547aae5bc86fac3eda317489169c3fda112
change-id: 20251016-cpu_cluster_component_pm-ce518f510433

Best regards,
-- 
Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>

On Thu, Dec 18, 2025 at 12:09:40AM -0800, Yuanfang Zhang wrote:
> This patch series adds support for CoreSight components local to CPU clusters,
> including funnel, replicator, and TMC, which reside within CPU cluster power
> domains. These components require special handling due to power domain
> constraints.
> 

Could you clarify why PSCI-based power domains associated with clusters in
domain-idle-states cannot address these requirements, given that PSCI CPU-idle
OSI mode was originally intended to support them? My understanding of this
patch series is that OSI mode is unable to do so, which, if accurate, appears
to be a flaw that should be corrected.

> Unlike system-level CoreSight devices, these components share the CPU cluster's
> power domain. When the cluster enters low-power mode (LPM), their registers
> become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster
> out of LPM, making standard register access unreliable.
> 

Are these devices the only ones on the system that are uniquely bound to
cluster-level power domains? If not, what additional devices share this
dependency so that we can understand how they are managed in comparison?

> To address this, the series introduces:
> - Identifying cluster-bound devices via a new `qcom,cpu-bound-components`
>   device tree property.

Really, no please.

-- 
Regards,
Sudeep

On 12/18/2025 7:33 PM, Sudeep Holla wrote:
> On Thu, Dec 18, 2025 at 12:09:40AM -0800, Yuanfang Zhang wrote:
>> This patch series adds support for CoreSight components local to CPU clusters,
>> including funnel, replicator, and TMC, which reside within CPU cluster power
>> domains. These components require special handling due to power domain
>> constraints.
>>
> 
> Could you clarify why PSCI-based power domains associated with clusters in
> domain-idle-states cannot address these requirements, given that PSCI CPU-idle
> OSI mode was originally intended to support them? My understanding of this
> patch series is that OSI mode is unable to do so, which, if accurate, appears
> to be a flaw that should be corrected.

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.

> 
>> Unlike system-level CoreSight devices, these components share the CPU cluster's
>> power domain. When the cluster enters low-power mode (LPM), their registers
>> become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster
>> out of LPM, making standard register access unreliable.
>>
> 
> Are these devices the only ones on the system that are uniquely bound to
> cluster-level power domains? If not, what additional devices share this
> dependency so that we can understand how they are managed in comparison?
> 

Yes, devices like ETM and TRBE also share this power domain and access constraint.
Their drivers naturally handle enablement/disablement on the specific CPU they
belong to (e.g., via hotplug callbacks or existing smp_call_function paths).
>> To address this, the series introduces:
>> - Identifying cluster-bound devices via a new `qcom,cpu-bound-components`
>>   device tree property.
> 
> Really, no please.
> 

Our objective is to determine which CoreSight components are physically locate
within the CPU cluster power domain. 
Would it be acceptable to derive this relationship from the existing power-domains binding?
For example, if a Funnel or Replicator node is linked to a power-domains entry that specifies a cpumask,
the driver could recognize this shared dependency and automatically apply the appropriate cluster-aware behavior.

thanks,
yuanfang.

On Fri, Dec 19, 2025 at 10:13:14AM +0800, yuanfang zhang wrote:
> 
> 
> On 12/18/2025 7:33 PM, Sudeep Holla wrote:
> > On Thu, Dec 18, 2025 at 12:09:40AM -0800, Yuanfang Zhang wrote:
> >> This patch series adds support for CoreSight components local to CPU clusters,
> >> including funnel, replicator, and TMC, which reside within CPU cluster power
> >> domains. These components require special handling due to power domain
> >> constraints.
> >>
> > 
> > Could you clarify why PSCI-based power domains associated with clusters in
> > domain-idle-states cannot address these requirements, given that PSCI CPU-idle
> > OSI mode was originally intended to support them? My understanding of this
> > patch series is that OSI mode is unable to do so, which, if accurate, appears
> > to be a flaw that should be corrected.
> 
> 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 hierarchicalCPU topology (PSCI OSI mode) to talk with genpd
> framework to manage the last CPU handling in cluster.

That is indeed the intended design. Could you clarify which specific
characteristics differentiate it here?

> 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.
> 

I am quite lost here. Why is it necessary to wake up the CPU? If I understand
correctly, all of this complexity is meant to ensure that the cluster power
domain is enabled before any of the funnel registers are accessed. Is that
correct?

If so, and if the cluster domains are already defined as the power domains for
these funnel devices, then they should be requested to power on automatically
before any register access occurs. Is that not the case?

What am I missing in this reasoning?

The only explanation I can see is that the firmware does not properly honor
power-domain requests coming directly from the OS. I believe that may be the
case, but I would be glad to be proven wrong.

> > 
> >> Unlike system-level CoreSight devices, these components share the CPU cluster's
> >> power domain. When the cluster enters low-power mode (LPM), their registers
> >> become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster
> >> out of LPM, making standard register access unreliable.
> >>
> > 
> > Are these devices the only ones on the system that are uniquely bound to
> > cluster-level power domains? If not, what additional devices share this
> > dependency so that we can understand how they are managed in comparison?
> > 
> 
> Yes, devices like ETM and TRBE also share this power domain and access constraint.
> Their drivers naturally handle enablement/disablement on the specific CPU they
> belong to (e.g., via hotplug callbacks or existing smp_call_function paths).

I understand many things are possible to implement, but the key question
remains: why doesn’t the existing OSI mechanism - added specifically to cover
cases like this solve the problem today?

Especially on platforms with OSI enabled, what concrete limitation forces us
into this additional “wake-up” path instead of relying on OSI to manage the
dependency/power sequencing?

> >> To address this, the series introduces:
> >> - Identifying cluster-bound devices via a new `qcom,cpu-bound-components`
> >>   device tree property.
> > 
> > Really, no please.
> > 
> 
> Our objective is to determine which CoreSight components are physically locate
> within the CPU cluster power domain.
>
> Would it be acceptable to derive this relationship from the existing
> power-domains binding?

In my opinion, this is not merely a possibility but an explicit expectation.

> For example, if a Funnel or Replicator node is linked to a power-domains
> entry that specifies a cpumask, the driver could recognize this shared
> dependency and automatically apply the appropriate cluster-aware behavior.
> 

Sure, but for the driver to use that information, we need clear explanation
for all the questions above. In short, why it is not working with the existing
PSCI domain idle support.

-- 
Regards,
Sudeep

On 19/12/2025 10:21, Sudeep Holla wrote:
> On Fri, Dec 19, 2025 at 10:13:14AM +0800, yuanfang zhang wrote:
>>
>>
>> On 12/18/2025 7:33 PM, Sudeep Holla wrote:
>>> On Thu, Dec 18, 2025 at 12:09:40AM -0800, Yuanfang Zhang wrote:
>>>> This patch series adds support for CoreSight components local to CPU clusters,
>>>> including funnel, replicator, and TMC, which reside within CPU cluster power
>>>> domains. These components require special handling due to power domain
>>>> constraints.
>>>>
>>>
>>> Could you clarify why PSCI-based power domains associated with clusters in
>>> domain-idle-states cannot address these requirements, given that PSCI CPU-idle
>>> OSI mode was originally intended to support them? My understanding of this
>>> patch series is that OSI mode is unable to do so, which, if accurate, appears
>>> to be a flaw that should be corrected.
>>
>> 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 hierarchicalCPU topology (PSCI OSI mode) to talk with genpd
>> framework to manage the last CPU handling in cluster.
> 
> That is indeed the intended design. Could you clarify which specific
> characteristics differentiate it here?
> 
>> 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.
>>
> 
> I am quite lost here. Why is it necessary to wake up the CPU? If I understand
> correctly, all of this complexity is meant to ensure that the cluster power
> domain is enabled before any of the funnel registers are accessed. Is that
> correct?
> 
> If so, and if the cluster domains are already defined as the power domains for
> these funnel devices, then they should be requested to power on automatically
> before any register access occurs. Is that not the case?
> 
> What am I missing in this reasoning?

Exactly, this is what I am too. But then you get the "pre-formated 
standard response" without answering our questions.

Suzuki

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

On 12/18/2025 6:40 PM, Leo Yan wrote:
> 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?
> 

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.


> 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


This can address the runtime issue, but it does not resolve the problem during the probe phase.

thanks,
Yuanfang> 
> Thanks,
> Leo

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

Cc: Sudeep

On 18/12/2025 08:09, Yuanfang Zhang wrote:
> This patch series adds support for CoreSight components local to CPU clusters,
> including funnel, replicator, and TMC, which reside within CPU cluster power
> domains. These components require special handling due to power domain
> constraints.
> 
> Unlike system-level CoreSight devices, these components share the CPU cluster's
> power domain. When the cluster enters low-power mode (LPM), their registers
> become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster
> out of LPM, making standard register access unreliable.

Why ? AFAIU, we have ways to tie the power-domain to that of the cluster
and that can auto-magically keep the cluster power ON as long as you
want to use them.

Suzuki


> 
> To address this, the series introduces:
> - Identifying cluster-bound devices via a new `qcom,cpu-bound-components`
>    device tree property.
> - Implementing deferred probing: if associated CPUs are offline during
>    probe, initialization is deferred until a CPU hotplug notifier detects
>    the CPU coming online.
> - Utilizing `smp_call_function_single()` to ensure register accesses
>    (initialization, enablement, sysfs reads) are always executed on a
>    powered CPU within the target cluster.
> - Extending the CoreSight link `enable` callback to pass the `cs_mode`.
>    This allows drivers to distinguish between SysFS and Perf modes and
>    apply mode-specific logic.
> 
> Jie Gan (1):
>    arm64: dts: qcom: hamoa: add Coresight nodes for APSS debug block
> 
> Yuanfang Zhang (11):
>    dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property
>    coresight: Pass trace mode to link enable callback
>    coresight-funnel: Support CPU cluster funnel initialization
>    coresight-funnel: Defer probe when associated CPUs are offline
>    coresight-replicator: Support CPU cluster replicator initialization
>    coresight-replicator: Defer probe when associated CPUs are offline
>    coresight-replicator: Update management interface for CPU-bound devices
>    coresight-tmc: Support probe and initialization for CPU cluster TMCs
>    coresight-tmc-etf: Refactor enable function for CPU cluster ETF support
>    coresight-tmc: Update management interface for CPU-bound TMCs
>    coresight-tmc: Defer probe when associated CPUs are offline
> 
> Verification:
> 
> This series has been verified on sm8750.
> 
> Test steps for delay probe:
> 
> 1. limit the system to enable at most 6 CPU cores during boot.
> 2. echo 1 >/sys/bus/cpu/devices/cpu6/online.
> 3. check whether ETM6 and ETM7 have been probed.
> 
> Test steps for sysfs mode:
> 
> echo 1 >/sys/bus/coresight/devices/tmc_etf0/enable_sink
> echo 1 >/sys/bus/coresight/devices/etm0/enable_source
> echo 1 >/sys/bus/coresight/devices/etm6/enable_source
> echo 0 >/sys/bus/coresight/devices/etm0/enable_source
> echo 0 >/sys/bus/coresight/devicse/etm6/enable_source
> echo 0 >/sys/bus/coresight/devices/tmc_etf0/enable_sink
> 
> echo 1 >/sys/bus/coresight/devices/tmc_etf1/enable_sink
> echo 1 >/sys/bus/coresight/devcies/etm0/enable_source
> cat /dev/tmc_etf1 >/tmp/etf1.bin
> echo 0 >/sys/bus/coresight/devices/etm0/enable_source
> echo 0 >/sys/bus/coresight/devices/tmc_etf1/enable_sink
> 
> echo 1 >/sys/bus/coresight/devices/tmc_etf2/enable_sink
> echo 1 >/sys/bus/coresight/devices/etm6/enable_source
> cat /dev/tmc_etf2 >/tmp/etf2.bin
> echo 0 >/sys/bus/coresight/devices/etm6/enable_source
> echo 0 >/sys/bus/coresight/devices/tmc_etf2/enable_sink
> 
> Test steps for sysfs node:
> 
> cat /sys/bus/coresight/devices/tmc_etf*/mgmt/*
> 
> cat /sys/bus/coresight/devices/funnel*/funnel_ctrl
> 
> cat /sys/bus/coresight/devices/replicator*/mgmt/*
> 
> Test steps for perf mode:
> 
> perf record -a -e cs_etm//k -- sleep 5
> 
> Signed-off-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>
> ---
> Changes in v2:
> - Use the qcom,cpu-bound-components device tree property to identify devices
>    bound to a cluster.
> - Refactor commit message.
> - Introduce a supported_cpus field in the drvdata structure to record the CPUs
>    that belong to the cluster where the local component resides.
> - Link to v1: https://lore.kernel.org/r/20251027-cpu_cluster_component_pm-v1-0-31355ac588c2@oss.qualcomm.com
> 
> ---
> Jie Gan (1):
>        arm64: dts: qcom: hamoa: Add CoreSight nodes for APSS debug block
> 
> Yuanfang Zhang (11):
>        dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property
>        coresight-funnel: Support CPU cluster funnel initialization
>        coresight-funnel: Defer probe when associated CPUs are offline
>        coresight-replicator: Support CPU cluster replicator initialization
>        coresight-replicator: Defer probe when associated CPUs are offline
>        coresight-replicator: Update management interface for CPU-bound devices
>        coresight-tmc: Support probe and initialization for CPU cluster TMCs
>        coresight-tmc-etf: Refactor enable function for CPU cluster ETF support
>        coresight-tmc: Update management interface for CPU-bound TMCs
>        coresight-tmc: Defer probe when associated CPUs are offline
>        coresight: Pass trace mode to link enable callback
> 
>   .../bindings/arm/arm,coresight-dynamic-funnel.yaml |   5 +
>   .../arm/arm,coresight-dynamic-replicator.yaml      |   5 +
>   .../devicetree/bindings/arm/arm,coresight-tmc.yaml |   5 +
>   arch/arm64/boot/dts/qcom/hamoa.dtsi                | 926 +++++++++++++++++++++
>   arch/arm64/boot/dts/qcom/purwa.dtsi                |  12 +
>   drivers/hwtracing/coresight/coresight-core.c       |   7 +-
>   drivers/hwtracing/coresight/coresight-funnel.c     | 258 +++++-
>   drivers/hwtracing/coresight/coresight-replicator.c | 341 +++++++-
>   drivers/hwtracing/coresight/coresight-tmc-core.c   | 387 +++++++--
>   drivers/hwtracing/coresight/coresight-tmc-etf.c    | 106 ++-
>   drivers/hwtracing/coresight/coresight-tmc.h        |  10 +
>   drivers/hwtracing/coresight/coresight-tnoc.c       |   3 +-
>   drivers/hwtracing/coresight/coresight-tpda.c       |   3 +-
>   include/linux/coresight.h                          |   3 +-
>   14 files changed, 1902 insertions(+), 169 deletions(-)
> ---
> base-commit: 008d3547aae5bc86fac3eda317489169c3fda112
> change-id: 20251016-cpu_cluster_component_pm-ce518f510433
> 
> Best regards,

On 12/18/2025 5:32 PM, Suzuki K Poulose wrote:
> Cc: Sudeep
> 
> On 18/12/2025 08:09, Yuanfang Zhang wrote:
>> This patch series adds support for CoreSight components local to CPU clusters,
>> including funnel, replicator, and TMC, which reside within CPU cluster power
>> domains. These components require special handling due to power domain
>> constraints.
>>
>> Unlike system-level CoreSight devices, these components share the CPU cluster's
>> power domain. When the cluster enters low-power mode (LPM), their registers
>> become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster
>> out of LPM, making standard register access unreliable.
> 
> Why ? AFAIU, we have ways to tie the power-domain to that of the cluster
> and that can auto-magically keep the cluster power ON as long as you
> want to use them.
> 
> Suzuki
> 
Hi Suzuki

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.

Yuanfang

> 
>>
>> To address this, the series introduces:
>> - Identifying cluster-bound devices via a new `qcom,cpu-bound-components`
>>    device tree property.
>> - Implementing deferred probing: if associated CPUs are offline during
>>    probe, initialization is deferred until a CPU hotplug notifier detects
>>    the CPU coming online.
>> - Utilizing `smp_call_function_single()` to ensure register accesses
>>    (initialization, enablement, sysfs reads) are always executed on a
>>    powered CPU within the target cluster.
>> - Extending the CoreSight link `enable` callback to pass the `cs_mode`.
>>    This allows drivers to distinguish between SysFS and Perf modes and
>>    apply mode-specific logic.
>>
>> Jie Gan (1):
>>    arm64: dts: qcom: hamoa: add Coresight nodes for APSS debug block
>>
>> Yuanfang Zhang (11):
>>    dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property
>>    coresight: Pass trace mode to link enable callback
>>    coresight-funnel: Support CPU cluster funnel initialization
>>    coresight-funnel: Defer probe when associated CPUs are offline
>>    coresight-replicator: Support CPU cluster replicator initialization
>>    coresight-replicator: Defer probe when associated CPUs are offline
>>    coresight-replicator: Update management interface for CPU-bound devices
>>    coresight-tmc: Support probe and initialization for CPU cluster TMCs
>>    coresight-tmc-etf: Refactor enable function for CPU cluster ETF support
>>    coresight-tmc: Update management interface for CPU-bound TMCs
>>    coresight-tmc: Defer probe when associated CPUs are offline
>>
>> Verification:
>>
>> This series has been verified on sm8750.
>>
>> Test steps for delay probe:
>>
>> 1. limit the system to enable at most 6 CPU cores during boot.
>> 2. echo 1 >/sys/bus/cpu/devices/cpu6/online.
>> 3. check whether ETM6 and ETM7 have been probed.
>>
>> Test steps for sysfs mode:
>>
>> echo 1 >/sys/bus/coresight/devices/tmc_etf0/enable_sink
>> echo 1 >/sys/bus/coresight/devices/etm0/enable_source
>> echo 1 >/sys/bus/coresight/devices/etm6/enable_source
>> echo 0 >/sys/bus/coresight/devices/etm0/enable_source
>> echo 0 >/sys/bus/coresight/devicse/etm6/enable_source
>> echo 0 >/sys/bus/coresight/devices/tmc_etf0/enable_sink
>>
>> echo 1 >/sys/bus/coresight/devices/tmc_etf1/enable_sink
>> echo 1 >/sys/bus/coresight/devcies/etm0/enable_source
>> cat /dev/tmc_etf1 >/tmp/etf1.bin
>> echo 0 >/sys/bus/coresight/devices/etm0/enable_source
>> echo 0 >/sys/bus/coresight/devices/tmc_etf1/enable_sink
>>
>> echo 1 >/sys/bus/coresight/devices/tmc_etf2/enable_sink
>> echo 1 >/sys/bus/coresight/devices/etm6/enable_source
>> cat /dev/tmc_etf2 >/tmp/etf2.bin
>> echo 0 >/sys/bus/coresight/devices/etm6/enable_source
>> echo 0 >/sys/bus/coresight/devices/tmc_etf2/enable_sink
>>
>> Test steps for sysfs node:
>>
>> cat /sys/bus/coresight/devices/tmc_etf*/mgmt/*
>>
>> cat /sys/bus/coresight/devices/funnel*/funnel_ctrl
>>
>> cat /sys/bus/coresight/devices/replicator*/mgmt/*
>>
>> Test steps for perf mode:
>>
>> perf record -a -e cs_etm//k -- sleep 5
>>
>> Signed-off-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>
>> ---
>> Changes in v2:
>> - Use the qcom,cpu-bound-components device tree property to identify devices
>>    bound to a cluster.
>> - Refactor commit message.
>> - Introduce a supported_cpus field in the drvdata structure to record the CPUs
>>    that belong to the cluster where the local component resides.
>> - Link to v1: https://lore.kernel.org/r/20251027-cpu_cluster_component_pm-v1-0-31355ac588c2@oss.qualcomm.com
>>
>> ---
>> Jie Gan (1):
>>        arm64: dts: qcom: hamoa: Add CoreSight nodes for APSS debug block
>>
>> Yuanfang Zhang (11):
>>        dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property
>>        coresight-funnel: Support CPU cluster funnel initialization
>>        coresight-funnel: Defer probe when associated CPUs are offline
>>        coresight-replicator: Support CPU cluster replicator initialization
>>        coresight-replicator: Defer probe when associated CPUs are offline
>>        coresight-replicator: Update management interface for CPU-bound devices
>>        coresight-tmc: Support probe and initialization for CPU cluster TMCs
>>        coresight-tmc-etf: Refactor enable function for CPU cluster ETF support
>>        coresight-tmc: Update management interface for CPU-bound TMCs
>>        coresight-tmc: Defer probe when associated CPUs are offline
>>        coresight: Pass trace mode to link enable callback
>>
>>   .../bindings/arm/arm,coresight-dynamic-funnel.yaml |   5 +
>>   .../arm/arm,coresight-dynamic-replicator.yaml      |   5 +
>>   .../devicetree/bindings/arm/arm,coresight-tmc.yaml |   5 +
>>   arch/arm64/boot/dts/qcom/hamoa.dtsi                | 926 +++++++++++++++++++++
>>   arch/arm64/boot/dts/qcom/purwa.dtsi                |  12 +
>>   drivers/hwtracing/coresight/coresight-core.c       |   7 +-
>>   drivers/hwtracing/coresight/coresight-funnel.c     | 258 +++++-
>>   drivers/hwtracing/coresight/coresight-replicator.c | 341 +++++++-
>>   drivers/hwtracing/coresight/coresight-tmc-core.c   | 387 +++++++--
>>   drivers/hwtracing/coresight/coresight-tmc-etf.c    | 106 ++-
>>   drivers/hwtracing/coresight/coresight-tmc.h        |  10 +
>>   drivers/hwtracing/coresight/coresight-tnoc.c       |   3 +-
>>   drivers/hwtracing/coresight/coresight-tpda.c       |   3 +-
>>   include/linux/coresight.h                          |   3 +-
>>   14 files changed, 1902 insertions(+), 169 deletions(-)
>> ---
>> base-commit: 008d3547aae5bc86fac3eda317489169c3fda112
>> change-id: 20251016-cpu_cluster_component_pm-ce518f510433
>>
>> Best regards,
> 

On 18/12/2025 16:18, yuanfang zhang wrote:
> 
> 
> On 12/18/2025 5:32 PM, Suzuki K Poulose wrote:
>> Cc: Sudeep
>>
>> On 18/12/2025 08:09, Yuanfang Zhang wrote:
>>> This patch series adds support for CoreSight components local to CPU clusters,
>>> including funnel, replicator, and TMC, which reside within CPU cluster power
>>> domains. These components require special handling due to power domain
>>> constraints.
>>>
>>> Unlike system-level CoreSight devices, these components share the CPU cluster's
>>> power domain. When the cluster enters low-power mode (LPM), their registers
>>> become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster
>>> out of LPM, making standard register access unreliable.
>>
>> Why ? AFAIU, we have ways to tie the power-domain to that of the cluster
>> and that can auto-magically keep the cluster power ON as long as you
>> want to use them.
>>
>> Suzuki
>>
> Hi Suzuki
> 
> 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.

Why does it need to wake up the CPU ? The firmware can power up the
cluster right? Anyways, to me this all looks like working around a
firmware issue. I will let you sort this out with Sudeep's response
, as I am not an expert on the cluster powermanagement and standards.

Suzuki



> 
> Yuanfang
> 
>>
>>>
>>> To address this, the series introduces:
>>> - Identifying cluster-bound devices via a new `qcom,cpu-bound-components`
>>>     device tree property.
>>> - Implementing deferred probing: if associated CPUs are offline during
>>>     probe, initialization is deferred until a CPU hotplug notifier detects
>>>     the CPU coming online.
>>> - Utilizing `smp_call_function_single()` to ensure register accesses
>>>     (initialization, enablement, sysfs reads) are always executed on a
>>>     powered CPU within the target cluster.
>>> - Extending the CoreSight link `enable` callback to pass the `cs_mode`.
>>>     This allows drivers to distinguish between SysFS and Perf modes and
>>>     apply mode-specific logic.
>>>
>>> Jie Gan (1):
>>>     arm64: dts: qcom: hamoa: add Coresight nodes for APSS debug block
>>>
>>> Yuanfang Zhang (11):
>>>     dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property
>>>     coresight: Pass trace mode to link enable callback
>>>     coresight-funnel: Support CPU cluster funnel initialization
>>>     coresight-funnel: Defer probe when associated CPUs are offline
>>>     coresight-replicator: Support CPU cluster replicator initialization
>>>     coresight-replicator: Defer probe when associated CPUs are offline
>>>     coresight-replicator: Update management interface for CPU-bound devices
>>>     coresight-tmc: Support probe and initialization for CPU cluster TMCs
>>>     coresight-tmc-etf: Refactor enable function for CPU cluster ETF support
>>>     coresight-tmc: Update management interface for CPU-bound TMCs
>>>     coresight-tmc: Defer probe when associated CPUs are offline
>>>
>>> Verification:
>>>
>>> This series has been verified on sm8750.
>>>
>>> Test steps for delay probe:
>>>
>>> 1. limit the system to enable at most 6 CPU cores during boot.
>>> 2. echo 1 >/sys/bus/cpu/devices/cpu6/online.
>>> 3. check whether ETM6 and ETM7 have been probed.
>>>
>>> Test steps for sysfs mode:
>>>
>>> echo 1 >/sys/bus/coresight/devices/tmc_etf0/enable_sink
>>> echo 1 >/sys/bus/coresight/devices/etm0/enable_source
>>> echo 1 >/sys/bus/coresight/devices/etm6/enable_source
>>> echo 0 >/sys/bus/coresight/devices/etm0/enable_source
>>> echo 0 >/sys/bus/coresight/devicse/etm6/enable_source
>>> echo 0 >/sys/bus/coresight/devices/tmc_etf0/enable_sink
>>>
>>> echo 1 >/sys/bus/coresight/devices/tmc_etf1/enable_sink
>>> echo 1 >/sys/bus/coresight/devcies/etm0/enable_source
>>> cat /dev/tmc_etf1 >/tmp/etf1.bin
>>> echo 0 >/sys/bus/coresight/devices/etm0/enable_source
>>> echo 0 >/sys/bus/coresight/devices/tmc_etf1/enable_sink
>>>
>>> echo 1 >/sys/bus/coresight/devices/tmc_etf2/enable_sink
>>> echo 1 >/sys/bus/coresight/devices/etm6/enable_source
>>> cat /dev/tmc_etf2 >/tmp/etf2.bin
>>> echo 0 >/sys/bus/coresight/devices/etm6/enable_source
>>> echo 0 >/sys/bus/coresight/devices/tmc_etf2/enable_sink
>>>
>>> Test steps for sysfs node:
>>>
>>> cat /sys/bus/coresight/devices/tmc_etf*/mgmt/*
>>>
>>> cat /sys/bus/coresight/devices/funnel*/funnel_ctrl
>>>
>>> cat /sys/bus/coresight/devices/replicator*/mgmt/*
>>>
>>> Test steps for perf mode:
>>>
>>> perf record -a -e cs_etm//k -- sleep 5
>>>
>>> Signed-off-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>
>>> ---
>>> Changes in v2:
>>> - Use the qcom,cpu-bound-components device tree property to identify devices
>>>     bound to a cluster.
>>> - Refactor commit message.
>>> - Introduce a supported_cpus field in the drvdata structure to record the CPUs
>>>     that belong to the cluster where the local component resides.
>>> - Link to v1: https://lore.kernel.org/r/20251027-cpu_cluster_component_pm-v1-0-31355ac588c2@oss.qualcomm.com
>>>
>>> ---
>>> Jie Gan (1):
>>>         arm64: dts: qcom: hamoa: Add CoreSight nodes for APSS debug block
>>>
>>> Yuanfang Zhang (11):
>>>         dt-bindings: arm: coresight: Add 'qcom,cpu-bound-components' property
>>>         coresight-funnel: Support CPU cluster funnel initialization
>>>         coresight-funnel: Defer probe when associated CPUs are offline
>>>         coresight-replicator: Support CPU cluster replicator initialization
>>>         coresight-replicator: Defer probe when associated CPUs are offline
>>>         coresight-replicator: Update management interface for CPU-bound devices
>>>         coresight-tmc: Support probe and initialization for CPU cluster TMCs
>>>         coresight-tmc-etf: Refactor enable function for CPU cluster ETF support
>>>         coresight-tmc: Update management interface for CPU-bound TMCs
>>>         coresight-tmc: Defer probe when associated CPUs are offline
>>>         coresight: Pass trace mode to link enable callback
>>>
>>>    .../bindings/arm/arm,coresight-dynamic-funnel.yaml |   5 +
>>>    .../arm/arm,coresight-dynamic-replicator.yaml      |   5 +
>>>    .../devicetree/bindings/arm/arm,coresight-tmc.yaml |   5 +
>>>    arch/arm64/boot/dts/qcom/hamoa.dtsi                | 926 +++++++++++++++++++++
>>>    arch/arm64/boot/dts/qcom/purwa.dtsi                |  12 +
>>>    drivers/hwtracing/coresight/coresight-core.c       |   7 +-
>>>    drivers/hwtracing/coresight/coresight-funnel.c     | 258 +++++-
>>>    drivers/hwtracing/coresight/coresight-replicator.c | 341 +++++++-
>>>    drivers/hwtracing/coresight/coresight-tmc-core.c   | 387 +++++++--
>>>    drivers/hwtracing/coresight/coresight-tmc-etf.c    | 106 ++-
>>>    drivers/hwtracing/coresight/coresight-tmc.h        |  10 +
>>>    drivers/hwtracing/coresight/coresight-tnoc.c       |   3 +-
>>>    drivers/hwtracing/coresight/coresight-tpda.c       |   3 +-
>>>    include/linux/coresight.h                          |   3 +-
>>>    14 files changed, 1902 insertions(+), 169 deletions(-)
>>> ---
>>> base-commit: 008d3547aae5bc86fac3eda317489169c3fda112
>>> change-id: 20251016-cpu_cluster_component_pm-ce518f510433
>>>
>>> Best regards,
>>
> 

On Thu, Dec 18, 2025 at 05:04:07PM +0000, Suzuki K Poulose wrote:
> On 18/12/2025 16:18, yuanfang zhang wrote:
> > 
> > On 12/18/2025 5:32 PM, Suzuki K Poulose wrote:
> > > Cc: Sudeep
> > > 
> > > On 18/12/2025 08:09, Yuanfang Zhang wrote:
> > > > This patch series adds support for CoreSight components local to CPU clusters,
> > > > including funnel, replicator, and TMC, which reside within CPU cluster power
> > > > domains. These components require special handling due to power domain
> > > > constraints.
> > > > 
> > > > Unlike system-level CoreSight devices, these components share the CPU cluster's
> > > > power domain. When the cluster enters low-power mode (LPM), their registers
> > > > become inaccessible. Notably, `pm_runtime_get` alone cannot bring the cluster
> > > > out of LPM, making standard register access unreliable.
> > > 
> > > Why ? AFAIU, we have ways to tie the power-domain to that of the cluster
> > > and that can auto-magically keep the cluster power ON as long as you
> > > want to use them.
> > > 
> > > Suzuki
> > > 
> > Hi Suzuki
> > 
> > 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.
> 
> Why does it need to wake up the CPU ? The firmware can power up the
> cluster right? Anyways, to me this all looks like working around a
> firmware issue. I will let you sort this out with Sudeep's response
> , as I am not an expert on the cluster powermanagement and standards.
> 

Indeed smells like a some workaround, will respond in another email in the
thread to capture other points as well.

-- 
Regards,
Sudeep