| Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame^] | 1 | Power Management Interface |
| 2 | |
| 3 | |
| 4 | The power management subsystem provides a unified sysfs interface to |
| 5 | userspace, regardless of what architecture or platform one is |
| 6 | running. The interface exists in /sys/power/ directory (assuming sysfs |
| 7 | is mounted at /sys). |
| 8 | |
| 9 | /sys/power/state controls system power state. Reading from this file |
| 10 | returns what states are supported, which is hard-coded to 'standby' |
| 11 | (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk' |
| 12 | (Suspend-to-Disk). |
| 13 | |
| 14 | Writing to this file one of those strings causes the system to |
| 15 | transition into that state. Please see the file |
| 16 | Documentation/power/states.txt for a description of each of those |
| 17 | states. |
| 18 | |
| 19 | |
| 20 | /sys/power/disk controls the operating mode of the suspend-to-disk |
| 21 | mechanism. Suspend-to-disk can be handled in several ways. The |
| 22 | greatest distinction is who writes memory to disk - the firmware or |
| 23 | the kernel. If the firmware does it, we assume that it also handles |
| 24 | suspending the system. |
| 25 | |
| 26 | If the kernel does it, then we have three options for putting the system |
| 27 | to sleep - using the platform driver (e.g. ACPI or other PM |
| 28 | registers), powering off the system or rebooting the system (for |
| 29 | testing). The system will support either 'firmware' or 'platform', and |
| 30 | that is known a priori. But, the user may choose 'shutdown' or |
| 31 | 'reboot' as alternatives. |
| 32 | |
| 33 | Reading from this file will display what the mode is currently set |
| 34 | to. Writing to this file will accept one of |
| 35 | |
| 36 | 'firmware' |
| 37 | 'platform' |
| 38 | 'shutdown' |
| 39 | 'reboot' |
| 40 | |
| 41 | It will only change to 'firmware' or 'platform' if the system supports |
| 42 | it. |
| 43 | |