1 |
3 |
xianfeng |
|
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 |
|
|
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.
|
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
|
76 |
|
|
trigger wake up events (e.g. pressing a key or opening a laptop lid).
|
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.
|