From: Peng Fan <peng.fan@nxp.com>
To: Sudeep Holla <sudeep.holla@arm.com>,
Cristian Marussi <cristian.marussi@arm.com>
Cc: arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>,
Chuck Cannon <chuck.cannon@nxp.com>, Peng Fan <peng.fan@nxp.com>
Subject: [PATCH v2 2/2] firmware: arm_scmi: power_control: Set SCMI_SYSPOWER_IDLE in PM resume
Date: Fri, 04 Jul 2025 11:09:36 +0800 [thread overview]
Message-ID: <20250704-scmi-pm-v2-2-9316cec2f9cc@nxp.com> (raw)
In-Reply-To: <20250704-scmi-pm-v2-0-9316cec2f9cc@nxp.com>
When the Linux SCMI agent is suspended and another agent sends a second
suspend message, the Linux agent wakes up. The expected behavior is for
the Linux agent to wake up and then suspend again.
However, due to a race condition, the second suspend notification wakes
the system, but the SCMI state is not yet set to SCMI_SYSPOWER_IDLE.
This is because interrupts (e.g., i.MX95 Message Unit interrupts, which are
always enabled as wakeup sources) are active before thaw_processes() is
called. As a result, scmi_userspace_notifier() runs too early and
ignores the suspend request since the state hasn't been updated yet.
This patch addresses the race by setting the SCMI state to
SCMI_SYSPOWER_IDLE earlier-during the device resume phase, before
thaw_processes() is invoked. This ensures that when the notifier is
triggered, the state check passes and the system can suspend again as
intended.
On i.MX95, there are two scenarios where the Cortex-A cluster issues a
WFI signal:
- Linux CPU idle
- Linux suspend
The hardware state machine handles power-off sequences, with SCP involved
in one step. However, SCP cannot distinguish between a CPU idle request
and a full suspend request-it only sees a generic cluster power-off.
As a result, the SCP cannot filter out the second suspend message. By
setting SCMI_SYSPOWER_IDLE early, we ensure the Linux agent can correctly
handle the second suspend request and re-enter suspend.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/firmware/arm_scmi/scmi_power_control.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/arm_scmi/scmi_power_control.c b/drivers/firmware/arm_scmi/scmi_power_control.c
index 21f467a92942883be66074c37c2cab08c3e8a5cc..d2cfd9d92e711f7247a13c7773c11c0a6e582876 100644
--- a/drivers/firmware/arm_scmi/scmi_power_control.c
+++ b/drivers/firmware/arm_scmi/scmi_power_control.c
@@ -46,6 +46,7 @@
#include <linux/math.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/pm.h>
#include <linux/printk.h>
#include <linux/reboot.h>
#include <linux/scmi_protocol.h>
@@ -324,12 +325,7 @@ static int scmi_userspace_notifier(struct notifier_block *nb,
static void scmi_suspend_work_func(struct work_struct *work)
{
- struct scmi_syspower_conf *sc =
- container_of(work, struct scmi_syspower_conf, suspend_work);
-
pm_suspend(PM_SUSPEND_MEM);
-
- sc->state = SCMI_SYSPOWER_IDLE;
}
static int scmi_syspower_probe(struct scmi_device *sdev)
@@ -354,6 +350,7 @@ static int scmi_syspower_probe(struct scmi_device *sdev)
sc->required_transition = SCMI_SYSTEM_MAX;
sc->userspace_nb.notifier_call = &scmi_userspace_notifier;
sc->dev = &sdev->dev;
+ dev_set_drvdata(&sdev->dev, sc);
INIT_WORK(&sc->suspend_work, scmi_suspend_work_func);
@@ -363,6 +360,20 @@ static int scmi_syspower_probe(struct scmi_device *sdev)
NULL, &sc->userspace_nb);
}
+static int scmi_system_power_resume(struct device *dev)
+{
+
+ struct scmi_syspower_conf *sc = dev_get_drvdata(dev);
+
+ sc->state = SCMI_SYSPOWER_IDLE;
+
+ return 0;
+}
+
+static const struct dev_pm_ops scmi_system_power_pmops = {
+ SET_SYSTEM_SLEEP_PM_OPS(NULL, scmi_system_power_resume)
+};
+
static const struct scmi_device_id scmi_id_table[] = {
{ SCMI_PROTOCOL_SYSTEM, "syspower" },
{ },
@@ -370,6 +381,9 @@ static const struct scmi_device_id scmi_id_table[] = {
MODULE_DEVICE_TABLE(scmi, scmi_id_table);
static struct scmi_driver scmi_system_power_driver = {
+ .driver = {
+ .pm = &scmi_system_power_pmops,
+ },
.name = "scmi-system-power",
.probe = scmi_syspower_probe,
.id_table = scmi_id_table,
--
2.37.1
next prev parent reply other threads:[~2025-07-04 3:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-04 3:09 [PATCH v2 0/2] firmware: arm_scmi: add pm ops for scmi_power_control Peng Fan
2025-07-04 3:09 ` [PATCH v2 1/2] firmware: arm_scmi: bus: Add pm ops Peng Fan
2025-07-07 11:25 ` Sudeep Holla
2025-07-08 1:32 ` Peng Fan
2025-07-04 3:09 ` Peng Fan [this message]
2025-07-08 15:26 ` [PATCH v2 0/2] firmware: arm_scmi: add pm ops for scmi_power_control Sudeep Holla
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=20250704-scmi-pm-v2-2-9316cec2f9cc@nxp.com \
--to=peng.fan@nxp.com \
--cc=arm-scmi@vger.kernel.org \
--cc=chuck.cannon@nxp.com \
--cc=cristian.marussi@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ranjani.vaidyanathan@nxp.com \
--cc=sudeep.holla@arm.com \
/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
all inboxes | Powered by JetHome®