adulau/aha
1
0
Fork 0
mirror of https://github.com/adulau/aha.git synced 2024-12-28 11:46:19 +00:00
Code Issues Projects Releases Packages Wiki Activity

power management: remove firmware disk mode

Browse source 
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:
Johannes Berg 2007-04-30 15:09:53 -07:00 committed by Linus Torvalds
parent fe0c935a6c
commit 11d77d0c01
5 changed files with 34 additions and 54 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
Documentation/power/interface.txt
View file

@ -18,17 +18,10 @@ states.
/sys/power/disk controls the operating mode of the suspend-to-disk /sys/power/disk controls the operating mode of the suspend-to-disk
mechanism. Suspend-to-disk can be handled in several ways. The mechanism. Suspend-to-disk can be handled in several ways. We have a
greatest distinction is who writes memory to disk - the firmware or few options for putting the system to sleep - using the platform driver
the kernel. If the firmware does it, we assume that it also handles (e.g. ACPI or other pm_ops), powering off the system or rebooting the
suspending the system. system (for testing).
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.
Additionally, /sys/power/disk can be used to turn on one of the two 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 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 Reading from this file will display what the mode is currently set
to. Writing to this file will accept one of to. Writing to this file will accept one of
'firmware' 'platform' (only if the platform supports it)
'platform'
'shutdown' 'shutdown'
'reboot' 'reboot'
'testproc' 'testproc'
'test' '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 /sys/power/image_size controls the size of the image created by
the suspend-to-disk mechanism. It can be written a string the suspend-to-disk mechanism. It can be written a string
representing a non-negative integer that will be used as an upper representing a non-negative integer that will be used as an upper

11
Documentation/power/states.txt
View file

@ -62,11 +62,12 @@ setup via another operating system for it to use. Despite the
inconvenience, this method requires minimal work by the kernel, since inconvenience, this method requires minimal work by the kernel, since
the firmware will also handle restoring memory contents on resume. the firmware will also handle restoring memory contents on resume.
If the kernel is responsible for persistently saving state, a mechanism For suspend-to-disk, a mechanism called swsusp called 'swsusp' (Swap
called 'swsusp' (Swap Suspend) is used to write memory contents to Suspend) is used to write memory contents to free swap space.
free swap space. swsusp has some restrictive requirements, but should swsusp has some restrictive requirements, but should work in most
work in most cases. Some, albeit outdated, documentation can be found cases. Some, albeit outdated, documentation can be found in
in Documentation/power/swsusp.txt. 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 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 low-power state (like ACPI S4), or it may simply power down. Powering

14
Documentation/power/swsusp.txt
View file

@ -156,8 +156,7 @@ instead set the PF_NOFREEZE process flag when creating the thread (and
be very careful). be very careful).
Q: What is the difference between "platform", "shutdown" and Q: What is the difference between "platform" and "shutdown"?
"firmware" in /sys/power/disk?
A: 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 platform: save state in linux, then tell bios to powerdown and blink
"suspended led" "suspended led"
firmware: tell bios to save state itself [needs BIOS-specific suspend "platform" is actually right thing to do where supported, but
partition, and has very little to do with swsusp] "shutdown" is most reliable (except on ACPI systems).
"platform" is actually right thing to do, but "shutdown" is most
reliable.
Q: I do not understand why you have such strong objections to idea of Q: I do not understand why you have such strong objections to idea of
selective suspend. 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 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 /sys/power/state file; write "standby" or "mem".) We've not seen any
hardware that can use these modes through software suspend, although in hardware that can use these modes through software suspend, although in
theory some systems might support "platform" or "firmware" modes that theory some systems might support "platform" modes that won't break the
won't break the USB connections. USB connections.
Remember that it's always a bad idea to unplug a disk drive containing a 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 mounted filesystem. That's true even when your system is asleep! The

13
include/linux/pm.h
View file

@ -114,13 +114,12 @@ typedef int __bitwise suspend_disk_method_t;
/* invalid must be 0 so struct pm_ops initialisers can leave it out */ /* 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_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) 1)
#define PM_DISK_PLATFORM ((__force suspend_disk_method_t) 2) #define PM_DISK_SHUTDOWN ((__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) 3)
#define PM_DISK_REBOOT ((__force suspend_disk_method_t) 4) #define PM_DISK_TEST ((__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) 5)
#define PM_DISK_TESTPROC ((__force suspend_disk_method_t) 6) #define PM_DISK_MAX ((__force suspend_disk_method_t) 6)
#define PM_DISK_MAX ((__force suspend_disk_method_t) 7)
/** /**
* struct pm_ops - Callbacks for managing platform dependent suspend states. * struct pm_ops - Callbacks for managing platform dependent suspend states.

27
kernel/power/disk.c
View file

@ -122,8 +122,6 @@ static int prepare_processes(void)
/** /**
* pm_suspend_disk - The granpappy of hibernation power management. * 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 * If not, then call swsusp to do its thing, then figure out how
* to power down the system. * to power down the system.
*/ */
@ -292,7 +290,6 @@ late_initcall(software_resume);
static const char * const pm_disk_modes[] = { static const char * const pm_disk_modes[] = {
[PM_DISK_FIRMWARE] = "firmware",
[PM_DISK_PLATFORM] = "platform", [PM_DISK_PLATFORM] = "platform",
[PM_DISK_SHUTDOWN] = "shutdown", [PM_DISK_SHUTDOWN] = "shutdown",
[PM_DISK_REBOOT] = "reboot", [PM_DISK_REBOOT] = "reboot",
@ -303,27 +300,25 @@ static const char * const pm_disk_modes[] = {
/** /**
* disk - Control suspend-to-disk mode * disk - Control suspend-to-disk mode
* *
* Suspend-to-disk can be handled in several ways. The greatest * Suspend-to-disk can be handled in several ways. We have a few options
* distinction is who writes memory to disk - the firmware or the OS. * for putting the system to sleep - using the platform driver (e.g. ACPI
* If the firmware does it, we assume that it also handles suspending * or other pm_ops), powering off the system or rebooting the system
* the system. * (for testing) as well as the two test modes.
* 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).
* *
* The system will support either 'firmware' or 'platform', and that is * The system can support 'platform', and that is known a priori (and
* known a priori (and encoded in pm_ops). But, the user may choose * encoded in pm_ops). However, the user may choose 'shutdown' or 'reboot'
* 'shutdown' or 'reboot' as alternatives. * as alternatives, as well as the test modes 'test' and 'testproc'.
* *
* show() will display what the mode is currently set to. * show() will display what the mode is currently set to.
* store() will accept one of * store() will accept one of
* *
* 'firmware'
* 'platform' * 'platform'
* 'shutdown' * 'shutdown'
* 'reboot' * '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). * 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; len = p ? p - buf : n;
mutex_lock(&pm_mutex); 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)) { if (!strncmp(buf, pm_disk_modes[i], len)) {
mode = i; mode = i;
break; break;