From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Linux PM list <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been reset by firmware
Date: Wed, 30 Sep 2015 23:51:47 +0200 [thread overview]
Message-ID: <2877152.vgpvethKO3@vostro.rjw.lan> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1509301039270.15216-100000@netrider.rowland.org>
On Wednesday, September 30, 2015 10:46:03 AM Alan Stern wrote:
> On Wed, 30 Sep 2015, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > If the platform firmware was involved in the system resume that's
> > being completed, there is a concern that some devices might have
> > been reset by it and if those devices had the power.direct_complete
> > flag set during the preceding suspend transition, they may stay
> > in a reset-power-on state indefinitely (until they are runtime-resumed
> > and then suspended again). That may not be a big deal from the
> > individual device's perspective, but if the system is an SoC, it may
> > be prevented from entering deep SoC-wide low-power states on idle
> > because of that.
> >
> > To prevent that from happening, force a runtime resume for devices
> > with power.direct_complete set if the platform firmware was involved
> > in the resume transition currently in progress.
> >
> > Something similar was done by the ACPI PM domain, but regardless of
> > the platform firmware involvement, and the new mechanism should be
> > sufficient to replace that code, so drop it.
>
> Maybe I'm not reading patch 1/2 correctly, but it looks like an
> ordinary ACPI-based desktop PC will always believe the firmware was
> involved in an S3 sleep transition.
That's correct and it reflects the reality.
> If that's so then won't this change defeat all the work being done by
> people trying to prevent unneeded runtime resumes during system resume?
> direct_complete would be useful only on non-ACPI systems.
To me at least the main motivation for direct_complete was to avoid unneeded
runtime resumes during system suspend and this patch doesn't change that.
Moreover, there is a difference between scheduling an asynchronous runtime
resume during system resume and doing a synchrouous runtime resume at that
point. In the latter case the resume process has to wait for the runtime
resume to complete, while in the former case we can get to thawing user
space while the scheduled runtime resume is in progress (or even still
waiting for that matter).
This means that direct_complete would be useful even for S3 transitions
with this patch applied. Not to mention the suspend-to-idle case in which
the resume really doesn't go through the firmware.
That said, perhaps the check as proposed is too coarse-grained. We need to
do something like this in the ACPI PM domain code (and we do it already) and
for PCI devices that are likely to be affected by the issue at hand. So
what about the appended patch (on top of https://patchwork.kernel.org/patch/7291711/)
instead?
Rafael
---
drivers/acpi/acpi_lpss.c | 2 +-
drivers/acpi/device_pm.c | 19 +------------------
drivers/base/power/generic_ops.c | 23 +++++++++++++++++++++++
drivers/pci/pci-driver.c | 2 +-
include/linux/pm.h | 2 +-
5 files changed, 27 insertions(+), 21 deletions(-)
Index: linux-pm/drivers/acpi/device_pm.c
===================================================================
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -963,23 +963,6 @@ int acpi_subsys_prepare(struct device *d
EXPORT_SYMBOL_GPL(acpi_subsys_prepare);
/**
- * acpi_subsys_complete - Finalize device's resume during system resume.
- * @dev: Device to handle.
- */
-void acpi_subsys_complete(struct device *dev)
-{
- pm_generic_complete(dev);
- /*
- * If the device had been runtime-suspended before the system went into
- * the sleep state it is going out of and it has never been resumed till
- * now, resume it in case the firmware powered it up.
- */
- if (dev->power.direct_complete)
- pm_request_resume(dev);
-}
-EXPORT_SYMBOL_GPL(acpi_subsys_complete);
-
-/**
* acpi_subsys_suspend - Run the device driver's suspend callback.
* @dev: Device to handle.
*
@@ -1047,7 +1030,7 @@ static struct dev_pm_domain acpi_general
.runtime_resume = acpi_subsys_runtime_resume,
#ifdef CONFIG_PM_SLEEP
.prepare = acpi_subsys_prepare,
- .complete = acpi_subsys_complete,
+ .complete = pm_complete_with_resume_check,
.suspend = acpi_subsys_suspend,
.suspend_late = acpi_subsys_suspend_late,
.resume_early = acpi_subsys_resume_early,
Index: linux-pm/drivers/acpi/acpi_lpss.c
===================================================================
--- linux-pm.orig/drivers/acpi/acpi_lpss.c
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -664,7 +664,7 @@ static struct dev_pm_domain acpi_lpss_pm
#ifdef CONFIG_PM
#ifdef CONFIG_PM_SLEEP
.prepare = acpi_subsys_prepare,
- .complete = acpi_subsys_complete,
+ .complete = pm_complete_with_resume_check,
.suspend = acpi_subsys_suspend,
.suspend_late = acpi_lpss_suspend_late,
.resume_early = acpi_lpss_resume_early,
Index: linux-pm/drivers/base/power/generic_ops.c
===================================================================
--- linux-pm.orig/drivers/base/power/generic_ops.c
+++ linux-pm/drivers/base/power/generic_ops.c
@@ -9,6 +9,7 @@
#include <linux/pm.h>
#include <linux/pm_runtime.h>
#include <linux/export.h>
+#include <linux/suspend.h>
#ifdef CONFIG_PM
/**
@@ -297,4 +298,26 @@ void pm_generic_complete(struct device *
if (drv && drv->pm && drv->pm->complete)
drv->pm->complete(dev);
}
+
+/**
+ * pm_complete_with_resume_check - Complete a device power transition.
+ * @dev: Device to handle.
+ *
+ * Complete a device power transition during a system-wide power transition and
+ * optionally schedule a runtime resume of the device if the system resume in
+ * progress has been initated by the platform firmware and the device had its
+ * power.direct_complete flag set.
+ */
+void pm_complete_with_resume_check(struct device *dev)
+{
+ pm_generic_complete(dev);
+ /*
+ * If the device had been runtime-suspended before the system went into
+ * the sleep state it is going out of and it has never been resumed till
+ * now, resume it in case the firmware powered it up.
+ */
+ if (dev->power.direct_complete && pm_resume_via_firmware())
+ pm_request_resume(dev);
+}
+EXPORT_SYMBOL_GPL(pm_complete_with_resume_check);
#endif /* CONFIG_PM_SLEEP */
Index: linux-pm/drivers/pci/pci-driver.c
===================================================================
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -687,7 +687,7 @@ static int pci_pm_prepare(struct device
static void pci_pm_complete(struct device *dev)
{
pci_dev_complete_resume(to_pci_dev(dev));
- pm_generic_complete(dev);
+ pm_complete_with_resume_check(dev);
}
#else /* !CONFIG_PM_SLEEP */
Index: linux-pm/include/linux/pm.h
===================================================================
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -731,7 +731,7 @@ extern int pm_generic_restore(struct dev
extern int pm_generic_poweroff_noirq(struct device *dev);
extern int pm_generic_poweroff_late(struct device *dev);
extern int pm_generic_poweroff(struct device *dev);
-extern void pm_generic_complete(struct device *dev);
+extern void pm_complete_with_resume_check(struct device *dev);
#else /* !CONFIG_PM_SLEEP */
next prev parent reply other threads:[~2015-09-30 21:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 0:46 [RFC][PATCH 0/2] PM / sleep: Make it possible to check if suspend/resume goes via firmware Rafael J. Wysocki
2015-09-30 0:52 ` [RFC][PATCH 1/2] PM / sleep: Add flags to indicate platform firmware involvement Rafael J. Wysocki
2015-09-30 0:53 ` [RFC][PATCH 2/2] PM / sleep: Kick devices that might have been reset by firmware Rafael J. Wysocki
2015-09-30 0:36 ` kbuild test robot
2015-09-30 14:46 ` Alan Stern
2015-09-30 21:51 ` Rafael J. Wysocki [this message]
2015-10-01 14:47 ` Alan Stern
2015-10-01 22:13 ` Rafael J. Wysocki
2015-10-02 1:50 ` [RFC][PATCH v2 0/2] PM / sleep: Make it possible to check if suspend/resume goes via firmware Rafael J. Wysocki
2015-10-02 1:52 ` [RFC][PATCH v2 1/2] PM / sleep: Add flags to indicate platform firmware involvement Rafael J. Wysocki
2015-10-02 1:54 ` [RFC][PATCH v2 2/2] PM / PCI / ACPI: Kick devices that might have been reset by firmware Rafael J. Wysocki
2015-10-06 22:48 ` [PATCH v3 0/3] PM / sleep: Make it possible to check if suspend/resume goes via firmware Rafael J. Wysocki
2015-10-06 22:49 ` [PATCH v3 1/3] PM / sleep: Add flags to indicate platform firmware involvement Rafael J. Wysocki
2015-10-06 22:50 ` [PATCH v3 2/3] PM / PCI / ACPI: Kick devices that might have been reset by firmware Rafael J. Wysocki
2015-10-06 22:53 ` [RFC][PATCH v3 3/3] input: i8042: Avoid resetting controller on system suspend/resume Rafael J. Wysocki
2015-10-06 22:34 ` Dmitry Torokhov
2015-10-06 23:08 ` Rafael J. Wysocki
2015-10-06 22:43 ` Dmitry Torokhov
2015-10-06 23:31 ` Rafael J. Wysocki
2015-10-06 23:11 ` kbuild test robot
2015-10-06 23:26 ` Dmitry Torokhov
2015-10-06 23:44 ` Rafael J. Wysocki
2015-10-07 1:03 ` [Update][PATCH " Rafael J. Wysocki
2015-10-12 20:17 ` Rafael J. Wysocki
2015-10-12 20:11 ` Dmitry Torokhov
2015-10-12 20:41 ` 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=2877152.vgpvethKO3@vostro.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=daniel.vetter@intel.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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).