/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
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
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
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:
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.
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
/* 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.
/**
* 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.
*/
static const char * const pm_disk_modes[] = {
- [PM_DISK_FIRMWARE] = "firmware",
[PM_DISK_PLATFORM] = "platform",
[PM_DISK_SHUTDOWN] = "shutdown",
[PM_DISK_REBOOT] = "reboot",
/**
* 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).
*/
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;
projects / linux-2.6-omap-h63xx.git / commitdiff