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