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

[Yuanfang Zhang]

Hi Sudeep & Suzuki,

Gentle reminder on this patch series. Please let me know if you have any concerns or suggestions.

Thanks, Yuanfang

On 6/29/2026 1:55 PM, Yuanfang Zhang wrote:
> Hi Sudeep & Suzuki,
> 
> Gentle reminder on this patch. Any feedback would be appreciated.
> 
> Thanks,
> Yuanfang.
> 
> On 5/25/2026 9:17 PM, 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.
>>
>> The implementation tried to address in two parts,
>> 1. Using cluster power-domain to know which coresight component belongs to which cluster/CPUs
>> 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()).
>>
>> The use of power-domains in (1) will limit this to PSCI OS-Initiated mode,
>> 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.
>>
>> (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.
>>
>>>
>>>> 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.
>>
>>>
>>> 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.
>>
>> 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
>>
>>>
>>> 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.
>>
>> 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.
>>
>> To put it other way,
>> For a hot-plugged off CPU, invoking a pm_runtime_get_sync() won't get the CPU (and make
>> its cluster power domain) ON. In order to turn on the CPU, one has to still request
>> the online of the CPU, say via sysfs command echo 1 > /sys/devices/system/cpu/cpuX/online
>> which would invoke PSCI CPU_ON function and the power domain for CPU gets marked as ON
>> only after CPU already landed in Linux via psci_idle_cpuhp_up() invoking pm_runtime_get_sync().
>>
>> I used specific hotplug example but same applies to idle powered down CPU (or Cluster) too.
>>
>>>
>>>>>> 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.
>>>
>>
>> Explained above.
>>
>> Thanks,
>> Maulik
>