[RFC PATCH v1 0/1] mailbox: arm_mhuv3: Keep combined IRQ enabled during system suspend

[RFC PATCH v1 0/1] mailbox: arm_mhuv3: Keep combined IRQ enabled during system suspend

[Finley Xiao]

Hi Sudeep, Cristian,

This is an RFC to ask about keeping the MHUv3 combined IRQs enabled
across system suspend, so that SCMI clock/power-domain operations
issued from the noirq phase keep working.

SCMI clock and power-domain operations go through the mailbox
transport, and during system suspend they are still needed in the noirq
phase. genpd powers off a device's parent domain from
genpd_suspend_noirq() (e.g. turning off a video power domain when
suspending the display controller), which issues
scmi_clock_config_set() / scmi_power_state_set() and waits for the
firmware reply via the mailbox RX IRQ. Because dpm_suspend_noirq()
calls suspend_device_irqs() before running the suspend_noirq callbacks,
the mailbox IRQ is already masked at that point and the transfer times
out:

  arm-scmi firmware:scmi: timed out in resp(caller:
  scmi_clock_config_set+0x90/0xdc)

We hit this on one of our platforms and worked around it downstream by
adding IRQF_NO_SUSPEND to our mailbox driver. arm_mhuv3.c has the same
pattern: both the PBX and MBX combined interrupts are requested as
threaded IRQs with only IRQF_ONESHOT and no hardirq handler, so an
MHUv3 instance used as the SCMI mailbox transport (arm,scmi-mailbox)
would time out the same way.

IRQ threads are not frozen during system suspend, so with
IRQF_NO_SUSPEND the threaded combined-IRQ handlers still run in the
noirq phase. For SCMI clk/pd traffic the MBX combined IRQ must stay
enabled; the PBX combined IRQ, used for txdone by IRQ when not in
polling mode, needs the same treatment.

The patch applies IRQF_NO_SUSPEND to both registrations, but we would
like your opinion on:

1. whether you are open to this at all, or whether SCMI users on MHUv3
   should instead rely on another transport (e.g. SMC) for traffic
   needed in the noirq phase;

2. whether it should be applied to both the PBX and MBX combined IRQs
   unconditionally, or only in specific configurations.

This is not purely hypothetical: several in-tree DTs already route SCMI
over a mailbox transport without IRQF_NO_SUSPEND on the mailbox IRQ,
e.g. Juno and Morello use the MHU doorbell and the Zena CSS DTS uses
MHUv3. The patch is sent as RFC for discussion only.

Thanks,
Finley

Finley Xiao (1):
  mailbox: arm_mhuv3: Keep the combined IRQ enabled during system
    suspend

 drivers/mailbox/arm_mhuv3.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

-- 
2.43.0

[RFC PATCH v1 1/1] mailbox: arm_mhuv3: Keep the combined IRQ enabled during system suspend

[Finley Xiao]

When MHUv3 is used as the SCMI mailbox transport (arm,scmi-mailbox),
SCMI clock and power-domain operations still need to work in the noirq
phase of system suspend: genpd may power off a device's parent domain
from genpd_suspend_noirq(), which issues scmi_clock_config_set() /
scmi_power_state_set() and waits for the firmware reply via the mailbox
RX IRQ.

However, dpm_suspend_noirq() calls suspend_device_irqs() before running
the suspend_noirq callbacks, so the combined interrupts are already
masked at that point and the SCMI transfer times out while waiting for
the reply.

Both the PBX and MBX combined interrupts are requested as threaded
IRQs with only IRQF_ONESHOT. The MBX combined IRQ must stay enabled so
that firmware replies are delivered, and the PBX combined IRQ, used
for txdone by IRQ when not in polling mode, needs the same treatment.

IRQ threads are not frozen during system suspend, so with
IRQF_NO_SUSPEND the threaded combined-IRQ handlers still run in the
noirq phase.

Add IRQF_NO_SUSPEND to the MHUv3 combined IRQ registrations so that
SCMI remains functional throughout the suspend/resume cycle.

Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
---
 drivers/mailbox/arm_mhuv3.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mailbox/arm_mhuv3.c b/drivers/mailbox/arm_mhuv3.c
index a1c528be47f3..04998e1346c5 100644
--- a/drivers/mailbox/arm_mhuv3.c
+++ b/drivers/mailbox/arm_mhuv3.c
@@ -980,7 +980,8 @@ static int mhuv3_setup_pbx(struct mhuv3 *mhu)
 
 		ret = devm_request_threaded_irq(dev, mhu->cmb_irq, NULL,
 						mhuv3_pbx_comb_interrupt,
-						IRQF_ONESHOT, "mhuv3-pbx", mhu);
+						IRQF_ONESHOT | IRQF_NO_SUSPEND,
+						"mhuv3-pbx", mhu);
 		if (ret)
 			return dev_err_probe(dev, ret,
 					     "Failed to request PBX IRQ\n");
