power management: remove firmware disk mode
This patch removes the firmware disk suspend mode which is the wrong approach, it is supposed to be used for implementing firmware-based disk suspend but cannot actually be used for that. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: <linux-pm@lists.linux-foundation.org> Cc: David Brownell <david-b@pacbell.net> Cc: Len Brown <lenb@kernel.org> Acked-by: Russell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
fe0c935a6c
commit
11d77d0c01
5 changed files with 34 additions and 54 deletions
|
@ -18,17 +18,10 @@ states.
|
|||
|
||||
|
||||
/sys/power/disk controls the operating mode of the suspend-to-disk
|
||||
mechanism. Suspend-to-disk can be handled in several ways. The
|
||||
greatest distinction is who writes memory to disk - the firmware or
|
||||
the kernel. If the firmware does it, we assume that it also handles
|
||||
suspending the system.
|
||||
|
||||
If the kernel does it, then we have three options for putting the system
|
||||
to sleep - using the platform driver (e.g. ACPI or other PM
|
||||
registers), powering off the system or rebooting the system (for
|
||||
testing). The system will support either 'firmware' or 'platform', and
|
||||
that is known a priori. But, the user may choose 'shutdown' or
|
||||
'reboot' as alternatives.
|
||||
mechanism. Suspend-to-disk can be handled in several ways. We have a
|
||||
few options for putting the system to sleep - using the platform driver
|
||||
(e.g. ACPI or other pm_ops), powering off the system or rebooting the
|
||||
system (for testing).
|
||||
|
||||
Additionally, /sys/power/disk can be used to turn on one of the two testing
|
||||
modes of the suspend-to-disk mechanism: 'testproc' or 'test'. If the
|
||||
|
@ -44,16 +37,12 @@ is being slow and which device drivers are misbehaving.
|
|||
Reading from this file will display what the mode is currently set
|
||||
to. Writing to this file will accept one of
|
||||
|
||||
'firmware'
|
||||
'platform'
|
||||
'platform' (only if the platform supports it)
|
||||
'shutdown'
|
||||
'reboot'
|
||||
'testproc'
|
||||
'test'
|
||||
|
||||
It will only change to 'firmware' or 'platform' if the system supports
|
||||
it.
|
||||
|
||||
/sys/power/image_size controls the size of the image created by
|
||||
the suspend-to-disk mechanism. It can be written a string
|
||||
representing a non-negative integer that will be used as an upper
|
||||
|
|
|
@ -62,17 +62,18 @@ setup via another operating system for it to use. Despite the
|
|||
inconvenience, this method requires minimal work by the kernel, since
|
||||
the firmware will also handle restoring memory contents on resume.
|
||||
|
||||
If the kernel is responsible for persistently saving state, a mechanism
|
||||
called 'swsusp' (Swap Suspend) is used to write memory contents to
|
||||
free swap space. swsusp has some restrictive requirements, but should
|
||||
work in most cases. Some, albeit outdated, documentation can be found
|
||||
in Documentation/power/swsusp.txt.
|
||||
For suspend-to-disk, a mechanism called swsusp called 'swsusp' (Swap
|
||||
Suspend) is used to write memory contents to free swap space.
|
||||
swsusp has some restrictive requirements, but should work in most
|
||||
cases. Some, albeit outdated, documentation can be found in
|
||||
Documentation/power/swsusp.txt. Alternatively, userspace can do most
|
||||
of the actual suspend to disk work, see userland-swsusp.txt.
|
||||
|
||||
Once memory state is written to disk, the system may either enter a
|
||||
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).
|
||||
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
|
||||
|
|
|
@ -156,8 +156,7 @@ instead set the PF_NOFREEZE process flag when creating the thread (and
|
|||
be very careful).
|
||||
|
||||
|
||||
Q: What is the difference between "platform", "shutdown" and
|
||||
"firmware" in /sys/power/disk?
|
||||
Q: What is the difference between "platform" and "shutdown"?
|
||||
|
||||
A:
|
||||
|
||||
|
@ -166,11 +165,8 @@ shutdown: save state in linux, then tell bios to powerdown
|
|||
platform: save state in linux, then tell bios to powerdown and blink
|
||||
"suspended led"
|
||||
|
||||
firmware: tell bios to save state itself [needs BIOS-specific suspend
|
||||
partition, and has very little to do with swsusp]
|
||||
|
||||
"platform" is actually right thing to do, but "shutdown" is most
|
||||
reliable.
|
||||
"platform" is actually right thing to do where supported, but
|
||||
"shutdown" is most reliable (except on ACPI systems).
|
||||
|
||||
Q: I do not understand why you have such strong objections to idea of
|
||||
selective suspend.
|
||||
|
@ -388,8 +384,8 @@ while the system is asleep, maintaining the connection, using true sleep
|
|||
modes like "suspend-to-RAM" or "standby". (Don't write "disk" to the
|
||||
/sys/power/state file; write "standby" or "mem".) We've not seen any
|
||||
hardware that can use these modes through software suspend, although in
|
||||
theory some systems might support "platform" or "firmware" modes that
|
||||
won't break the USB connections.
|
||||
theory some systems might support "platform" modes that won't break the
|
||||
USB connections.
|
||||
|
||||
Remember that it's always a bad idea to unplug a disk drive containing a
|
||||
mounted filesystem. That's true even when your system is asleep! The
|
||||
|
|
|
@ -114,13 +114,12 @@ typedef int __bitwise suspend_disk_method_t;
|
|||
|
||||
/* invalid must be 0 so struct pm_ops initialisers can leave it out */
|
||||
#define PM_DISK_INVALID ((__force suspend_disk_method_t) 0)
|
||||
#define PM_DISK_FIRMWARE ((__force suspend_disk_method_t) 1)
|
||||
#define PM_DISK_PLATFORM ((__force suspend_disk_method_t) 2)
|
||||
#define PM_DISK_SHUTDOWN ((__force suspend_disk_method_t) 3)
|
||||
#define PM_DISK_REBOOT ((__force suspend_disk_method_t) 4)
|
||||
#define PM_DISK_TEST ((__force suspend_disk_method_t) 5)
|
||||
#define PM_DISK_TESTPROC ((__force suspend_disk_method_t) 6)
|
||||
#define PM_DISK_MAX ((__force suspend_disk_method_t) 7)
|
||||
#define PM_DISK_PLATFORM ((__force suspend_disk_method_t) 1)
|
||||
#define PM_DISK_SHUTDOWN ((__force suspend_disk_method_t) 2)
|
||||
#define PM_DISK_REBOOT ((__force suspend_disk_method_t) 3)
|
||||
#define PM_DISK_TEST ((__force suspend_disk_method_t) 4)
|
||||
#define PM_DISK_TESTPROC ((__force suspend_disk_method_t) 5)
|
||||
#define PM_DISK_MAX ((__force suspend_disk_method_t) 6)
|
||||
|
||||
/**
|
||||
* struct pm_ops - Callbacks for managing platform dependent suspend states.
|
||||
|
|
|
@ -122,8 +122,6 @@ static int prepare_processes(void)
|
|||
/**
|
||||
* pm_suspend_disk - The granpappy of hibernation power management.
|
||||
*
|
||||
* If we're going through the firmware, then get it over with quickly.
|
||||
*
|
||||
* If not, then call swsusp to do its thing, then figure out how
|
||||
* to power down the system.
|
||||
*/
|
||||
|
@ -292,7 +290,6 @@ late_initcall(software_resume);
|
|||
|
||||
|
||||
static const char * const pm_disk_modes[] = {
|
||||
[PM_DISK_FIRMWARE] = "firmware",
|
||||
[PM_DISK_PLATFORM] = "platform",
|
||||
[PM_DISK_SHUTDOWN] = "shutdown",
|
||||
[PM_DISK_REBOOT] = "reboot",
|
||||
|
@ -303,27 +300,25 @@ static const char * const pm_disk_modes[] = {
|
|||
/**
|
||||
* disk - Control suspend-to-disk mode
|
||||
*
|
||||
* Suspend-to-disk can be handled in several ways. The greatest
|
||||
* distinction is who writes memory to disk - the firmware or the OS.
|
||||
* If the firmware does it, we assume that it also handles suspending
|
||||
* the system.
|
||||
* If the OS does it, then we have three options for putting the system
|
||||
* to sleep - using the platform driver (e.g. ACPI or other PM registers),
|
||||
* powering off the system or rebooting the system (for testing).
|
||||
* Suspend-to-disk can be handled in several ways. We have a few options
|
||||
* for putting the system to sleep - using the platform driver (e.g. ACPI
|
||||
* or other pm_ops), powering off the system or rebooting the system
|
||||
* (for testing) as well as the two test modes.
|
||||
*
|
||||
* The system will support either 'firmware' or 'platform', and that is
|
||||
* known a priori (and encoded in pm_ops). But, the user may choose
|
||||
* 'shutdown' or 'reboot' as alternatives.
|
||||
* The system can support 'platform', and that is known a priori (and
|
||||
* encoded in pm_ops). However, the user may choose 'shutdown' or 'reboot'
|
||||
* as alternatives, as well as the test modes 'test' and 'testproc'.
|
||||
*
|
||||
* show() will display what the mode is currently set to.
|
||||
* store() will accept one of
|
||||
*
|
||||
* 'firmware'
|
||||
* 'platform'
|
||||
* 'shutdown'
|
||||
* 'reboot'
|
||||
* 'test'
|
||||
* 'testproc'
|
||||
*
|
||||
* It will only change to 'firmware' or 'platform' if the system
|
||||
* It will only change to 'platform' if the system
|
||||
* supports it (as determined from pm_ops->pm_disk_mode).
|
||||
*/
|
||||
|
||||
|
@ -345,7 +340,7 @@ static ssize_t disk_store(struct subsystem * s, const char * buf, size_t n)
|
|||
len = p ? p - buf : n;
|
||||
|
||||
mutex_lock(&pm_mutex);
|
||||
for (i = PM_DISK_FIRMWARE; i < PM_DISK_MAX; i++) {
|
||||
for (i = PM_DISK_PLATFORM; i < PM_DISK_MAX; i++) {
|
||||
if (!strncmp(buf, pm_disk_modes[i], len)) {
|
||||
mode = i;
|
||||
break;
|
||||
|
|
Loading…
Reference in a new issue