[PATCH v2 00/12] coresight: Add CPU cluster funnel/replicator/tmc support

[Ulf Hansson]

+ linux-pm

On Thu, Jul 23, 2026 at 3:45 PM Sudeep Holla <sudeep.holla at kernel.org> wrote:
>
> On Mon, May 25, 2026 at 06:47:27PM +0530, Maulik Shah (mkshah) wrote:
> >
> >
> > On 12/19/2025 3:51 PM, 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?
> >
> > Sorry for coming very late on this.
> >
> > This series is intended to handle coresight components which resides within CPU cluster.
> > For the cases where cluster is in deepest idle low power mode or all CPUs belonging to cluster
> > are hotplugged off, access to coresight components can not be done.
> >
>
> Sure, but the question is why is the cluster entering deepest idle state if
> coresight is in use ?
>
> > The implementation tried to address in two parts,
> > 1. Using cluster power-domain to know which coresight component belongs to which cluster/CPUs
>
> OK
>
> > 2. Schedule the task on intended cluster's CPU to make sure the CPU (and cluster) power is
> > ON while coresight component of the cluster is being accessed (using smp_call_function_single()).
> >
>
> Why, just block any cluster entering deeper idle state when corresponding
> coresight component is in use. This should be taken care automatically.
>
> > The use of power-domains in (1) will limit this to PSCI OS-Initiated mode,
>
> Yes
>
> > to have this support on PSCI Platform-Coordinated mode too, probably instead of power-domains,
> > cpu-maps (which also defines the clusters) from device tree is a better choice which will give
> > the information on which CPU belongs to which cluster.
> >
>
> No, let the platform deal with it. And the whole OSI mode was pushed giving
> such use-case as example and now you are telling you want to solve the problem
> for PC mode. I am confused. Just use OSI.
>
> > (2) ensured that scheduling happened on intended CPU and while the access is in progress, CPU (and
> > cluster) will not enter power down in between.
> >
>
> No, just block entering that state in OS(for OSI) and in the platform(for PC)
>
> > >
> > >> 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?
> >
> > Yes, This is to ensure that CPU (and cluster) power is ON while coresight components
> > for same cluster are being accessed.
> >
>
> Or just don't turn off cluster if coresight is enabled and in use.
>
> > >
> > > 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?
> >
> > Cluster power-domains will be only available for PSCI OS-initiated mode but also
> > will not help for cases where all CPUs in cluster are hotplugged off as hotplugs are
> > platform coordinated.
> >
>
> See above, let platform deal with it. It is called PC for that reason.

I agree. If PC mode is used, then the FW should manage this through
another channel, like SCMI for example.

>
> > After discussion with our HW team to automatically request power on for coresight
> > component GPR [1] can be used but they seems not working as intended on the existing
> > SoCs and will be available on next generation SoC.
> >
> > [1] https://developer.arm.com/documentation/ddi0480/d/Functional-Overview/Granular-Power-Requestor
> >
>
> You are looking at it from wrong side as you allowed cluster to power down
> when the coresight in the cluster power domain was still in use, right ?

This coresight part that is about to be configured for profiling
belongs to one CPU cluster. The current CPU we are running on when
starting the configuration, belongs to another cluster.

Hence, the cluster that contains the CPU for profiling may be turned
off. See more below.

>
> > >
> > > 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.
> > >
> >
> > please see below comment for more details, This seems not a firmware issue.
> >
> > >>>
> > >>>> 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?
> >
> > + Ulf in loop.
> >
> > Current platforms with OSI enabled, Linux PSCI do not implement the power_on/power_off
> > requests, as far as i know, runtime PM was never meant to implement this part and
> > pm_runtime_get_sync() (from drivers/cpuidle/cpuidle-psci.c) call is only used to convey
> > to cluster power domains about a child CPU/ sub domain being on after it has already
> > been landed in Linux.
> >
>
> When a shared power domain has one of the consumer active, why is the power
> domain being turned off. OSI is supposed to handle that, I still don't
> understand what am I missing ?
>
> > The standalone invoke of pm_runtime_get_sync() from another CPU do not really turn on/get
> > the CPU (and cluster), as the CPUs either use CPUidle / CPU hotplug paths to enter/exit
> > low power mode.

This is the main problem!

Calling pm_runtime_get_sync() on a device, doesn't necessarily power
on the CPU PM domain (cluster) it belongs to.

At the moment pm_runtime_get_sync(), for CPU PM domains, only
guarantees that an already powered-on CPU PM domain stays powered on
if it's already on.

I am working on a patch to fix this in a generic way, I will keep you posted.

[...]

Kind regards
Uffe