Commit | Line | Data |
---|---|---|
1da177e4 LT |
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 | ||
11d77d0c JB |
65 | For suspend-to-disk, a mechanism called swsusp called 'swsusp' (Swap |
66 | Suspend) is used to write memory contents to free swap space. | |
67 | swsusp has some restrictive requirements, but should work in most | |
68 | cases. Some, albeit outdated, documentation can be found in | |
69 | Documentation/power/swsusp.txt. Alternatively, userspace can do most | |
70 | of the actual suspend to disk work, see userland-swsusp.txt. | |
1da177e4 LT |
71 | |
72 | Once memory state is written to disk, the system may either enter a | |
73 | low-power state (like ACPI S4), or it may simply power down. Powering | |
74 | down offers greater savings, and allows this mechanism to work on any | |
75 | system. However, entering a real low-power state allows the user to | |
11d77d0c | 76 | trigger wake up events (e.g. pressing a key or opening a laptop lid). |
1da177e4 LT |
77 | |
78 | A transition from Suspend-to-Disk to the On state should take about 30 | |
79 | seconds, though it's typically a bit more with the current | |
80 | implementation. |