PageRenderTime 13ms CodeModel.GetById 10ms app.highlight 1ms RepoModel.GetById 1ms app.codeStats 0ms

/Documentation/power/interface.txt

https://bitbucket.org/evzijst/gittest
Plain Text | 43 lines | 32 code | 11 blank | 0 comment | 0 complexity | 27019d60d18523bbae0be2dc66618b43 MD5 | raw file
 1Power Management Interface
 2
 3
 4The power management subsystem provides a unified sysfs interface to 
 5userspace, regardless of what architecture or platform one is
 6running. The interface exists in /sys/power/ directory (assuming sysfs
 7is mounted at /sys). 
 8
 9/sys/power/state controls system power state. Reading from this file
10returns 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
14Writing to this file one of those strings causes the system to
15transition into that state. Please see the file
16Documentation/power/states.txt for a description of each of those
17states.
18
19
20/sys/power/disk controls the operating mode of the suspend-to-disk
21mechanism. Suspend-to-disk can be handled in several ways. The
22greatest distinction is who writes memory to disk - the firmware or
23the kernel. If the firmware does it, we assume that it also handles
24suspending the system. 
25
26If the kernel does it, then we have three options for putting the system
27to sleep - using the platform driver (e.g. ACPI or other PM
28registers), powering off the system or rebooting the system (for
29testing). The system will support either 'firmware' or 'platform', and
30that is known a priori. But, the user may choose 'shutdown' or
31'reboot' as alternatives. 
32
33Reading from this file will display what the mode is currently set
34to. Writing to this file will accept one of
35
36       'firmware'
37       'platform'
38       'shutdown'
39       'reboot'
40
41It will only change to 'firmware' or 'platform' if the system supports
42it. 
43