Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | |
| 2 | System Power Management States |
| 3 | |
| 4 | |
| 5 | The kernel supports three power management states generically, though |
| 6 | each is dependent on platform support code to implement the low-level |
| 7 | details for each state. This file describes each state, what they are |
| 8 | commonly called, what ACPI state they map to, and what string to write |
| 9 | to /sys/power/state to enter that state |
| 10 | |
| 11 | |
| 12 | State: Standby / Power-On Suspend |
| 13 | ACPI State: S1 |
| 14 | String: "standby" |
| 15 | |
| 16 | This state offers minimal, though real, power savings, while providing |
| 17 | a very low-latency transition back to a working system. No operating |
| 18 | state is lost (the CPU retains power), so the system easily starts up |
| 19 | again where it left off. |
| 20 | |
| 21 | We try to put devices in a low-power state equivalent to D1, which |
| 22 | also offers low power savings, but low resume latency. Not all devices |
| 23 | support D1, and those that don't are left on. |
| 24 | |
| 25 | A transition from Standby to the On state should take about 1-2 |
| 26 | seconds. |
| 27 | |
| 28 | |
| 29 | State: Suspend-to-RAM |
| 30 | ACPI State: S3 |
| 31 | String: "mem" |
| 32 | |
| 33 | This state offers significant power savings as everything in the |
| 34 | system is put into a low-power state, except for memory, which is |
| 35 | placed in self-refresh mode to retain its contents. |
| 36 | |
| 37 | System and device state is saved and kept in memory. All devices are |
| 38 | suspended and put into D3. In many cases, all peripheral buses lose |
| 39 | power when entering STR, so devices must be able to handle the |
| 40 | transition back to the On state. |
| 41 | |
| 42 | For at least ACPI, STR requires some minimal boot-strapping code to |
| 43 | resume the system from STR. This may be true on other platforms. |
| 44 | |
| 45 | A transition from Suspend-to-RAM to the On state should take about |
| 46 | 3-5 seconds. |
| 47 | |
| 48 | |
| 49 | State: Suspend-to-disk |
| 50 | ACPI State: S4 |
| 51 | String: "disk" |
| 52 | |
| 53 | This state offers the greatest power savings, and can be used even in |
| 54 | the absence of low-level platform support for power management. This |
| 55 | state operates similarly to Suspend-to-RAM, but includes a final step |
| 56 | of writing memory contents to disk. On resume, this is read and memory |
| 57 | is restored to its pre-suspend state. |
| 58 | |
| 59 | STD can be handled by the firmware or the kernel. If it is handled by |
| 60 | the firmware, it usually requires a dedicated partition that must be |
| 61 | setup via another operating system for it to use. Despite the |
| 62 | inconvenience, this method requires minimal work by the kernel, since |
| 63 | the firmware will also handle restoring memory contents on resume. |
| 64 | |
| 65 | If the kernel is responsible for persistantly saving state, a mechanism |
| 66 | called 'swsusp' (Swap Suspend) is used to write memory contents to |
| 67 | free swap space. swsusp has some restrictive requirements, but should |
| 68 | work in most cases. Some, albeit outdated, documentation can be found |
| 69 | in Documentation/power/swsusp.txt. |
| 70 | |
| 71 | Once memory state is written to disk, the system may either enter a |
| 72 | low-power state (like ACPI S4), or it may simply power down. Powering |
| 73 | down offers greater savings, and allows this mechanism to work on any |
| 74 | system. However, entering a real low-power state allows the user to |
| 75 | trigger wake up events (e.g. pressing a key or opening a laptop lid). |
| 76 | |
| 77 | A transition from Suspend-to-Disk to the On state should take about 30 |
| 78 | seconds, though it's typically a bit more with the current |
| 79 | implementation. |