]>
Commit | Line | Data |
---|---|---|
84ed64ee RW |
1 | What: /sys/power/ |
2 | Date: August 2006 | |
49db1903 | 3 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
84ed64ee RW |
4 | Description: |
5 | The /sys/power directory will contain files that will | |
6 | provide a unified interface to the power management | |
7 | subsystem. | |
8 | ||
9 | What: /sys/power/state | |
406e7938 | 10 | Date: November 2016 |
49db1903 | 11 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
84ed64ee | 12 | Description: |
0399d4db RW |
13 | The /sys/power/state file controls system sleep states. |
14 | Reading from this file returns the available sleep state | |
406e7938 RW |
15 | labels, which may be "mem" (suspend), "standby" (power-on |
16 | suspend), "freeze" (suspend-to-idle) and "disk" (hibernation). | |
84ed64ee | 17 | |
406e7938 RW |
18 | Writing one of the above strings to this file causes the system |
19 | to transition into the corresponding state, if available. | |
20 | ||
21 | See Documentation/power/states.txt for more information. | |
22 | ||
23 | What: /sys/power/mem_sleep | |
24 | Date: November 2016 | |
25 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> | |
26 | Description: | |
27 | The /sys/power/mem_sleep file controls the operating mode of | |
28 | system suspend. Reading from it returns the available modes | |
29 | as "s2idle" (always present), "shallow" and "deep" (present if | |
30 | supported). The mode that will be used on subsequent attempts | |
31 | to suspend the system (by writing "mem" to the /sys/power/state | |
32 | file described above) is enclosed in square brackets. | |
33 | ||
34 | Writing one of the above strings to this file causes the mode | |
35 | represented by it to be used on subsequent attempts to suspend | |
36 | the system. | |
37 | ||
38 | See Documentation/power/states.txt for more information. | |
84ed64ee RW |
39 | |
40 | What: /sys/power/disk | |
b918f6e6 | 41 | Date: September 2006 |
49db1903 | 42 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
84ed64ee RW |
43 | Description: |
44 | The /sys/power/disk file controls the operating mode of the | |
45 | suspend-to-disk mechanism. Reading from this file returns | |
46 | the name of the method by which the system will be put to | |
47 | sleep on the next suspend. There are four methods supported: | |
48 | 'firmware' - means that the memory image will be saved to disk | |
49 | by some firmware, in which case we also assume that the | |
50 | firmware will handle the system suspend. | |
51 | 'platform' - the memory image will be saved by the kernel and | |
52 | the system will be put to sleep by the platform driver (e.g. | |
53 | ACPI or other PM registers). | |
54 | 'shutdown' - the memory image will be saved by the kernel and | |
55 | the system will be powered off. | |
56 | 'reboot' - the memory image will be saved by the kernel and | |
57 | the system will be rebooted. | |
58 | ||
b918f6e6 RW |
59 | Additionally, /sys/power/disk can be used to turn on one of the |
60 | two testing modes of the suspend-to-disk mechanism: 'testproc' | |
61 | or 'test'. If the suspend-to-disk mechanism is in the | |
62 | 'testproc' mode, writing 'disk' to /sys/power/state will cause | |
63 | the kernel to disable nonboot CPUs and freeze tasks, wait for 5 | |
64 | seconds, unfreeze tasks and enable nonboot CPUs. If it is in | |
65 | the 'test' mode, writing 'disk' to /sys/power/state will cause | |
66 | the kernel to disable nonboot CPUs and freeze tasks, shrink | |
67 | memory, suspend devices, wait for 5 seconds, resume devices, | |
68 | unfreeze tasks and enable nonboot CPUs. Then, we are able to | |
69 | look in the log messages and work out, for example, which code | |
70 | is being slow and which device drivers are misbehaving. | |
71 | ||
84ed64ee RW |
72 | The suspend-to-disk method may be chosen by writing to this |
73 | file one of the accepted strings: | |
74 | ||
75 | 'firmware' | |
76 | 'platform' | |
77 | 'shutdown' | |
78 | 'reboot' | |
b918f6e6 RW |
79 | 'testproc' |
80 | 'test' | |
84ed64ee RW |
81 | |
82 | It will only change to 'firmware' or 'platform' if the system | |
83 | supports that. | |
84 | ||
85 | What: /sys/power/image_size | |
86 | Date: August 2006 | |
49db1903 | 87 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
84ed64ee RW |
88 | Description: |
89 | The /sys/power/image_size file controls the size of the image | |
90 | created by the suspend-to-disk mechanism. It can be written a | |
91 | string representing a non-negative integer that will be used | |
92 | as an upper limit of the image size, in bytes. The kernel's | |
93 | suspend-to-disk code will do its best to ensure the image size | |
94 | will not exceed this number. However, if it turns out to be | |
95 | impossible, the kernel will try to suspend anyway using the | |
96 | smallest image possible. In particular, if "0" is written to | |
97 | this file, the suspend image will be as small as possible. | |
98 | ||
99 | Reading from this file will display the current image size | |
100 | limit, which is set to 500 MB by default. | |
101 | ||
102 | What: /sys/power/pm_trace | |
103 | Date: August 2006 | |
49db1903 | 104 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
84ed64ee RW |
105 | Description: |
106 | The /sys/power/pm_trace file controls the code which saves the | |
107 | last PM event point in the RTC across reboots, so that you can | |
108 | debug a machine that just hangs during suspend (or more | |
109 | commonly, during resume). Namely, the RTC is only used to save | |
110 | the last PM event point if this file contains '1'. Initially | |
111 | it contains '0' which may be changed to '1' by writing a | |
112 | string representing a nonzero integer into it. | |
113 | ||
114 | To use this debugging feature you should attempt to suspend | |
115 | the machine, then reboot it and run | |
116 | ||
117 | dmesg -s 1000000 | grep 'hash matches' | |
118 | ||
d33ac60b JH |
119 | If you do not get any matches (or they appear to be false |
120 | positives), it is possible that the last PM event point | |
121 | referred to a device created by a loadable kernel module. In | |
122 | this case cat /sys/power/pm_trace_dev_match (see below) after | |
123 | your system is started up and the kernel modules are loaded. | |
124 | ||
84ed64ee RW |
125 | CAUTION: Using it will cause your machine's real-time (CMOS) |
126 | clock to be set to a random invalid time after a resume. | |
0e06b4a8 | 127 | |
d33ac60b JH |
128 | What; /sys/power/pm_trace_dev_match |
129 | Date: October 2010 | |
130 | Contact: James Hogan <james@albanarts.com> | |
131 | Description: | |
132 | The /sys/power/pm_trace_dev_match file contains the name of the | |
133 | device associated with the last PM event point saved in the RTC | |
134 | across reboots when pm_trace has been used. More precisely it | |
135 | contains the list of current devices (including those | |
136 | registered by loadable kernel modules since boot) which match | |
137 | the device hash in the RTC at boot, with a newline after each | |
138 | one. | |
139 | ||
140 | The advantage of this file over the hash matches printed to the | |
141 | kernel log (see /sys/power/pm_trace), is that it includes | |
142 | devices created after boot by loadable kernel modules. | |
143 | ||
144 | Due to the small hash size necessary to fit in the RTC, it is | |
145 | possible that more than one device matches the hash, in which | |
146 | case further investigation is required to determine which | |
147 | device is causing the problem. Note that genuine RTC clock | |
148 | values (such as when pm_trace has not been used), can still | |
149 | match a device and output it's name here. | |
150 | ||
0e06b4a8 RW |
151 | What: /sys/power/pm_async |
152 | Date: January 2009 | |
49db1903 | 153 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
0e06b4a8 RW |
154 | Description: |
155 | The /sys/power/pm_async file controls the switch allowing the | |
156 | user space to enable or disable asynchronous suspend and resume | |
157 | of devices. If enabled, this feature will cause some device | |
158 | drivers' suspend and resume callbacks to be executed in parallel | |
159 | with each other and with the main suspend thread. It is enabled | |
160 | if this file contains "1", which is the default. It may be | |
161 | disabled by writing "0" to this file, in which case all devices | |
162 | will be suspended and resumed synchronously. | |
c125e96f RW |
163 | |
164 | What: /sys/power/wakeup_count | |
165 | Date: July 2010 | |
49db1903 | 166 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
c125e96f RW |
167 | Description: |
168 | The /sys/power/wakeup_count file allows user space to put the | |
169 | system into a sleep state while taking into account the | |
170 | concurrent arrival of wakeup events. Reading from it returns | |
171 | the current number of registered wakeup events and it blocks if | |
172 | some wakeup events are being processed at the time the file is | |
173 | read from. Writing to it will only succeed if the current | |
174 | number of wakeup events is equal to the written value and, if | |
175 | successful, will make the kernel abort a subsequent transition | |
176 | to a sleep state if any wakeup events are reported after the | |
177 | write has returned. | |
ddeb6487 RW |
178 | |
179 | What: /sys/power/reserved_size | |
180 | Date: May 2011 | |
49db1903 | 181 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
ddeb6487 RW |
182 | Description: |
183 | The /sys/power/reserved_size file allows user space to control | |
184 | the amount of memory reserved for allocations made by device | |
185 | drivers during the "device freeze" stage of hibernation. It can | |
186 | be written a string representing a non-negative integer that | |
187 | will be used as the amount of memory to reserve for allocations | |
188 | made by device drivers' "freeze" callbacks, in bytes. | |
189 | ||
190 | Reading from this file will display the current value, which is | |
191 | set to 1 MB by default. | |
7483b4a4 RW |
192 | |
193 | What: /sys/power/autosleep | |
194 | Date: April 2012 | |
49db1903 | 195 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
7483b4a4 RW |
196 | Description: |
197 | The /sys/power/autosleep file can be written one of the strings | |
198 | returned by reads from /sys/power/state. If that happens, a | |
199 | work item attempting to trigger a transition of the system to | |
200 | the sleep state represented by that string is queued up. This | |
201 | attempt will only succeed if there are no active wakeup sources | |
202 | in the system at that time. After every execution, regardless | |
203 | of whether or not the attempt to put the system to sleep has | |
204 | succeeded, the work item requeues itself until user space | |
205 | writes "off" to /sys/power/autosleep. | |
206 | ||
207 | Reading from this file causes the last string successfully | |
208 | written to it to be returned. | |
b86ff982 RW |
209 | |
210 | What: /sys/power/wake_lock | |
211 | Date: February 2012 | |
49db1903 | 212 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
b86ff982 RW |
213 | Description: |
214 | The /sys/power/wake_lock file allows user space to create | |
215 | wakeup source objects and activate them on demand (if one of | |
216 | those wakeup sources is active, reads from the | |
217 | /sys/power/wakeup_count file block or return false). When a | |
218 | string without white space is written to /sys/power/wake_lock, | |
219 | it will be assumed to represent a wakeup source name. If there | |
220 | is a wakeup source object with that name, it will be activated | |
221 | (unless active already). Otherwise, a new wakeup source object | |
222 | will be registered, assigned the given name and activated. | |
223 | If a string written to /sys/power/wake_lock contains white | |
224 | space, the part of the string preceding the white space will be | |
225 | regarded as a wakeup source name and handled as descrived above. | |
226 | The other part of the string will be regarded as a timeout (in | |
227 | nanoseconds) such that the wakeup source will be automatically | |
228 | deactivated after it has expired. The timeout, if present, is | |
229 | set regardless of the current state of the wakeup source object | |
230 | in question. | |
231 | ||
232 | Reads from this file return a string consisting of the names of | |
233 | wakeup sources created with the help of it that are active at | |
234 | the moment, separated with spaces. | |
235 | ||
236 | ||
237 | What: /sys/power/wake_unlock | |
238 | Date: February 2012 | |
49db1903 | 239 | Contact: Rafael J. Wysocki <rjw@rjwysocki.net> |
b86ff982 RW |
240 | Description: |
241 | The /sys/power/wake_unlock file allows user space to deactivate | |
242 | wakeup sources created with the help of /sys/power/wake_lock. | |
243 | When a string is written to /sys/power/wake_unlock, it will be | |
244 | assumed to represent the name of a wakeup source to deactivate. | |
245 | If a wakeup source object of that name exists and is active at | |
246 | the moment, it will be deactivated. | |
247 | ||
248 | Reads from this file return a string consisting of the names of | |
249 | wakeup sources created with the help of /sys/power/wake_lock | |
250 | that are inactive at the moment, separated with spaces. | |
4b7760ba SN |
251 | |
252 | What: /sys/power/pm_print_times | |
253 | Date: May 2012 | |
254 | Contact: Sameer Nanda <snanda@chromium.org> | |
255 | Description: | |
256 | The /sys/power/pm_print_times file allows user space to | |
257 | control whether the time taken by devices to suspend and | |
258 | resume is printed. These prints are useful for hunting down | |
259 | devices that take too long to suspend or resume. | |
260 | ||
261 | Writing a "1" enables this printing while writing a "0" | |
262 | disables it. The default value is "0". Reading from this file | |
263 | will display the current value. | |
a6f5f0dd AY |
264 | |
265 | What: /sys/power/pm_wakeup_irq | |
266 | Date: April 2015 | |
267 | Contact: Alexandra Yates <alexandra.yates@linux.intel.org> | |
268 | Description: | |
269 | The /sys/power/pm_wakeup_irq file reports to user space the IRQ | |
270 | number of the first wakeup interrupt (that is, the first | |
271 | interrupt from an IRQ line armed for system wakeup) seen by the | |
272 | kernel during the most recent system suspend/resume cycle. | |
273 | ||
274 | This output is useful for system wakeup diagnostics of spurious | |
275 | wakeup interrupts. |