diff options
author | Alan Stern <stern@rowland.harvard.edu> | 2007-10-10 16:24:56 -0400 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2007-10-12 17:55:34 -0400 |
commit | cd38c1e1ae5273c28a12baacaf17c1faa062661f (patch) | |
tree | 941e5e2623725947ef40a68c04da371e9170fc20 /Documentation/usb | |
parent | 271f9e68f3450ac8d1ff3bda36581f1ec0d0cc1f (diff) |
USB: documentation for USB power management
This patch (as998) adds documentation on how USB power management
works and how to use it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'Documentation/usb')
-rw-r--r-- | Documentation/usb/power-management.txt | 517 |
1 files changed, 517 insertions, 0 deletions
diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt new file mode 100644 index 000000000000..97842deec471 --- /dev/null +++ b/Documentation/usb/power-management.txt | |||
@@ -0,0 +1,517 @@ | |||
1 | Power Management for USB | ||
2 | |||
3 | Alan Stern <stern@rowland.harvard.edu> | ||
4 | |||
5 | October 5, 2007 | ||
6 | |||
7 | |||
8 | |||
9 | What is Power Management? | ||
10 | ------------------------- | ||
11 | |||
12 | Power Management (PM) is the practice of saving energy by suspending | ||
13 | parts of a computer system when they aren't being used. While a | ||
14 | component is "suspended" it is in a nonfunctional low-power state; it | ||
15 | might even be turned off completely. A suspended component can be | ||
16 | "resumed" (returned to a functional full-power state) when the kernel | ||
17 | needs to use it. (There also are forms of PM in which components are | ||
18 | placed in a less functional but still usable state instead of being | ||
19 | suspended; an example would be reducing the CPU's clock rate. This | ||
20 | document will not discuss those other forms.) | ||
21 | |||
22 | When the parts being suspended include the CPU and most of the rest of | ||
23 | the system, we speak of it as a "system suspend". When a particular | ||
24 | device is turned off while the system as a whole remains running, we | ||
25 | call it a "dynamic suspend" (also known as a "runtime suspend" or | ||
26 | "selective suspend"). This document concentrates mostly on how | ||
27 | dynamic PM is implemented in the USB subsystem, although system PM is | ||
28 | covered to some extent (see Documentation/power/*.txt for more | ||
29 | information about system PM). | ||
30 | |||
31 | Note: Dynamic PM support for USB is present only if the kernel was | ||
32 | built with CONFIG_USB_SUSPEND enabled. System PM support is present | ||
33 | only if the kernel was built with CONFIG_SUSPEND or CONFIG_HIBERNATION | ||
34 | enabled. | ||
35 | |||
36 | |||
37 | What is Remote Wakeup? | ||
38 | ---------------------- | ||
39 | |||
40 | When a device has been suspended, it generally doesn't resume until | ||
41 | the computer tells it to. Likewise, if the entire computer has been | ||
42 | suspended, it generally doesn't resume until the user tells it to, say | ||
43 | by pressing a power button or opening the cover. | ||
44 | |||
45 | However some devices have the capability of resuming by themselves, or | ||
46 | asking the kernel to resume them, or even telling the entire computer | ||
47 | to resume. This capability goes by several names such as "Wake On | ||
48 | LAN"; we will refer to it generically as "remote wakeup". When a | ||
49 | device is enabled for remote wakeup and it is suspended, it may resume | ||
50 | itself (or send a request to be resumed) in response to some external | ||
51 | event. Examples include a suspended keyboard resuming when a key is | ||
52 | pressed, or a suspended USB hub resuming when a device is plugged in. | ||
53 | |||
54 | |||
55 | When is a USB device idle? | ||
56 | -------------------------- | ||
57 | |||
58 | A device is idle whenever the kernel thinks it's not busy doing | ||
59 | anything important and thus is a candidate for being suspended. The | ||
60 | exact definition depends on the device's driver; drivers are allowed | ||
61 | to declare that a device isn't idle even when there's no actual | ||
62 | communication taking place. (For example, a hub isn't considered idle | ||
63 | unless all the devices plugged into that hub are already suspended.) | ||
64 | In addition, a device isn't considered idle so long as a program keeps | ||
65 | its usbfs file open, whether or not any I/O is going on. | ||
66 | |||
67 | If a USB device has no driver, its usbfs file isn't open, and it isn't | ||
68 | being accessed through sysfs, then it definitely is idle. | ||
69 | |||
70 | |||
71 | Forms of dynamic PM | ||
72 | ------------------- | ||
73 | |||
74 | Dynamic suspends can occur in two ways: manual and automatic. | ||
75 | "Manual" means that the user has told the kernel to suspend a device, | ||
76 | whereas "automatic" means that the kernel has decided all by itself to | ||
77 | suspend a device. Automatic suspend is called "autosuspend" for | ||
78 | short. In general, a device won't be autosuspended unless it has been | ||
79 | idle for some minimum period of time, the so-called idle-delay time. | ||
80 | |||
81 | Of course, nothing the kernel does on its own initiative should | ||
82 | prevent the computer or its devices from working properly. If a | ||
83 | device has been autosuspended and a program tries to use it, the | ||
84 | kernel will automatically resume the device (autoresume). For the | ||
85 | same reason, an autosuspended device will usually have remote wakeup | ||
86 | enabled, if the device supports remote wakeup. | ||
87 | |||
88 | It is worth mentioning that many USB drivers don't support | ||
89 | autosuspend. In fact, at the time of this writing (Linux 2.6.23) the | ||
90 | only drivers which do support it are the hub driver, kaweth, asix, | ||
91 | usblp, usblcd, and usb-skeleton (which doesn't count). If a | ||
92 | non-supporting driver is bound to a device, the device won't be | ||
93 | autosuspended. In effect, the kernel pretends the device is never | ||
94 | idle. | ||
95 | |||
96 | We can categorize power management events in two broad classes: | ||
97 | external and internal. External events are those triggered by some | ||
98 | agent outside the USB stack: system suspend/resume (triggered by | ||
99 | userspace), manual dynamic suspend/resume (also triggered by | ||
100 | userspace), and remote wakeup (triggered by the device). Internal | ||
101 | events are those triggered within the USB stack: autosuspend and | ||
102 | autoresume. | ||
103 | |||
104 | |||
105 | The user interface for dynamic PM | ||
106 | --------------------------------- | ||
107 | |||
108 | The user interface for controlling dynamic PM is located in the power/ | ||
109 | subdirectory of each USB device's sysfs directory, that is, in | ||
110 | /sys/bus/usb/devices/.../power/ where "..." is the device's ID. The | ||
111 | relevant attribute files are: wakeup, level, and autosuspend. | ||
112 | |||
113 | power/wakeup | ||
114 | |||
115 | This file is empty if the device does not support | ||
116 | remote wakeup. Otherwise the file contains either the | ||
117 | word "enabled" or the word "disabled", and you can | ||
118 | write those words to the file. The setting determines | ||
119 | whether or not remote wakeup will be enabled when the | ||
120 | device is next suspended. (If the setting is changed | ||
121 | while the device is suspended, the change won't take | ||
122 | effect until the following suspend.) | ||
123 | |||
124 | power/level | ||
125 | |||
126 | This file contains one of three words: "on", "auto", | ||
127 | or "suspend". You can write those words to the file | ||
128 | to change the device's setting. | ||
129 | |||
130 | "on" means that the device should be resumed and | ||
131 | autosuspend is not allowed. (Of course, system | ||
132 | suspends are still allowed.) | ||
133 | |||
134 | "auto" is the normal state in which the kernel is | ||
135 | allowed to autosuspend and autoresume the device. | ||
136 | |||
137 | "suspend" means that the device should remain | ||
138 | suspended, and autoresume is not allowed. (But remote | ||
139 | wakeup may still be allowed, since it is controlled | ||
140 | separately by the power/wakeup attribute.) | ||
141 | |||
142 | power/autosuspend | ||
143 | |||
144 | This file contains an integer value, which is the | ||
145 | number of seconds the device should remain idle before | ||
146 | the kernel will autosuspend it (the idle-delay time). | ||
147 | The default is 2. 0 means to autosuspend as soon as | ||
148 | the device becomes idle, and -1 means never to | ||
149 | autosuspend. You can write a number to the file to | ||
150 | change the autosuspend idle-delay time. | ||
151 | |||
152 | Writing "-1" to power/autosuspend and writing "on" to power/level do | ||
153 | essentially the same thing -- they both prevent the device from being | ||
154 | autosuspended. Yes, this is a redundancy in the API. | ||
155 | |||
156 | (In 2.6.21 writing "0" to power/autosuspend would prevent the device | ||
157 | from being autosuspended; the behavior was changed in 2.6.22. The | ||
158 | power/autosuspend attribute did not exist prior to 2.6.21, and the | ||
159 | power/level attribute did not exist prior to 2.6.22.) | ||
160 | |||
161 | |||
162 | Changing the default idle-delay time | ||
163 | ------------------------------------ | ||
164 | |||
165 | The default autosuspend idle-delay time is controlled by a module | ||
166 | parameter in usbcore. You can specify the value when usbcore is | ||
167 | loaded. For example, to set it to 5 seconds instead of 2 you would | ||
168 | do: | ||
169 | |||
170 | modprobe usbcore autosuspend=5 | ||
171 | |||
172 | Equivalently, you could add to /etc/modprobe.conf a line saying: | ||
173 | |||
174 | options usbcore autosuspend=5 | ||
175 | |||
176 | Some distributions load the usbcore module very early during the boot | ||
177 | process, by means of a program or script running from an initramfs | ||
178 | image. To alter the parameter value you would have to rebuild that | ||
179 | image. | ||
180 | |||
181 | If usbcore is compiled into the kernel rather than built as a loadable | ||
182 | module, you can add | ||
183 | |||
184 | usbcore.autosuspend=5 | ||
185 | |||
186 | to the kernel's boot command line. | ||
187 | |||
188 | Finally, the parameter value can be changed while the system is | ||
189 | running. If you do: | ||
190 | |||
191 | echo 5 >/sys/module/usbcore/parameters/autosuspend | ||
192 | |||
193 | then each new USB device will have its autosuspend idle-delay | ||
194 | initialized to 5. (The idle-delay values for already existing devices | ||
195 | will not be affected.) | ||
196 | |||
197 | Setting the initial default idle-delay to -1 will prevent any | ||
198 | autosuspend of any USB device. This is a simple alternative to | ||
199 | disabling CONFIG_USB_SUSPEND and rebuilding the kernel, and it has the | ||
200 | added benefit of allowing you to enable autosuspend for selected | ||
201 | devices. | ||
202 | |||
203 | |||
204 | Warnings | ||
205 | -------- | ||
206 | |||
207 | The USB specification states that all USB devices must support power | ||
208 | management. Nevertheless, the sad fact is that many devices do not | ||
209 | support it very well. You can suspend them all right, but when you | ||
210 | try to resume them they disconnect themselves from the USB bus or | ||
211 | they stop working entirely. This seems to be especially prevalent | ||
212 | among printers and scanners, but plenty of other types of device have | ||
213 | the same deficiency. | ||
214 | |||
215 | For this reason, by default the kernel disables autosuspend (the | ||
216 | power/level attribute is initialized to "on") for all devices other | ||
217 | than hubs. Hubs, at least, appear to be reasonably well-behaved in | ||
218 | this regard. | ||
219 | |||
220 | (In 2.6.21 and 2.6.22 this wasn't the case. Autosuspend was enabled | ||
221 | by default for almost all USB devices. A number of people experienced | ||
222 | problems as a result.) | ||
223 | |||
224 | This means that non-hub devices won't be autosuspended unless the user | ||
225 | or a program explicitly enables it. As of this writing there aren't | ||
226 | any widespread programs which will do this; we hope that in the near | ||
227 | future device managers such as HAL will take on this added | ||
228 | responsibility. In the meantime you can always carry out the | ||
229 | necessary operations by hand or add them to a udev script. You can | ||
230 | also change the idle-delay time; 2 seconds is not the best choice for | ||
231 | every device. | ||
232 | |||
233 | Sometimes it turns out that even when a device does work okay with | ||
234 | autosuspend there are still problems. For example, there are | ||
235 | experimental patches adding autosuspend support to the usbhid driver, | ||
236 | which manages keyboards and mice, among other things. Tests with a | ||
237 | number of keyboards showed that typing on a suspended keyboard, while | ||
238 | causing the keyboard to do a remote wakeup all right, would | ||
239 | nonetheless frequently result in lost keystrokes. Tests with mice | ||
240 | showed that some of them would issue a remote-wakeup request in | ||
241 | response to button presses but not to motion, and some in response to | ||
242 | neither. | ||
243 | |||
244 | The kernel will not prevent you from enabling autosuspend on devices | ||
245 | that can't handle it. It is even possible in theory to damage a | ||
246 | device by suspending it at the wrong time -- for example, suspending a | ||
247 | USB hard disk might cause it to spin down without parking the heads. | ||
248 | (Highly unlikely, but possible.) Take care. | ||
249 | |||
250 | |||
251 | The driver interface for Power Management | ||
252 | ----------------------------------------- | ||
253 | |||
254 | The requirements for a USB driver to support external power management | ||
255 | are pretty modest; the driver need only define | ||
256 | |||
257 | .suspend | ||
258 | .resume | ||
259 | .reset_resume | ||
260 | |||
261 | methods in its usb_driver structure, and the reset_resume method is | ||
262 | optional. The methods' jobs are quite simple: | ||
263 | |||
264 | The suspend method is called to warn the driver that the | ||
265 | device is going to be suspended. If the driver returns a | ||
266 | negative error code, the suspend will be aborted. Normally | ||
267 | the driver will return 0, in which case it must cancel all | ||
268 | outstanding URBs (usb_kill_urb()) and not submit any more. | ||
269 | |||
270 | The resume method is called to tell the driver that the | ||
271 | device has been resumed and the driver can return to normal | ||
272 | operation. URBs may once more be submitted. | ||
273 | |||
274 | The reset_resume method is called to tell the driver that | ||
275 | the device has been resumed and it also has been reset. | ||
276 | The driver should redo any necessary device initialization, | ||
277 | since the device has probably lost most or all of its state | ||
278 | (although the interfaces will be in the same altsettings as | ||
279 | before the suspend). | ||
280 | |||
281 | The reset_resume method is used by the USB Persist facility (see | ||
282 | Documentation/usb/persist.txt) and it can also be used under certain | ||
283 | circumstances when CONFIG_USB_PERSIST is not enabled. Currently, if a | ||
284 | device is reset during a resume and the driver does not have a | ||
285 | reset_resume method, the driver won't receive any notification about | ||
286 | the resume. Later kernels will call the driver's disconnect method; | ||
287 | 2.6.23 doesn't do this. | ||
288 | |||
289 | USB drivers are bound to interfaces, so their suspend and resume | ||
290 | methods get called when the interfaces are suspended or resumed. In | ||
291 | principle one might want to suspend some interfaces on a device (i.e., | ||
292 | force the drivers for those interface to stop all activity) without | ||
293 | suspending the other interfaces. The USB core doesn't allow this; all | ||
294 | interfaces are suspended when the device itself is suspended and all | ||
295 | interfaces are resumed when the device is resumed. It isn't possible | ||
296 | to suspend or resume some but not all of a device's interfaces. The | ||
297 | closest you can come is to unbind the interfaces' drivers. | ||
298 | |||
299 | |||
300 | The driver interface for autosuspend and autoresume | ||
301 | --------------------------------------------------- | ||
302 | |||
303 | To support autosuspend and autoresume, a driver should implement all | ||
304 | three of the methods listed above. In addition, a driver indicates | ||
305 | that it supports autosuspend by setting the .supports_autosuspend flag | ||
306 | in its usb_driver structure. It is then responsible for informing the | ||
307 | USB core whenever one of its interfaces becomes busy or idle. The | ||
308 | driver does so by calling these three functions: | ||
309 | |||
310 | int usb_autopm_get_interface(struct usb_interface *intf); | ||
311 | void usb_autopm_put_interface(struct usb_interface *intf); | ||
312 | int usb_autopm_set_interface(struct usb_interface *intf); | ||
313 | |||
314 | The functions work by maintaining a counter in the usb_interface | ||
315 | structure. When intf->pm_usage_count is > 0 then the interface is | ||
316 | deemed to be busy, and the kernel will not autosuspend the interface's | ||
317 | device. When intf->pm_usage_count is <= 0 then the interface is | ||
318 | considered to be idle, and the kernel may autosuspend the device. | ||
319 | |||
320 | (There is a similar pm_usage_count field in struct usb_device, | ||
321 | associated with the device itself rather than any of its interfaces. | ||
322 | This field is used only by the USB core.) | ||
323 | |||
324 | The driver owns intf->pm_usage_count; it can modify the value however | ||
325 | and whenever it likes. A nice aspect of the usb_autopm_* routines is | ||
326 | that the changes they make are protected by the usb_device structure's | ||
327 | PM mutex (udev->pm_mutex); however drivers may change pm_usage_count | ||
328 | without holding the mutex. | ||
329 | |||
330 | usb_autopm_get_interface() increments pm_usage_count and | ||
331 | attempts an autoresume if the new value is > 0 and the | ||
332 | device is suspended. | ||
333 | |||
334 | usb_autopm_put_interface() decrements pm_usage_count and | ||
335 | attempts an autosuspend if the new value is <= 0 and the | ||
336 | device isn't suspended. | ||
337 | |||
338 | usb_autopm_set_interface() leaves pm_usage_count alone. | ||
339 | It attempts an autoresume if the value is > 0 and the device | ||
340 | is suspended, and it attempts an autosuspend if the value is | ||
341 | <= 0 and the device isn't suspended. | ||
342 | |||
343 | There also are a couple of utility routines drivers can use: | ||
344 | |||
345 | usb_autopm_enable() sets pm_usage_cnt to 1 and then calls | ||
346 | usb_autopm_set_interface(), which will attempt an autoresume. | ||
347 | |||
348 | usb_autopm_disable() sets pm_usage_cnt to 0 and then calls | ||
349 | usb_autopm_set_interface(), which will attempt an autosuspend. | ||
350 | |||
351 | The conventional usage pattern is that a driver calls | ||
352 | usb_autopm_get_interface() in its open routine and | ||
353 | usb_autopm_put_interface() in its close or release routine. But | ||
354 | other patterns are possible. | ||
355 | |||
356 | The autosuspend attempts mentioned above will often fail for one | ||
357 | reason or another. For example, the power/level attribute might be | ||
358 | set to "on", or another interface in the same device might not be | ||
359 | idle. This is perfectly normal. If the reason for failure was that | ||
360 | the device hasn't been idle for long enough, a delayed workqueue | ||
361 | routine is automatically set up to carry out the operation when the | ||
362 | autosuspend idle-delay has expired. | ||
363 | |||
364 | Autoresume attempts also can fail. This will happen if power/level is | ||
365 | set to "suspend" or if the device doesn't manage to resume properly. | ||
366 | Unlike autosuspend, there's no delay for an autoresume. | ||
367 | |||
368 | |||
369 | Other parts of the driver interface | ||
370 | ----------------------------------- | ||
371 | |||
372 | Sometimes a driver needs to make sure that remote wakeup is enabled | ||
373 | during autosuspend. For example, there's not much point | ||
374 | autosuspending a keyboard if the user can't cause the keyboard to do a | ||
375 | remote wakeup by typing on it. If the driver sets | ||
376 | intf->needs_remote_wakeup to 1, the kernel won't autosuspend the | ||
377 | device if remote wakeup isn't available or has been disabled through | ||
378 | the power/wakeup attribute. (If the device is already autosuspended, | ||
379 | though, setting this flag won't cause the kernel to autoresume it. | ||
380 | Normally a driver would set this flag in its probe method, at which | ||
381 | time the device is guaranteed not to be autosuspended.) | ||
382 | |||
383 | The usb_autopm_* routines have to run in a sleepable process context; | ||
384 | they must not be called from an interrupt handler or while holding a | ||
385 | spinlock. In fact, the entire autosuspend mechanism is not well geared | ||
386 | toward interrupt-driven operation. However there is one thing a | ||
387 | driver can do in an interrupt handler: | ||
388 | |||
389 | usb_mark_last_busy(struct usb_device *udev); | ||
390 | |||
391 | This sets udev->last_busy to the current time. udev->last_busy is the | ||
392 | field used for idle-delay calculations; updating it will cause any | ||
393 | pending autosuspend to be moved back. The usb_autopm_* routines will | ||
394 | also set the last_busy field to the current time. | ||
395 | |||
396 | Calling urb_mark_last_busy() from within an URB completion handler is | ||
397 | subject to races: The kernel may have just finished deciding the | ||
398 | device has been idle for long enough but not yet gotten around to | ||
399 | calling the driver's suspend method. The driver would have to be | ||
400 | responsible for synchronizing its suspend method with its URB | ||
401 | completion handler and causing the autosuspend to fail with -EBUSY if | ||
402 | an URB had completed too recently. | ||
403 | |||
404 | External suspend calls should never be allowed to fail in this way, | ||
405 | only autosuspend calls. The driver can tell them apart by checking | ||
406 | udev->auto_pm; this flag will be set to 1 for internal PM events | ||
407 | (autosuspend or autoresume) and 0 for external PM events. | ||
408 | |||
409 | Many of the ingredients in the autosuspend framework are oriented | ||
410 | towards interfaces: The usb_interface structure contains the | ||
411 | pm_usage_cnt field, and the usb_autopm_* routines take an interface | ||
412 | pointer as their argument. But somewhat confusingly, a few of the | ||
413 | pieces (usb_mark_last_busy() and udev->auto_pm) use the usb_device | ||
414 | structure instead. Drivers need to keep this straight; they can call | ||
415 | interface_to_usbdev() to find the device structure for a given | ||
416 | interface. | ||
417 | |||
418 | |||
419 | Locking requirements | ||
420 | -------------------- | ||
421 | |||
422 | All three suspend/resume methods are always called while holding the | ||
423 | usb_device's PM mutex. For external events -- but not necessarily for | ||
424 | autosuspend or autoresume -- the device semaphore (udev->dev.sem) will | ||
425 | also be held. This implies that external suspend/resume events are | ||
426 | mutually exclusive with calls to probe, disconnect, pre_reset, and | ||
427 | post_reset; the USB core guarantees that this is true of internal | ||
428 | suspend/resume events as well. | ||
429 | |||
430 | If a driver wants to block all suspend/resume calls during some | ||
431 | critical section, it can simply acquire udev->pm_mutex. | ||
432 | Alternatively, if the critical section might call some of the | ||
433 | usb_autopm_* routines, the driver can avoid deadlock by doing: | ||
434 | |||
435 | down(&udev->dev.sem); | ||
436 | rc = usb_autopm_get_interface(intf); | ||
437 | |||
438 | and at the end of the critical section: | ||
439 | |||
440 | if (!rc) | ||
441 | usb_autopm_put_interface(intf); | ||
442 | up(&udev->dev.sem); | ||
443 | |||
444 | Holding the device semaphore will block all external PM calls, and the | ||
445 | usb_autopm_get_interface() will prevent any internal PM calls, even if | ||
446 | it fails. (Exercise: Why?) | ||
447 | |||
448 | The rules for locking order are: | ||
449 | |||
450 | Never acquire any device semaphore while holding any PM mutex. | ||
451 | |||
452 | Never acquire udev->pm_mutex while holding the PM mutex for | ||
453 | a device that isn't a descendant of udev. | ||
454 | |||
455 | In other words, PM mutexes should only be acquired going up the device | ||
456 | tree, and they should be acquired only after locking all the device | ||
457 | semaphores you need to hold. These rules don't matter to drivers very | ||
458 | much; they usually affect just the USB core. | ||
459 | |||
460 | Still, drivers do need to be careful. For example, many drivers use a | ||
461 | private mutex to synchronize their normal I/O activities with their | ||
462 | disconnect method. Now if the driver supports autosuspend then it | ||
463 | must call usb_autopm_put_interface() from somewhere -- maybe from its | ||
464 | close method. It should make the call while holding the private mutex, | ||
465 | since a driver shouldn't call any of the usb_autopm_* functions for an | ||
466 | interface from which it has been unbound. | ||
467 | |||
468 | But the usb_autpm_* routines always acquire the device's PM mutex, and | ||
469 | consequently the locking order has to be: private mutex first, PM | ||
470 | mutex second. Since the suspend method is always called with the PM | ||
471 | mutex held, it mustn't try to acquire the private mutex. It has to | ||
472 | synchronize with the driver's I/O activities in some other way. | ||
473 | |||
474 | |||
475 | Interaction between dynamic PM and system PM | ||
476 | -------------------------------------------- | ||
477 | |||
478 | Dynamic power management and system power management can interact in | ||
479 | a couple of ways. | ||
480 | |||
481 | Firstly, a device may already be manually suspended or autosuspended | ||
482 | when a system suspend occurs. Since system suspends are supposed to | ||
483 | be as transparent as possible, the device should remain suspended | ||
484 | following the system resume. The 2.6.23 kernel obeys this principle | ||
485 | for manually suspended devices but not for autosuspended devices; they | ||
486 | do get resumed when the system wakes up. (Presumably they will be | ||
487 | autosuspended again after their idle-delay time expires.) In later | ||
488 | kernels this behavior will be fixed. | ||
489 | |||
490 | (There is an exception. If a device would undergo a reset-resume | ||
491 | instead of a normal resume, and the device is enabled for remote | ||
492 | wakeup, then the reset-resume takes place even if the device was | ||
493 | already suspended when the system suspend began. The justification is | ||
494 | that a reset-resume is a kind of remote-wakeup event. Or to put it | ||
495 | another way, a device which needs a reset won't be able to generate | ||
496 | normal remote-wakeup signals, so it ought to be resumed immediately.) | ||
497 | |||
498 | Secondly, a dynamic power-management event may occur as a system | ||
499 | suspend is underway. The window for this is short, since system | ||
500 | suspends don't take long (a few seconds usually), but it can happen. | ||
501 | For example, a suspended device may send a remote-wakeup signal while | ||
502 | the system is suspending. The remote wakeup may succeed, which would | ||
503 | cause the system suspend to abort. If the remote wakeup doesn't | ||
504 | succeed, it may still remain active and thus cause the system to | ||
505 | resume as soon as the system suspend is complete. Or the remote | ||
506 | wakeup may fail and get lost. Which outcome occurs depends on timing | ||
507 | and on the hardware and firmware design. | ||
508 | |||
509 | More interestingly, a device might undergo a manual resume or | ||
510 | autoresume during system suspend. With current kernels this shouldn't | ||
511 | happen, because manual resumes must be initiated by userspace and | ||
512 | autoresumes happen in response to I/O requests, but all user processes | ||
513 | and I/O should be quiescent during a system suspend -- thanks to the | ||
514 | freezer. However there are plans to do away with the freezer, which | ||
515 | would mean these things would become possible. If and when this comes | ||
516 | about, the USB core will carefully arrange matters so that either type | ||
517 | of resume will block until the entire system has resumed. | ||