From d5e1670afe0c886d6dd92afb7a1f085f88294dc8 Mon Sep 17 00:00:00 2001 From: Shuah Khan Date: Wed, 8 May 2013 01:14:32 +0200 Subject: [PATCH 1/4] PM: Avoid calling kfree() under spinlock in dev_pm_put_subsys_data() Fix dev_pm_put_subsys_data() so that it doesn't call kfree() under a spinlock and make it return 1 whenever it leaves NULL power.subsys_data (regardless of the reason). Signed-off-by: Shuah Khan Reviewed-by: Pavel Machek Acked-by: Greg Kroah-Hartman Signed-off-by: Rafael J. Wysocki --- drivers/base/power/common.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c index 39c32529b833..5da914041305 100644 --- a/drivers/base/power/common.c +++ b/drivers/base/power/common.c @@ -61,24 +61,24 @@ EXPORT_SYMBOL_GPL(dev_pm_get_subsys_data); int dev_pm_put_subsys_data(struct device *dev) { struct pm_subsys_data *psd; - int ret = 0; + int ret = 1; spin_lock_irq(&dev->power.lock); psd = dev_to_psd(dev); - if (!psd) { - ret = -EINVAL; + if (!psd) goto out; - } if (--psd->refcount == 0) { dev->power.subsys_data = NULL; - kfree(psd); - ret = 1; + } else { + psd = NULL; + ret = 0; } out: spin_unlock_irq(&dev->power.lock); + kfree(psd); return ret; } From dc5aeae4f961ca8ea9511422236d7076585f149a Mon Sep 17 00:00:00 2001 From: Zhang Rui Date: Mon, 13 May 2013 02:42:11 +0000 Subject: [PATCH 2/4] PM: Documentation update for freeze state Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki --- Documentation/power/devices.txt | 15 ++++++++------- Documentation/power/interface.txt | 4 ++-- Documentation/power/states.txt | 20 +++++++++++++++++--- 3 files changed, 27 insertions(+), 12 deletions(-) diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 504dfe4d52eb..a66c9821b5ce 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -268,7 +268,7 @@ situations. System Power Management Phases ------------------------------ Suspending or resuming the system is done in several phases. Different phases -are used for standby or memory sleep states ("suspend-to-RAM") and the +are used for freeze, standby, and memory sleep states ("suspend-to-RAM") and the hibernation state ("suspend-to-disk"). Each phase involves executing callbacks for every device before the next phase begins. Not all busses or classes support all these callbacks and not all drivers use all the callbacks. The @@ -309,7 +309,8 @@ execute the corresponding method from dev->driver->pm instead if there is one. Entering System Suspend ----------------------- -When the system goes into the standby or memory sleep state, the phases are: +When the system goes into the freeze, standby or memory sleep state, +the phases are: prepare, suspend, suspend_late, suspend_noirq. @@ -368,7 +369,7 @@ the devices that were suspended. Leaving System Suspend ---------------------- -When resuming from standby or memory sleep, the phases are: +When resuming from freeze, standby or memory sleep, the phases are: resume_noirq, resume_early, resume, complete. @@ -433,8 +434,8 @@ the system log. Entering Hibernation -------------------- -Hibernating the system is more complicated than putting it into the standby or -memory sleep state, because it involves creating and saving a system image. +Hibernating the system is more complicated than putting it into the other +sleep states, because it involves creating and saving a system image. Therefore there are more phases for hibernation, with a different set of callbacks. These phases always run after tasks have been frozen and memory has been freed. @@ -485,8 +486,8 @@ image forms an atomic snapshot of the system state. At this point the system image is saved, and the devices then need to be prepared for the upcoming system shutdown. This is much like suspending them -before putting the system into the standby or memory sleep state, and the phases -are similar. +before putting the system into the freeze, standby or memory sleep state, +and the phases are similar. 9. The prepare phase is discussed above. diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt index c537834af005..f1f0f59a7c47 100644 --- a/Documentation/power/interface.txt +++ b/Documentation/power/interface.txt @@ -7,8 +7,8 @@ running. The interface exists in /sys/power/ directory (assuming sysfs is mounted at /sys). /sys/power/state controls system power state. Reading from this file -returns what states are supported, which is hard-coded to 'standby' -(Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk' +returns what states are supported, which is hard-coded to 'freeze', +'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk' (Suspend-to-Disk). Writing to this file one of those strings causes the system to diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt index 4416b28630df..42f28b7aaf6b 100644 --- a/Documentation/power/states.txt +++ b/Documentation/power/states.txt @@ -2,12 +2,26 @@ System Power Management States -The kernel supports three power management states generically, though -each is dependent on platform support code to implement the low-level -details for each state. This file describes each state, what they are +The kernel supports four power management states generically, though +one is generic and the other three are dependent on platform support +code to implement the low-level details for each state. +This file describes each state, what they are commonly called, what ACPI state they map to, and what string to write to /sys/power/state to enter that state +state: Freeze / Low-Power Idle +ACPI state: S0 +String: "freeze" + +This state is a generic, pure software, light-weight, low-power state. +It allows more energy to be saved relative to idle by freezing user +space and putting all I/O devices into low-power states (possibly +lower-power than available at run time), such that the processors can +spend more time in their idle states. +This state can be used for platforms without Standby/Suspend-to-RAM +support, or it can be used in addition to Suspend-to-RAM (memory sleep) +to provide reduced resume latency. + State: Standby / Power-On Suspend ACPI State: S1 From 86fd03d1607525af3926ff0a299b16c51fa4221b Mon Sep 17 00:00:00 2001 From: Zhang Rui Date: Mon, 13 May 2013 02:42:12 +0000 Subject: [PATCH 3/4] PM / Documentation: remove inaccurate suspend/hibernate transition lantency statement The lantency of the transition from suspend and hibernate is platform-dependent. Thus we should not refer the lantency in the documentation. Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki --- Documentation/power/states.txt | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt index 42f28b7aaf6b..442d43df9b25 100644 --- a/Documentation/power/states.txt +++ b/Documentation/power/states.txt @@ -36,9 +36,6 @@ We try to put devices in a low-power state equivalent to D1, which also offers low power savings, but low resume latency. Not all devices support D1, and those that don't are left on. -A transition from Standby to the On state should take about 1-2 -seconds. - State: Suspend-to-RAM ACPI State: S3 @@ -56,9 +53,6 @@ transition back to the On state. For at least ACPI, STR requires some minimal boot-strapping code to resume the system from STR. This may be true on other platforms. -A transition from Suspend-to-RAM to the On state should take about -3-5 seconds. - State: Suspend-to-disk ACPI State: S4 @@ -88,7 +82,3 @@ low-power state (like ACPI S4), or it may simply power down. Powering down offers greater savings, and allows this mechanism to work on any system. However, entering a real low-power state allows the user to trigger wake up events (e.g. pressing a key or opening a laptop lid). - -A transition from Suspend-to-Disk to the On state should take about 30 -seconds, though it's typically a bit more with the current -implementation. From 6bc08ed02385378d8c84410fb407fe5640834350 Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Mon, 13 May 2013 12:00:03 +0000 Subject: [PATCH 4/4] PM / hibernate: Correct documentation Correct the meaning of PM_HIBERNATION_PREPARE in the docs. References: http://lkml.kernel.org/r/20130512162717.GA6305@pd.tnic Signed-off-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki --- Documentation/power/notifiers.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/power/notifiers.txt b/Documentation/power/notifiers.txt index c2a4a346c0d9..a81fa254303d 100644 --- a/Documentation/power/notifiers.txt +++ b/Documentation/power/notifiers.txt @@ -15,8 +15,10 @@ A suspend/hibernation notifier may be used for this purpose. The subsystems or drivers having such needs can register suspend notifiers that will be called upon the following events by the PM core: -PM_HIBERNATION_PREPARE The system is going to hibernate or suspend, tasks will - be frozen immediately. +PM_HIBERNATION_PREPARE The system is going to hibernate, tasks will be frozen + immediately. This is different from PM_SUSPEND_PREPARE + below because here we do additional work between notifiers + and drivers freezing. PM_POST_HIBERNATION The system memory state has been restored from a hibernation image or an error occurred during