@@ -1017,7 +1018,8 @@ static int mhuv3_setup_mbx(struct mhuv3 *mhu)
 				     "MBX combined IRQ is missing !\n");
 
 	ret = devm_request_threaded_irq(dev, mhu->cmb_irq, NULL,
-					mhuv3_mbx_comb_interrupt, IRQF_ONESHOT,
+					mhuv3_mbx_comb_interrupt,
+					IRQF_ONESHOT | IRQF_NO_SUSPEND,
 					"mhuv3-mbx", mhu);
 	if (ret)
 		return dev_err_probe(dev, ret, "Failed to request MBX IRQ\n");
-- 
2.43.0

Re: [RFC PATCH v1 1/1] mailbox: arm_mhuv3: Keep the combined IRQ enabled during system suspend

[Sudeep Holla]

On Wed, Sep 30, 2026 at 11:36:57AM +0800, Finley Xiao wrote:
> When MHUv3 is used as the SCMI mailbox transport (arm,scmi-mailbox),
> SCMI clock and power-domain operations still need to work in the noirq
> phase of system suspend: genpd may power off a device's parent domain
> from genpd_suspend_noirq(), which issues scmi_clock_config_set() /
> scmi_power_state_set() and waits for the firmware reply via the mailbox
> RX IRQ.
> 
> However, dpm_suspend_noirq() calls suspend_device_irqs() before running
> the suspend_noirq callbacks, so the combined interrupts are already
> masked at that point and the SCMI transfer times out while waiting for
> the reply.
> 
> Both the PBX and MBX combined interrupts are requested as threaded
> IRQs with only IRQF_ONESHOT. The MBX combined IRQ must stay enabled so
> that firmware replies are delivered, and the PBX combined IRQ, used
> for txdone by IRQ when not in polling mode, needs the same treatment.
> 
> IRQ threads are not frozen during system suspend, so with
> IRQF_NO_SUSPEND the threaded combined-IRQ handlers still run in the
> noirq phase.
> 
> Add IRQF_NO_SUSPEND to the MHUv3 combined IRQ registrations so that
> SCMI remains functional throughout the suspend/resume cycle.
>

Looks good to me. Just to confirm, the expectation is to just have the
IRQs functional during suspend/resume cycle only and *not to wake up* the
system right ? If you need wakeup, you need to do more work.

For this change,

Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>

Jassi,

Please pick this up for next cycle when you are at it. Thanks!

-- 
Regards,
Sudeep

Re: [RFC PATCH v1 1/1] mailbox: arm_mhuv3: Keep the combined IRQ enabled during system suspend

[Finley Xiao]

在 2026/9/30 16:50, Sudeep Holla 写道:
> On Wed, Sep 30, 2026 at 11:36:57AM +0800, Finley Xiao wrote:
>> When MHUv3 is used as the SCMI mailbox transport (arm,scmi-mailbox),
>> SCMI clock and power-domain operations still need to work in the noirq
>> phase of system suspend: genpd may power off a device's parent domain
>> from genpd_suspend_noirq(), which issues scmi_clock_config_set() /
>> scmi_power_state_set() and waits for the firmware reply via the mailbox
>> RX IRQ.
>>
>> However, dpm_suspend_noirq() calls suspend_device_irqs() before running
>> the suspend_noirq callbacks, so the combined interrupts are already
>> masked at that point and the SCMI transfer times out while waiting for
>> the reply.
>>
>> Both the PBX and MBX combined interrupts are requested as threaded
>> IRQs with only IRQF_ONESHOT. The MBX combined IRQ must stay enabled so
>> that firmware replies are delivered, and the PBX combined IRQ, used
>> for txdone by IRQ when not in polling mode, needs the same treatment.
>>
>> IRQ threads are not frozen during system suspend, so with
>> IRQF_NO_SUSPEND the threaded combined-IRQ handlers still run in the
>> noirq phase.
>>
>> Add IRQF_NO_SUSPEND to the MHUv3 combined IRQ registrations so that
>> SCMI remains functional throughout the suspend/resume cycle.
>>
> Looks good to me. Just to confirm, the expectation is to just have the
> IRQs functional during suspend/resume cycle only and *not to wake up* the
> system right ? If you need wakeup, you need to do more work.

Yes, exactly. We just need the IRQs functional during the suspend/resume
cycle (for SCMI traffic in the noirq phase), not to wake up the system.

Thanks for the review.

>
> For this change,
>
> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
>
> Jassi,
>
> Please pick this up for next cycle when you are at it. Thanks!
>
-- 
Best regards,

底层平台中心 肖锋（Finley Xiao）
************************************************************************************
瑞芯微电子股份有限公司
Rockchip Electronics Co., Ltd.
福建省福州市铜盘路软件大道89号软件园A区21号楼 350003
No.21 Building, A District, Fuzhou Software Park, Fuzhou, Fujian 350003, P.R. China
Tel: 0591-83991906-8602 Mobile: 18506057603
************************************************************************************