* [PATCH 1/3] arm64: dts: qcom: sm6375: Hook up MPM
2023-12-15 0:01 [PATCH 0/3] MPM hooking upping Konrad Dybcio
@ 2023-12-15 0:01 ` Konrad Dybcio
2023-12-15 0:01 ` [PATCH 2/3] arm64: dts: qcom: msm8996: " Konrad Dybcio
` (2 subsequent siblings)
3 siblings, 0 replies; 12+ messages in thread
From: Konrad Dybcio @ 2023-12-15 0:01 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio
Add a node for MPM and wire it up on consumers that use it. This also
fixes a very bad and sad assumption I made when initially porting this
SoC that the downstream MPM-TLMM mappings were 1-1. That apparently
changed some time ago, so with this patch the MPM consumers will actually
be hooked up to the correct interrupt lines.
Fixes: 59d34ca97f91 ("arm64: dts: qcom: Add initial device tree for SM6375")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
arch/arm64/boot/dts/qcom/sm6375.dtsi | 41 ++++++++++++++++++++++++++++++------
1 file changed, 34 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm6375.dtsi b/arch/arm64/boot/dts/qcom/sm6375.dtsi
index 331bd98dbfde..7ac8bf26dda3 100644
--- a/arch/arm64/boot/dts/qcom/sm6375.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6375.dtsi
@@ -311,6 +311,25 @@ scm {
};
};
+ mpm: interrupt-controller {
+ compatible = "qcom,mpm";
+ qcom,rpm-msg-ram = <&apss_mpm>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&ipcc IPCC_CLIENT_AOP IPCC_MPROC_SIGNAL_SMP2P>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #power-domain-cells = <0>;
+ interrupt-parent = <&intc>;
+ qcom,mpm-pin-count = <96>;
+ qcom,mpm-pin-map = <5 296>, /* Soundwire wake_irq */
+ <12 422>, /* DWC3 ss_phy_irq */
+ <86 183>, /* MPM wake, SPMI */
+ <89 314>, /* TSENS0 0C */
+ <90 315>, /* TSENS1 0C */
+ <93 164>, /* DWC3 dm_hs_phy_irq */
+ <94 165>; /* DWC3 dp_hs_phy_irq */
+ };
+
memory@80000000 {
device_type = "memory";
/* We expect the bootloader to fill in the size */
@@ -486,6 +505,7 @@ CPU_PD7: power-domain-cpu7 {
CLUSTER_PD: power-domain-cpu-cluster0 {
#power-domain-cells = <0>;
+ power-domains = <&mpm>;
domain-idle-states = <&CLUSTER_SLEEP_0>;
};
};
@@ -808,7 +828,7 @@ tlmm: pinctrl@500000 {
reg = <0 0x00500000 0 0x800000>;
interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
gpio-ranges = <&tlmm 0 0 157>;
- /* TODO: Hook up MPM as wakeup-parent when it's there */
+ wakeup-parent = <&mpm>;
interrupt-controller;
gpio-controller;
#interrupt-cells = <2>;
@@ -960,7 +980,7 @@ spmi_bus: spmi@1c40000 {
<0 0x01c0a000 0 0x26000>;
reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
interrupt-names = "periph_irq";
- interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts-extended = <&mpm 86 IRQ_TYPE_LEVEL_HIGH>;
qcom,ee = <0>;
qcom,channel = <0>;
#address-cells = <2>;
@@ -992,8 +1012,15 @@ tsens1: thermal-sensor@4413000 {
};
rpm_msg_ram: sram@45f0000 {
- compatible = "qcom,rpm-msg-ram";
+ compatible = "qcom,rpm-msg-ram", "mmio-sram";
reg = <0 0x045f0000 0 0x7000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x045f0000 0x7000>;
+
+ apss_mpm: sram@1b8 {
+ reg = <0x1b8 0x48>;
+ };
};
sram@4690000 {
@@ -1403,10 +1430,10 @@ usb_1: usb@4ef8800 {
<&gcc GCC_USB30_PRIM_MASTER_CLK>;
assigned-clock-rates = <19200000>, <133333333>;
- interrupts = <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 93 IRQ_TYPE_EDGE_BOTH>,
- <GIC_SPI 94 IRQ_TYPE_EDGE_BOTH>;
+ interrupts-extended = <&intc GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>,
+ <&mpm 12 IRQ_TYPE_LEVEL_HIGH>,
+ <&mpm 93 IRQ_TYPE_EDGE_BOTH>,
+ <&mpm 94 IRQ_TYPE_EDGE_BOTH>;
interrupt-names = "hs_phy_irq",
"ss_phy_irq",
"dm_hs_phy_irq",
--
2.40.1
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH 2/3] arm64: dts: qcom: msm8996: Hook up MPM
2023-12-15 0:01 [PATCH 0/3] MPM hooking upping Konrad Dybcio
2023-12-15 0:01 ` [PATCH 1/3] arm64: dts: qcom: sm6375: Hook up MPM Konrad Dybcio
@ 2023-12-15 0:01 ` Konrad Dybcio
2023-12-15 0:01 ` [PATCH 3/3] arm64: dts: qcom: qcm2290: " Konrad Dybcio
2023-12-17 17:21 ` [PATCH 0/3] MPM hooking upping Bjorn Andersson
3 siblings, 0 replies; 12+ messages in thread
From: Konrad Dybcio @ 2023-12-15 0:01 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio
Wire up MPM and the interrupts it provides.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 39 +++++++++++++++++++++++++++++------
1 file changed, 33 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 35a0d2a69711..11e3fe4f342f 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -444,6 +444,25 @@ memory@80000000 {
reg = <0x0 0x80000000 0x0 0x0>;
};
+ mpm: interrupt-controller {
+ compatible = "qcom,mpm";
+ qcom,rpm-msg-ram = <&apss_mpm>;
+ interrupts = <GIC_SPI 171 IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&apcs_glb 1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #power-domain-cells = <0>;
+ interrupt-parent = <&intc>;
+ qcom,mpm-pin-count = <96>;
+ qcom,mpm-pin-map = <2 184>, /* TSENS1 upper_lower_int */
+ <52 243>, /* DWC3_PRI ss_phy_irq */
+ <79 347>, /* DWC3_PRI hs_phy_irq */
+ <80 352>, /* DWC3_SEC hs_phy_irq */
+ <81 347>, /* QUSB2_PHY_PRI DP+DM */
+ <82 352>, /* QUSB2_PHY_SEC DP+DM */
+ <87 326>; /* SPMI */
+ };
+
psci {
compatible = "arm,psci-1.0";
method = "smc";
@@ -733,8 +752,15 @@ pciephy_2: phy@3000 {
};
rpm_msg_ram: sram@68000 {
- compatible = "qcom,rpm-msg-ram";
+ compatible = "qcom,rpm-msg-ram", "mmio-sram";
reg = <0x00068000 0x6000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x00068000 0x7000>;
+
+ apss_mpm: sram@1b8 {
+ reg = <0x1b8 0x48>;
+ };
};
qfprom@74000 {
@@ -820,8 +846,8 @@ tsens1: thermal-sensor@4ad000 {
reg = <0x004ad000 0x1000>, /* TM */
<0x004ac000 0x1000>; /* SROT */
#qcom,sensors = <8>;
- interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts-extended = <&mpm 2 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc GIC_SPI 430 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "uplow", "critical";
#thermal-sensor-cells = <1>;
};
@@ -1343,6 +1369,7 @@ tlmm: pinctrl@1010000 {
interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
gpio-ranges = <&tlmm 0 0 150>;
+ wakeup-parent = <&mpm>;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
@@ -1870,7 +1897,7 @@ spmi_bus: spmi@400f000 {
<0x0400a000 0x002100>;
reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
interrupt-names = "periph_irq";
- interrupts = <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts-extended = <&mpm 87 IRQ_TYPE_LEVEL_HIGH>;
qcom,ee = <0>;
qcom,channel = <0>;
#address-cells = <2>;
@@ -3026,8 +3053,8 @@ usb3: usb@6af8800 {
#size-cells = <1>;
ranges;
- interrupts = <GIC_SPI 347 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts-extended = <&mpm 79 IRQ_TYPE_LEVEL_HIGH>,
+ <&mpm 52 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "hs_phy_irq", "ss_phy_irq";
clocks = <&gcc GCC_SYS_NOC_USB3_AXI_CLK>,
--
2.40.1
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH 3/3] arm64: dts: qcom: qcm2290: Hook up MPM
2023-12-15 0:01 [PATCH 0/3] MPM hooking upping Konrad Dybcio
2023-12-15 0:01 ` [PATCH 1/3] arm64: dts: qcom: sm6375: Hook up MPM Konrad Dybcio
2023-12-15 0:01 ` [PATCH 2/3] arm64: dts: qcom: msm8996: " Konrad Dybcio
@ 2023-12-15 0:01 ` Konrad Dybcio
2026-07-09 11:41 ` Marek Szyprowski
2023-12-17 17:21 ` [PATCH 0/3] MPM hooking upping Bjorn Andersson
3 siblings, 1 reply; 12+ messages in thread
From: Konrad Dybcio @ 2023-12-15 0:01 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio
Wire up MPM and the interrupts it provides.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
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>;
};
};
@@ -266,6 +267,24 @@ rpmpd_opp_turbo_plus: opp8 {
};
};
};
+
+ mpm: interrupt-controller {
+ compatible = "qcom,mpm";
+ qcom,rpm-msg-ram = <&apss_mpm>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&apcs_glb 1>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #power-domain-cells = <0>;
+ interrupt-parent = <&intc>;
+ qcom,mpm-pin-count = <96>;
+ qcom,mpm-pin-map = <2 275>, /* TSENS0 uplow */
+ <5 296>, /* Soundwire master_irq */
+ <12 422>, /* DWC3 ss_phy_irq */
+ <24 79>, /* Soundwire wake_irq */
+ <86 183>, /* MPM wake, SPMI */
+ <90 260>; /* QUSB2_PHY DP+DM */
+ };
};
reserved_memory: reserved-memory {
@@ -429,6 +448,7 @@ tlmm: pinctrl@500000 {
interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
gpio-ranges = <&tlmm 0 0 127>;
+ wakeup-parent = <&mpm>;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
@@ -778,7 +798,7 @@ spmi_bus: spmi@1c40000 {
"obsrvr",
"intr",
"cnfg";
- interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts-extended = <&mpm 86 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "periph_irq";
qcom,ee = <0>;
qcom,channel = <0>;
@@ -793,8 +813,8 @@ tsens0: thermal-sensor@4411000 {
reg = <0x0 0x04411000 0x0 0x1ff>,
<0x0 0x04410000 0x0 0x8>;
#qcom,sensors = <10>;
- interrupts = <GIC_SPI 275 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
+ interrupts-extended = <&mpm 2 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "uplow", "critical";
#thermal-sensor-cells = <1>;
};
@@ -813,8 +833,15 @@ bimc: interconnect@4480000 {
};
rpm_msg_ram: sram@45f0000 {
- compatible = "qcom,rpm-msg-ram";
+ compatible = "qcom,rpm-msg-ram", "mmio-sram";
reg = <0x0 0x045f0000 0x0 0x7000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x045f0000 0x7000>;
+
+ apss_mpm: sram@1b8 {
+ reg = <0x1b8 0x48>;
+ };
};
sram@4690000 {
@@ -1293,9 +1320,10 @@ &qup_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
usb: usb@4ef8800 {
compatible = "qcom,qcm2290-dwc3", "qcom,dwc3";
reg = <0x0 0x04ef8800 0x0 0x400>;
- interrupts = <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "hs_phy_irq", "ss_phy_irq";
+ interrupts-extended = <&intc GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
+ <&mpm 12 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hs_phy_irq",
+ "ss_phy_irq";
clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
<&gcc GCC_USB30_PRIM_MASTER_CLK>,
--
2.40.1
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH 3/3] arm64: dts: qcom: qcm2290: Hook up MPM
2023-12-15 0:01 ` [PATCH 3/3] arm64: dts: qcom: qcm2290: " Konrad Dybcio
@ 2026-07-09 11:41 ` Marek Szyprowski
2026-07-14 13:04 ` Ulf Hansson
2026-07-14 13:27 ` Maulik Shah (mkshah)
0 siblings, 2 replies; 12+ messages in thread
From: Marek Szyprowski @ 2026-07-09 11:41 UTC (permalink / raw)
To: Konrad Dybcio, Andy Gross, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Ulf Hansson, linux-pm@vger.kernel.org
On 15.12.2023 01:01, Konrad Dybcio wrote:
> Wire up MPM and the interrupts it provides.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
> 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").
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).
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)?
[1] mentioned kernel log :
=============================
[ BUG: Invalid wait context ]
7.2.0-rc2-next-20260708+ #13154 Not tainted
-----------------------------
kworker/u16:1/44 is trying to lock:
ffff000002517870 (&genpd->slock/1){....}-{3:3}, at: genpd_lock_nested_spin+0x1c/0x30
other info that might help us debug this:
context-{5:5}
locks held by kworker/u16:1/44: 5, last CPU#3:
#0: ffff000000032140 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x6a8/0x86c
#1: ffff800080533d90 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1f8/0x86c
#2: ffff00000036c138 (&dev->mutex){....}-{4:4}, at: __device_attach+0x3c/0x1b8
#3: ffffa850a0fca5f8 (gpd_list_lock){+.+.}-{4:4}, at: of_genpd_add_subdomain+0x30/0xc8
#4: ffff000001994750 (&genpd->raw_slock){....}-{2:2}, at: genpd_lock_raw_spin+0x1c/0x30
stack backtrace:
CPU: 3 UID: 0 PID: 44 Comm: kworker/u16:1 Not tainted 7.2.0-rc2-next-20260708+ #13154 PREEMPT
Hardware name: Arduino UnoQ (DT)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
show_stack+0x18/0x24 (C)
dump_stack_lvl+0x90/0xd0
dump_stack+0x18/0x24
__lock_acquire+0xa78/0x22a8
lock_acquire+0x1d8/0x404
_raw_spin_lock_irqsave_nested+0x64/0x8c
genpd_lock_nested_spin+0x1c/0x30
genpd_add_subdomain+0x8c/0x1d8
of_genpd_add_subdomain+0x68/0xc8
dt_idle_pd_init_topology+0x88/0x100
psci_cpuidle_domain_probe+0x1bc/0x31c
platform_probe+0x5c/0xac
really_probe+0xbc/0x298
__driver_probe_device+0x164/0x184
driver_probe_device+0xbc/0x11c
__device_attach_driver+0xb8/0x118
bus_for_each_drv+0x84/0xe4
__device_attach+0xac/0x1b8
device_initial_probe+0x50/0x54
bus_probe_device+0x38/0xa8
deferred_probe_work_func+0x8c/0xc8
process_one_work+0x248/0x86c
worker_thread+0x240/0x388
kthread+0x13c/0x148
ret_from_fork+0x10/0x20
CPUidle PSCI: Initialized CPU PM domain topology using OSI mode
> @@ -266,6 +267,24 @@ rpmpd_opp_turbo_plus: opp8 {
> };
> };
> };
> +
> + mpm: interrupt-controller {
> + compatible = "qcom,mpm";
> + qcom,rpm-msg-ram = <&apss_mpm>;
> + interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>;
> + mboxes = <&apcs_glb 1>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + #power-domain-cells = <0>;
> + interrupt-parent = <&intc>;
> + qcom,mpm-pin-count = <96>;
> + qcom,mpm-pin-map = <2 275>, /* TSENS0 uplow */
> + <5 296>, /* Soundwire master_irq */
> + <12 422>, /* DWC3 ss_phy_irq */
> + <24 79>, /* Soundwire wake_irq */
> + <86 183>, /* MPM wake, SPMI */
> + <90 260>; /* QUSB2_PHY DP+DM */
> + };
> };
>
> reserved_memory: reserved-memory {
> @@ -429,6 +448,7 @@ tlmm: pinctrl@500000 {
> interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>;
> gpio-controller;
> gpio-ranges = <&tlmm 0 0 127>;
> + wakeup-parent = <&mpm>;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> @@ -778,7 +798,7 @@ spmi_bus: spmi@1c40000 {
> "obsrvr",
> "intr",
> "cnfg";
> - interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts-extended = <&mpm 86 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "periph_irq";
> qcom,ee = <0>;
> qcom,channel = <0>;
> @@ -793,8 +813,8 @@ tsens0: thermal-sensor@4411000 {
> reg = <0x0 0x04411000 0x0 0x1ff>,
> <0x0 0x04410000 0x0 0x8>;
> #qcom,sensors = <10>;
> - interrupts = <GIC_SPI 275 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts-extended = <&mpm 2 IRQ_TYPE_LEVEL_HIGH>,
> + <&intc GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "uplow", "critical";
> #thermal-sensor-cells = <1>;
> };
> @@ -813,8 +833,15 @@ bimc: interconnect@4480000 {
> };
>
> rpm_msg_ram: sram@45f0000 {
> - compatible = "qcom,rpm-msg-ram";
> + compatible = "qcom,rpm-msg-ram", "mmio-sram";
> reg = <0x0 0x045f0000 0x0 0x7000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x045f0000 0x7000>;
> +
> + apss_mpm: sram@1b8 {
> + reg = <0x1b8 0x48>;
> + };
> };
>
> sram@4690000 {
> @@ -1293,9 +1320,10 @@ &qup_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
> usb: usb@4ef8800 {
> compatible = "qcom,qcm2290-dwc3", "qcom,dwc3";
> reg = <0x0 0x04ef8800 0x0 0x400>;
> - interrupts = <GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
> - <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
> - interrupt-names = "hs_phy_irq", "ss_phy_irq";
> + interrupts-extended = <&intc GIC_SPI 260 IRQ_TYPE_LEVEL_HIGH>,
> + <&mpm 12 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "hs_phy_irq",
> + "ss_phy_irq";
>
> clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
> <&gcc GCC_USB30_PRIM_MASTER_CLK>,
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 3/3] arm64: dts: qcom: qcm2290: Hook up MPM
2026-07-09 11:41 ` Marek Szyprowski
@ 2026-07-14 13:04 ` Ulf Hansson
2026-07-14 13:29 ` Maulik Shah (mkshah)
2026-07-15 9:28 ` Konrad Dybcio
2026-07-14 13:27 ` Maulik Shah (mkshah)
1 sibling, 2 replies; 12+ messages in thread
From: Ulf Hansson @ 2026-07-14 13:04 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Konrad Dybcio, Andy Gross, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Konrad Dybcio, linux-arm-msm,
devicetree, linux-kernel, Ulf Hansson, linux-pm@vger.kernel.org
On Thu, Jul 9, 2026 at 1:41 PM Marek Szyprowski
<m.szyprowski@samsung.com> 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@linaro.org>
> > ---
> > 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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 3/3] arm64: dts: qcom: qcm2290: Hook up MPM
2026-07-14 13:04 ` Ulf Hansson
@ 2026-07-14 13:29 ` Maulik Shah (mkshah)
2026-07-15 6:14 ` Marek Szyprowski
2026-07-15 9:28 ` Konrad Dybcio
1 sibling, 1 reply; 12+ messages in thread
From: Maulik Shah (mkshah) @ 2026-07-14 13:29 UTC (permalink / raw)
To: Ulf Hansson, Marek Szyprowski
Cc: Konrad Dybcio, Andy Gross, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Konrad Dybcio, linux-arm-msm,
devicetree, linux-kernel, Ulf Hansson, linux-pm@vger.kernel.org
On 7/14/2026 6:34 PM, Ulf Hansson wrote:
> On Thu, Jul 9, 2026 at 1:41 PM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
[...]
> 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.
Agree, There is a series [1] sent out to fix modeling similar to how rpmh-rsc works.
[1] https://lore.kernel.org/lkml/20260713-b4-shikra_lpm_addition-v1-0-3d858df2cbbf@oss.qualcomm.com/
Thanks,
Maulik
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3] arm64: dts: qcom: qcm2290: Hook up MPM
2026-07-14 13:29 ` Maulik Shah (mkshah)
@ 2026-07-15 6:14 ` Marek Szyprowski
2026-07-15 12:37 ` Maulik Shah (mkshah)
0 siblings, 1 reply; 12+ messages in thread
From: Marek Szyprowski @ 2026-07-15 6:14 UTC (permalink / raw)
To: Maulik Shah (mkshah), Ulf Hansson
Cc: Konrad Dybcio, Andy Gross, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Konrad Dybcio, linux-arm-msm,
devicetree, linux-kernel, Ulf Hansson, linux-pm@vger.kernel.org
On 14.07.2026 15:29, Maulik Shah (mkshah) wrote:
> On 7/14/2026 6:34 PM, Ulf Hansson wrote:
>> On Thu, Jul 9, 2026 at 1:41 PM Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
> [...]
>
>> 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.
> Agree, There is a series [1] sent out to fix modeling similar to how rpmh-rsc works.
>
> [1] https://lore.kernel.org/lkml/20260713-b4-shikra_lpm_addition-v1-0-3d858df2cbbf@oss.qualcomm.com/
Indeed that series fixes the modelling issue, but it doesn't change much
from the spinlock vs. raw_spinlock perspective. There is still the
'invalid wait context' issue there, because mbox API cannot be properly
called from cpu_pm_notifier (which use raw_notifier internally):
=============================
[ BUG: Invalid wait context ]
7.2.0-rc3-next-20260714+ #16842 Not tainted
-----------------------------
swapper/3/0 is trying to lock:
ffff0000008ac408 (&chan->lock){....}-{3:3}, at: mbox_send_message+0x3c/0x15c
other info that might help us debug this:
context-{5:5}
locks held by swapper/3/0: 1, last CPU#3:
#0: ffffd99263a61228 (cpu_pm_notifier.lock){....}-{2:2}, at: cpu_pm_enter+0x28/0x78
stack backtrace:
CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 7.2.0-rc3-next-20260714+ #16842 PREEMPT
Hardware name: Arduino UnoQ (DT)
Call trace:
show_stack+0x18/0x24 (C)
dump_stack_lvl+0x8c/0xcc
dump_stack+0x18/0x24
__lock_acquire+0x928/0x1f90
lock_acquire+0x2b8/0x3ec
_raw_spin_lock_irqsave+0x60/0x88
mbox_send_message+0x3c/0x15c
handle_rpm_notification+0x58/0x114
mpm_cpu_pm_callback+0x9c/0xdc
notifier_call_chain+0xa0/0x234
raw_notifier_call_chain_robust+0x48/0xa8
cpu_pm_enter+0x40/0x78
__psci_enter_domain_idle_state.isra.0+0x48/0x470
psci_enter_domain_idle_state+0x18/0x24
cpuidle_enter_state+0xbc/0x428
cpuidle_enter+0x38/0x50
do_idle+0x158/0x324
cpu_startup_entry+0x38/0x3c
secondary_start_kernel+0x138/0x158
__secondary_switched+0xc0/0xc4
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 3/3] arm64: dts: qcom: qcm2290: Hook up MPM
2026-07-15 6:14 ` Marek Szyprowski
@ 2026-07-15 12:37 ` Maulik Shah (mkshah)
0 siblings, 0 replies; 12+ messages in thread
From: Maulik Shah (mkshah) @ 2026-07-15 12:37 UTC (permalink / raw)
To: Marek Szyprowski, Ulf Hansson
Cc: Konrad Dybcio, Andy Gross, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Konrad Dybcio, linux-arm-msm,
devicetree, linux-kernel, Ulf Hansson, linux-pm@vger.kernel.org
On 7/15/2026 11:44 AM, Marek Szyprowski wrote:
> On 14.07.2026 15:29, Maulik Shah (mkshah) wrote:
>> On 7/14/2026 6:34 PM, Ulf Hansson wrote:
>>> On Thu, Jul 9, 2026 at 1:41 PM Marek Szyprowski
>>> <m.szyprowski@samsung.com> wrote:
>> [...]
>>
>>> 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.
>> Agree, There is a series [1] sent out to fix modeling similar to how rpmh-rsc works.
>>
>> [1] https://lore.kernel.org/lkml/20260713-b4-shikra_lpm_addition-v1-0-3d858df2cbbf@oss.qualcomm.com/
> Indeed that series fixes the modelling issue, but it doesn't change much
> from the spinlock vs. raw_spinlock perspective. There is still the
> 'invalid wait context' issue there, because mbox API cannot be properly
> called from cpu_pm_notifier (which use raw_notifier internally):
Okay, i see why series [1] did not help for agatti due to fallback on CPU PM notification.
On PREEMPT_RT kernel, GENPD is marked as always RPM always on,
So MPM driver never get the .power_off callback it registered for and hence MPM irqchip won't invoke mbox_() APIs.
from drivers/cpuidle/cpuidle-psci-domain.c,
/*
* On a PREEMPT_RT based configuration the domain idle states are
* supported, but only during system-wide suspend.
*/
if (IS_ENABLED(CONFIG_PREEMPT_RT))
pd->flags |= GENPD_FLAG_RPM_ALWAYS_ON;
The series [1] fallbacks to CPU_PM based notification if "power-domains" property is not added.
having a power-domains property would have avoided the BUG for agatti on RT kernel.
Agatti device tree change in the series [2] only removed power-domain-cells# but did not add power-domains = <&cluster_pd>;
with the reason that qrb2210-rb1.dts had deleted "cluster_pd" however qrb2210-arduino-imola.dts still have it.
so below change on top of [1] series would avoid the BUG from mpm_cpu_pm_callback().
--- a/arch/arm64/boot/dts/qcom/agatti.dtsi
+++ b/arch/arm64/boot/dts/qcom/agatti.dtsi
@@ -281,6 +281,7 @@ mpm: interrupt-controller {
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
+ power-domains = <&cluster_pd>;
qcom,mpm-pin-count = <96>;
qcom,mpm-pin-map = <2 275>, /* TSENS0 uplow */
<5 296>, /* Soundwire master_irq */
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
index bf6fb12ad990..7dc2cade0a7f 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
@@ -246,6 +246,10 @@ &cpu_pd3 {
/delete-node/ &cluster_pd;
+&mpm {
+ /delete-property/ power-domains;
+};
+
[2] https://lore.kernel.org/linux-arm-msm/20260713-b4-shikra_lpm_addition-v1-0-3d858df2cbbf@oss.qualcomm.com/T/#m5bbdb535424c38209cc08e6afeae5e3aac9f6cc0
Thanks,
Maulik
>
> =============================
> [ BUG: Invalid wait context ]
> 7.2.0-rc3-next-20260714+ #16842 Not tainted
> -----------------------------
> swapper/3/0 is trying to lock:
> ffff0000008ac408 (&chan->lock){....}-{3:3}, at: mbox_send_message+0x3c/0x15c
> other info that might help us debug this:
> context-{5:5}
> locks held by swapper/3/0: 1, last CPU#3:
> #0: ffffd99263a61228 (cpu_pm_notifier.lock){....}-{2:2}, at: cpu_pm_enter+0x28/0x78
> stack backtrace:
> CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 7.2.0-rc3-next-20260714+ #16842 PREEMPT
> Hardware name: Arduino UnoQ (DT)
> Call trace:
> show_stack+0x18/0x24 (C)
> dump_stack_lvl+0x8c/0xcc
> dump_stack+0x18/0x24
> __lock_acquire+0x928/0x1f90
> lock_acquire+0x2b8/0x3ec
> _raw_spin_lock_irqsave+0x60/0x88
> mbox_send_message+0x3c/0x15c
> handle_rpm_notification+0x58/0x114
> mpm_cpu_pm_callback+0x9c/0xdc
> notifier_call_chain+0xa0/0x234
> raw_notifier_call_chain_robust+0x48/0xa8
> cpu_pm_enter+0x40/0x78
> __psci_enter_domain_idle_state.isra.0+0x48/0x470
> psci_enter_domain_idle_state+0x18/0x24
> cpuidle_enter_state+0xbc/0x428
> cpuidle_enter+0x38/0x50
> do_idle+0x158/0x324
> cpu_startup_entry+0x38/0x3c
> secondary_start_kernel+0x138/0x158
> __secondary_switched+0xc0/0xc4
>
> Best regards
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3] arm64: dts: qcom: qcm2290: Hook up MPM
2026-07-14 13:04 ` Ulf Hansson
2026-07-14 13:29 ` Maulik Shah (mkshah)
@ 2026-07-15 9:28 ` Konrad Dybcio
1 sibling, 0 replies; 12+ messages in thread
From: Konrad Dybcio @ 2026-07-15 9:28 UTC (permalink / raw)
To: Ulf Hansson, Marek Szyprowski
Cc: Konrad Dybcio, Andy Gross, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Konrad Dybcio, linux-arm-msm,
devicetree, linux-kernel, Ulf Hansson, linux-pm@vger.kernel.org
On 7/14/26 3:04 PM, Ulf Hansson wrote:
> On Thu, Jul 9, 2026 at 1:41 PM Marek Szyprowski
> <m.szyprowski@samsung.com> 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@linaro.org>
>>> ---
>>> 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.
I think that's right - we only need the "CPU_SS going off" notification
Konrad
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 3/3] arm64: dts: qcom: qcm2290: Hook up MPM
2026-07-09 11:41 ` Marek Szyprowski
2026-07-14 13:04 ` Ulf Hansson
@ 2026-07-14 13:27 ` Maulik Shah (mkshah)
1 sibling, 0 replies; 12+ messages in thread
From: Maulik Shah (mkshah) @ 2026-07-14 13:27 UTC (permalink / raw)
To: Marek Szyprowski, Konrad Dybcio, Andy Gross, Bjorn Andersson,
Rob Herring, Conor Dooley, Krzysztof Kozlowski
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Ulf Hansson, linux-pm@vger.kernel.org
On 7/9/2026 5:11 PM, Marek Szyprowski wrote:
> On 15.12.2023 01:01, Konrad Dybcio wrote:
>> Wire up MPM and the interrupts it provides.
>>
[...]
> 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)?
can you try with [1], which includes changes for agatti/ qcm2290.
The series is sent for other missing timer programming adding in MPM as well as probe dependency issue, but should
help in this case.
[1] https://lore.kernel.org/lkml/20260713-b4-shikra_lpm_addition-v1-0-3d858df2cbbf@oss.qualcomm.com/
Thanks,
Maulik
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 0/3] MPM hooking upping
2023-12-15 0:01 [PATCH 0/3] MPM hooking upping Konrad Dybcio
` (2 preceding siblings ...)
2023-12-15 0:01 ` [PATCH 3/3] arm64: dts: qcom: qcm2290: " Konrad Dybcio
@ 2023-12-17 17:21 ` Bjorn Andersson
3 siblings, 0 replies; 12+ messages in thread
From: Bjorn Andersson @ 2023-12-17 17:21 UTC (permalink / raw)
To: Andy Gross, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel
On Fri, 15 Dec 2023 01:01:07 +0100, Konrad Dybcio wrote:
> This series hooks up MPM (which can finally be done after winning the
> lengthy bindings fight) on 6375, 8996 and 2290 as a good start.
>
> The hardware in question is present on all RPM SMD SoCs (so, roughly
> msm8974 and up), which means many more platforms are there to come.
>
> MPM is one of the key pieces for allowing full system power collapse
> (and perhaps as importantly, resume) and serves roughly the same role
> as PDC on RPMh SoCs for this purpose.
>
> [...]
Applied, thanks!
[1/3] arm64: dts: qcom: sm6375: Hook up MPM
commit: d3246a0cf43fd24a1986163284edd2389143809d
[2/3] arm64: dts: qcom: msm8996: Hook up MPM
commit: 09896da07315cce07b019ab00750c8a57e1b53a3
[3/3] arm64: dts: qcom: qcm2290: Hook up MPM
commit: e3f6a699404154e7e103f8055f21c3556721603f
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply [flat|nested] 12+ messages in thread