diff options
author | Zhang Rui <rui.zhang@intel.com> | 2013-05-12 22:42:11 -0400 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2013-05-13 19:41:37 -0400 |
commit | dc5aeae4f961ca8ea9511422236d7076585f149a (patch) | |
tree | 69e0efbccf0a2d3827ee7827905c23a9aa6ac0e1 /Documentation | |
parent | d5e1670afe0c886d6dd92afb7a1f085f88294dc8 (diff) |
PM: Documentation update for freeze state
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/power/devices.txt | 15 | ||||
-rw-r--r-- | Documentation/power/interface.txt | 4 | ||||
-rw-r--r-- | Documentation/power/states.txt | 20 |
3 files changed, 27 insertions, 12 deletions
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 504dfe4d52eb..a66c9821b5ce 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt | |||
@@ -268,7 +268,7 @@ situations. | |||
268 | System Power Management Phases | 268 | System Power Management Phases |
269 | ------------------------------ | 269 | ------------------------------ |
270 | Suspending or resuming the system is done in several phases. Different phases | 270 | Suspending or resuming the system is done in several phases. Different phases |
271 | are used for standby or memory sleep states ("suspend-to-RAM") and the | 271 | are used for freeze, standby, and memory sleep states ("suspend-to-RAM") and the |
272 | hibernation state ("suspend-to-disk"). Each phase involves executing callbacks | 272 | hibernation state ("suspend-to-disk"). Each phase involves executing callbacks |
273 | for every device before the next phase begins. Not all busses or classes | 273 | for every device before the next phase begins. Not all busses or classes |
274 | support all these callbacks and not all drivers use all the callbacks. The | 274 | support all these callbacks and not all drivers use all the callbacks. The |
@@ -309,7 +309,8 @@ execute the corresponding method from dev->driver->pm instead if there is one. | |||
309 | 309 | ||
310 | Entering System Suspend | 310 | Entering System Suspend |
311 | ----------------------- | 311 | ----------------------- |
312 | When the system goes into the standby or memory sleep state, the phases are: | 312 | When the system goes into the freeze, standby or memory sleep state, |
313 | the phases are: | ||
313 | 314 | ||
314 | prepare, suspend, suspend_late, suspend_noirq. | 315 | prepare, suspend, suspend_late, suspend_noirq. |
315 | 316 | ||
@@ -368,7 +369,7 @@ the devices that were suspended. | |||
368 | 369 | ||
369 | Leaving System Suspend | 370 | Leaving System Suspend |
370 | ---------------------- | 371 | ---------------------- |
371 | When resuming from standby or memory sleep, the phases are: | 372 | When resuming from freeze, standby or memory sleep, the phases are: |
372 | 373 | ||
373 | resume_noirq, resume_early, resume, complete. | 374 | resume_noirq, resume_early, resume, complete. |
374 | 375 | ||
@@ -433,8 +434,8 @@ the system log. | |||
433 | 434 | ||
434 | Entering Hibernation | 435 | Entering Hibernation |
435 | -------------------- | 436 | -------------------- |
436 | Hibernating the system is more complicated than putting it into the standby or | 437 | Hibernating the system is more complicated than putting it into the other |
437 | memory sleep state, because it involves creating and saving a system image. | 438 | sleep states, because it involves creating and saving a system image. |
438 | Therefore there are more phases for hibernation, with a different set of | 439 | Therefore there are more phases for hibernation, with a different set of |
439 | callbacks. These phases always run after tasks have been frozen and memory has | 440 | callbacks. These phases always run after tasks have been frozen and memory has |
440 | been freed. | 441 | been freed. |
@@ -485,8 +486,8 @@ image forms an atomic snapshot of the system state. | |||
485 | 486 | ||
486 | At this point the system image is saved, and the devices then need to be | 487 | At this point the system image is saved, and the devices then need to be |
487 | prepared for the upcoming system shutdown. This is much like suspending them | 488 | prepared for the upcoming system shutdown. This is much like suspending them |
488 | before putting the system into the standby or memory sleep state, and the phases | 489 | before putting the system into the freeze, standby or memory sleep state, |
489 | are similar. | 490 | and the phases are similar. |
490 | 491 | ||
491 | 9. The prepare phase is discussed above. | 492 | 9. The prepare phase is discussed above. |
492 | 493 | ||
diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt index c537834af005..f1f0f59a7c47 100644 --- a/Documentation/power/interface.txt +++ b/Documentation/power/interface.txt | |||
@@ -7,8 +7,8 @@ running. The interface exists in /sys/power/ directory (assuming sysfs | |||
7 | is mounted at /sys). | 7 | is mounted at /sys). |
8 | 8 | ||
9 | /sys/power/state controls system power state. Reading from this file | 9 | /sys/power/state controls system power state. Reading from this file |
10 | returns what states are supported, which is hard-coded to 'standby' | 10 | returns what states are supported, which is hard-coded to 'freeze', |
11 | (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk' | 11 | 'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk' |
12 | (Suspend-to-Disk). | 12 | (Suspend-to-Disk). |
13 | 13 | ||
14 | Writing to this file one of those strings causes the system to | 14 | Writing to this file one of those strings causes the system to |
diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt index 4416b28630df..42f28b7aaf6b 100644 --- a/Documentation/power/states.txt +++ b/Documentation/power/states.txt | |||
@@ -2,12 +2,26 @@ | |||
2 | System Power Management States | 2 | System Power Management States |
3 | 3 | ||
4 | 4 | ||
5 | The kernel supports three power management states generically, though | 5 | The kernel supports four power management states generically, though |
6 | each is dependent on platform support code to implement the low-level | 6 | one is generic and the other three are dependent on platform support |
7 | details for each state. This file describes each state, what they are | 7 | code to implement the low-level details for each state. |
8 | This file describes each state, what they are | ||
8 | commonly called, what ACPI state they map to, and what string to write | 9 | commonly called, what ACPI state they map to, and what string to write |
9 | to /sys/power/state to enter that state | 10 | to /sys/power/state to enter that state |
10 | 11 | ||
12 | state: Freeze / Low-Power Idle | ||
13 | ACPI state: S0 | ||
14 | String: "freeze" | ||
15 | |||
16 | This state is a generic, pure software, light-weight, low-power state. | ||
17 | It allows more energy to be saved relative to idle by freezing user | ||
18 | space and putting all I/O devices into low-power states (possibly | ||
19 | lower-power than available at run time), such that the processors can | ||
20 | spend more time in their idle states. | ||
21 | This state can be used for platforms without Standby/Suspend-to-RAM | ||
22 | support, or it can be used in addition to Suspend-to-RAM (memory sleep) | ||
23 | to provide reduced resume latency. | ||
24 | |||
11 | 25 | ||
12 | State: Standby / Power-On Suspend | 26 | State: Standby / Power-On Suspend |
13 | ACPI State: S1 | 27 | ACPI State: S1 |