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