From: Finley Xiao <finley.xiao@rock-chips.com>
To: Finley Xiao <finley.xiao@rock-chips.com>,
Sudeep Holla <sudeep.holla@kernel.org>,
Cristian Marussi <cristian.marussi@arm.com>
Cc: Jassi Brar <jassisinghbrar@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: [RFC PATCH v1 0/1] mailbox: arm_mhuv3: Keep combined IRQ enabled during system suspend
Date: Wed, 30 Sep 2026 11:36:56 +0800 [thread overview]
Message-ID: <20260930033657.312266-1-finley.xiao@rock-chips.com> (raw)
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
next reply other threads:[~2026-09-30 3:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 3:36 Finley Xiao [this message]
2026-09-30 3:36 ` [RFC PATCH v1 1/1] mailbox: arm_mhuv3: Keep the combined IRQ enabled during system suspend Finley Xiao
2026-09-30 8:50 ` Sudeep Holla
2026-09-30 9:36 ` Finley Xiao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260930033657.312266-1-finley.xiao@rock-chips.com \
--to=finley.xiao@rock-chips.com \
--cc=cristian.marussi@arm.com \
--cc=jassisinghbrar@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sudeep.holla@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox