Re: [PATCH 3/3] arm64: dts: qcom: qcm2290: Hook up MPM

[Ulf Hansson]

On Thu, Jul 9, 2026 at 1:41 PM Marek Szyprowski
<m.szyprowski@xxxxxxxxxxx> wrote:
>
> On 15.12.2023 01:01, Konrad Dybcio wrote:
> > Wire up MPM and the interrupts it provides.
> >
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
> > ---
> >  arch/arm64/boot/dts/qcom/qcm2290.dtsi | 42 +++++++++++++++++++++++++++++------
> >  1 file changed, 35 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/qcm2290.dtsi b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
> > index ce04d0acdede..0911fb08ed63 100644
> > --- a/arch/arm64/boot/dts/qcom/qcm2290.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/qcm2290.dtsi
> > @@ -199,6 +199,7 @@ CPU_PD3: power-domain-cpu3 {
> >
> >               CLUSTER_PD: power-domain-cpu-cluster {
> >                       #power-domain-cells = <0>;
> > +                     power-domains = <&mpm>;
> >                       domain-idle-states = <&CLUSTER_SLEEP>;
> >               };
> >       };
>
>
> This patch landed long time ago in mainline as commit e3f6a6994041
> ("arm64: dts: qcom: qcm2290: Hook up MPM").

Without detailed HW expertise (still learning about the UnoQ), it
looks to me that the HW may have been modelled upside down.

The power-domain-cpu-cluster should probably *not* be the consumer of
the mpm, but rather the opposite. This is how qcom,rpmh-rsc works, for
example.

>
> Recently I've added Arduino UnoQ board
> (arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts) to my test farm
> and found that this patch is responsible for the "Invalid wait context"
> warning [1] observed during boot of the recent kernels when
> CONFIG_PROVE_RAW_LOCK_NESTING is set (which is implicitly true when
> CONFIG_PROVE_LOCKING is set since commit d8fccd9ca5f90). This shows
> a real problem if one wants to run RT-enabled kernel.
>
> This is because the above chunk adds the "mpm" as a parent power domain
> to the "cluster_pd" (in current arch/arm64/boot/dts/qcom/agatti.dtsi).
> "cluster_pd" is initialized as "GENPD_FLAG_IRQ_SAFE | GENPD_FLAG_CPU_DOMAIN"
> (see psci_pd_init in drivers/cpuidle/cpuidle-psci-domain.c, which use
> raw_spinlock_t based locking), while the "mpm" power domain only as
> "GENPD_FLAG_IRQ_SAFE" (see qcom_mpm_probe in drivers/irqchip/irq-qcom-mpm.c,
> which use spinlock_t locking).
>
> I've check and there is no easy way to make the "mpm" power domain
> GENPD_FLAG_CPU_DOMAIN compatible. drivers/irqchip/irq-qcom-mpm.c driver
> uses mbox API, which internally uses spinlock_t based locking. Then
> there is a drivers/mailbox/qcom-apcs-ipc-mailbox.c driver and even
> more dependencies: mmio regmap, clocks and probably more (I've didn't
> check further).

Yep, this wont work.

>
> The question is how to solve this issue? Is this dependency really
> required? Would it work if the "mpm" power domain is set as always
> on and genpd framework extended to support such case without
> triggering lockdep warning (it already has support for irq-safe
> device in non-irq-safe power domain)?
>

I think the whole thing just "works" if we make the mpm a consumer of
the cluster-pd instead, which probably also is the right way to model
the HW.

For "last man activities" (before the cluster-pd turns off), the mpm
driver may register genpd on/off notifiers with
dev_pm_genpd_add_notifier(), similar to drivers/soc/qcom/rpmh-rsc.c.

[...]

Kind regards
Uffe