Re: [PATCH 2/7] irqchip/irq-qcom-mpm: Register MPM under CPU cluster power domain

[Konrad Dybcio]

On 7/15/26 12:34 PM, Stephan Gerhold wrote:
> On Wed, Jul 15, 2026 at 11:46:58AM +0200, Konrad Dybcio wrote:
>> On 7/13/26 12:25 PM, Sneh Mankad wrote:
>>> MPM irqchip needs to notify RPM (Resource Power Manager) processor to read
>>> the latest wake up capable interrupts when the CPU cluster is entering the
>>> deepest idle state. This is done by sending IPC interrupt to RPM and is
>>> implemented as .power_off() callback by registering MPM as parent power
>>> domain to CPU cluster.
>>
>> [...]
>>
>>> If MPM has not registered with CPU cluster power domain, utilize the CPU PM
>>> notifications to manage RPM communication when the last CPU goes to power
>>> collapse.
>>
>> I have mixed feelings about this case. The RPMH RSC driver keeps that as a
>> fallback for platforms which don't have PSCI OSI mode specifically.
>>
>> On the other hand, there are platforms (early arm64 - pre-msm8996 and almost
>> all of the arm32 platforms) that don't define any CPU power domains, so
>> perhaps it's necessary after all..
>>
> 
> I don't think this fallback is relevant for the non-PSCI QC platforms,
> for the following reasons:
> 
>  - They don't define the MPM.
>  - They don't support cluster idle upstream, so they don't need to
>    define the MPM. They can't reach the idle state where it would become
>    relevant.
>  - The setup for cluster idle without PSCI is essentially equivalent to
>    OSI, except that the SPM/SAW driver needs to program the idle state
>    to enter. There is one SPM/SAW for every idle domain (e.g. on
>    MSM8939: 2x4 CPU, 2x Cluster, 1x System). You can just model the
>    SPM/SAW instances as power domains to get the same setup as PSCI OSI
>    (I had a draft for this at some point). So if someone ever implements
>    this, we should be able to use the same approach as for PSCI OSI.

Yeah I said 'necessary' because of the arm32 platforms. This would probably
be the preferable way forward.

> I'm not aware of non-OSI PSCI platforms with MPM either, so I'm not sure
> when this fallback would be used.

I think it's generally only SC7180 and there's definitely no MPM there.

> We probably do need some fallback for the old sm6375/agatii DTBs though.

The sleep logic doesn't really matter without the platforms hitting a
specific power state anyway, so I'm not sure we actually have to (i.e.
the regressed path can't be exercised today anyway)

Konrad