From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux ACPI <linux-acpi@vger.kernel.org>,
Linux PCI <linux-pci@vger.kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: [PATCH v1 3/9] PM: Make pm_runtime_force_resume() work with DPM_FLAG_SMART_SUSPEND
Date: Wed, 25 Jun 2025 21:18:51 +0200 [thread overview]
Message-ID: <1847016.VLH7GnMWUR@rjwysocki.net> (raw)
In-Reply-To: <22759968.EfDdHjke4D@rjwysocki.net>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Curently, drivers using pm_runtime_force_suspend/resume() cannot set
DPM_FLAG_SMART_SUSPEND because the devices with that flag set may need
to be resumed during system-wide resume regardless of whether or not
they have power.needs_force_resume set. That can happen due to a
dependency resolved at the beginning of a system-wide resume transition
(for instance, a bus type or PM domain has decided to resume a
subordinate device with DPM_FLAG_SMART_SUSPEND and its parent and
suppliers also need to be resumed).
To overcome this limitation, modify pm_runtime_force_resume() to check
the device's power.smart_suspend flag (which is set for devices with
DPM_FLAG_SMART_SUSPEND set that meet some additional requirements) and
the device's runtime PM status in addition to power.needs_force_resume.
Also change it to clear power.smart_suspend to ensure that it will not
handle the same device twice during one transition.
The underlying observation is that there are two cases in which the
device needs to be resumed by pm_runtime_force_resume(). One of them
is when the device has power.needs_force_resume set, which means that
pm_runtime_force_suspend() has suspended it and decided that it should
be resumed during the subsequent system resume. The other one is when
power.smart_suspend is set and the device's runtume PM status is
RPM_ACTIVE.
Update kerneldoc comments in accordance with the code changes.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/base/power/runtime.c | 38 +++++++++++++++++++++++++++-----------
1 file changed, 27 insertions(+), 11 deletions(-)
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1964,10 +1964,6 @@
* sure the device is put into low power state and it should only be used during
* system-wide PM transitions to sleep states. It assumes that the analogous
* pm_runtime_force_resume() will be used to resume the device.
- *
- * Do not use with DPM_FLAG_SMART_SUSPEND as this can lead to an inconsistent
- * state where this function has called the ->runtime_suspend callback but the
- * PM core marks the driver as runtime active.
*/
int pm_runtime_force_suspend(struct device *dev)
{
@@ -2014,20 +2010,28 @@
* pm_runtime_force_resume - Force a device into resume state if needed.
* @dev: Device to resume.
*
- * Prior invoking this function we expect the user to have brought the device
- * into low power state by a call to pm_runtime_force_suspend(). Here we reverse
- * those actions and bring the device into full power, if it is expected to be
- * used on system resume. In the other case, we defer the resume to be managed
- * via runtime PM.
+ * This function expects that either pm_runtime_force_suspend() has put the
+ * device into a low-power state prior to calling it, or the device had been
+ * runtime-suspended before the preceding system-wide suspend transition and it
+ * was left in suspend during that transition.
+ *
+ * The actions carried out by pm_runtime_force_suspend(), or by a runtime
+ * suspend in general, are reversed and the device is brought back into full
+ * power if it is expected to be used on system resume, which is the case when
+ * its needs_force_resume flag is set or when its smart_suspend flag is set and
+ * its runtime PM status is "active".
+ *
+ * In other cases, the resume is deferred to be managed via runtime PM.
*
- * Typically this function may be invoked from a system resume callback.
+ * Typically, this function may be invoked from a system resume callback.
*/
int pm_runtime_force_resume(struct device *dev)
{
int (*callback)(struct device *);
int ret = 0;
- if (!dev->power.needs_force_resume)
+ if (!dev->power.needs_force_resume && (!dev_pm_smart_suspend(dev) ||
+ pm_runtime_status_suspended(dev)))
goto out;
callback = RPM_GET_CALLBACK(dev, runtime_resume);
@@ -2041,8 +2045,20 @@
}
pm_runtime_mark_last_busy(dev);
+
out:
+ /*
+ * The smart_suspend flag can be cleared here because it is not going
+ * to be necessary until the next system-wide suspend transition that
+ * will update it again.
+ */
+ dev->power.smart_suspend = false;
+ /*
+ * Also clear needs_force_resume to make this function skip devices that
+ * have been seen by it once.
+ */
dev->power.needs_force_resume = false;
+
pm_runtime_enable(dev);
return ret;
}
next prev parent reply other threads:[~2025-06-25 19:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 19:14 [PATCH v1 0/9] PM: Reconcile different driver options for runtime PM integration with system sleep Rafael J. Wysocki
2025-06-25 19:16 ` [PATCH v1 1/9] PM: Use true/false as power.needs_force_resume values Rafael J. Wysocki
2025-06-26 10:10 ` Ulf Hansson
2025-06-25 19:17 ` [PATCH v1 0/9] PM: Check power.needs_force_resume in pm_runtime_force_suspend() Rafael J. Wysocki
2025-06-25 19:30 ` Rafael J. Wysocki
2025-06-26 10:10 ` Ulf Hansson
2025-06-26 10:15 ` Rafael J. Wysocki
2025-06-25 19:18 ` Rafael J. Wysocki [this message]
2025-06-26 10:26 ` [PATCH v1 3/9] PM: Make pm_runtime_force_resume() work with DPM_FLAG_SMART_SUSPEND Ulf Hansson
2025-06-25 19:19 ` [PATCH v1 4/9] PM: Move pm_runtime_force_suspend/resume() under CONFIG_PM_SLEEP Rafael J. Wysocki
2025-06-26 9:38 ` Ulf Hansson
2025-06-26 9:41 ` Rafael J. Wysocki
2025-06-26 10:04 ` Ulf Hansson
2025-06-26 10:13 ` Rafael J. Wysocki
2025-06-26 10:20 ` Ulf Hansson
2025-06-25 19:20 ` [PATCH v1 5/9] PM: Move needs_force_resume " Rafael J. Wysocki
2025-06-25 19:24 ` [PATCH v1 7/9] PM: sleep: Add strict_midlayer flag to struct dev_pm_info Rafael J. Wysocki
2025-06-25 19:24 ` [PATCH v1 8/9] ACPI: PM: Set/clear power.strict_midlayer during attach/detach Rafael J. Wysocki
2025-06-25 19:25 ` [PATCH v1 9/9] PCI: PM: Set power.strict_midlayer in pci_pm_init() Rafael J. Wysocki
2025-06-26 10:30 ` [PATCH v1 0/9] PM: Reconcile different driver options for runtime PM integration with system sleep Ulf Hansson
2025-06-26 10:34 ` Rafael J. Wysocki
2025-06-26 10:41 ` Ulf Hansson
2025-06-26 10:59 ` Rafael J. Wysocki
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=1847016.VLH7GnMWUR@rjwysocki.net \
--to=rjw@rjwysocki.net \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=ulf.hansson@linaro.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;
as well as URLs for NNTP newsgroup(s).