aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/usb/power-management.txt
diff options
context:
space:
mode:
authorAlan Stern <stern@rowland.harvard.edu>2009-12-07 13:01:37 -0500
committerGreg Kroah-Hartman <gregkh@suse.de>2009-12-11 14:55:25 -0500
commit8e4ceb38eb5bbaef22fc00abe9bc11e26bea2ab5 (patch)
tree7cb5fee6c50add1094aed430d46afeb2c7689b51 /Documentation/usb/power-management.txt
parent9af23624ae2c7978313b46e58fdc4ca5d8b799f5 (diff)
USB: prepare for changover to Runtime PM framework
This patch (as1303) revises the USB Power Management infrastructure to make it compatible with the new driver-model Runtime PM framework: Drivers are no longer allowed to access intf->pm_usage_cnt directly; the PM framework manages its own usage counters. usb_autopm_set_interface() is eliminated, because it directly sets intf->pm_usage_cnt. usb_autopm_enable() and usb_autopm_disable() are eliminated, because they call usb_autopm_set_interface(). usb_autopm_get_interface_no_resume() and usb_autopm_put_interface_no_suspend() are added. They correspond to pm_runtime_get_noresume() and pm_runtime_put_noidle() in the PM framework. The power/level attribute no longer accepts "suspend", only "on" and "auto". The PM framework doesn't allow devices to be forced into a suspended mode. The hub driver contains the only code that violates the new guidelines. It is updated to use the new interface routines instead. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'Documentation/usb/power-management.txt')
-rw-r--r--Documentation/usb/power-management.txt60
1 files changed, 28 insertions, 32 deletions
diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt
index 8817368203d6..c7c1dc2f8017 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -2,7 +2,7 @@
2 2
3 Alan Stern <stern@rowland.harvard.edu> 3 Alan Stern <stern@rowland.harvard.edu>
4 4
5 October 5, 2007 5 November 10, 2009
6 6
7 7
8 8
@@ -123,9 +123,9 @@ relevant attribute files are: wakeup, level, and autosuspend.
123 123
124 power/level 124 power/level
125 125
126 This file contains one of three words: "on", "auto", 126 This file contains one of two words: "on" or "auto".
127 or "suspend". You can write those words to the file 127 You can write those words to the file to change the
128 to change the device's setting. 128 device's setting.
129 129
130 "on" means that the device should be resumed and 130 "on" means that the device should be resumed and
131 autosuspend is not allowed. (Of course, system 131 autosuspend is not allowed. (Of course, system
@@ -134,10 +134,10 @@ relevant attribute files are: wakeup, level, and autosuspend.
134 "auto" is the normal state in which the kernel is 134 "auto" is the normal state in which the kernel is
135 allowed to autosuspend and autoresume the device. 135 allowed to autosuspend and autoresume the device.
136 136
137 "suspend" means that the device should remain 137 (In kernels up to 2.6.32, you could also specify
138 suspended, and autoresume is not allowed. (But remote 138 "suspend", meaning that the device should remain
139 wakeup may still be allowed, since it is controlled 139 suspended and autoresume was not allowed. This
140 separately by the power/wakeup attribute.) 140 setting is no longer supported.)
141 141
142 power/autosuspend 142 power/autosuspend
143 143
@@ -313,13 +313,14 @@ three of the methods listed above. In addition, a driver indicates
313that it supports autosuspend by setting the .supports_autosuspend flag 313that it supports autosuspend by setting the .supports_autosuspend flag
314in its usb_driver structure. It is then responsible for informing the 314in its usb_driver structure. It is then responsible for informing the
315USB core whenever one of its interfaces becomes busy or idle. The 315USB core whenever one of its interfaces becomes busy or idle. The
316driver does so by calling these five functions: 316driver does so by calling these six functions:
317 317
318 int usb_autopm_get_interface(struct usb_interface *intf); 318 int usb_autopm_get_interface(struct usb_interface *intf);
319 void usb_autopm_put_interface(struct usb_interface *intf); 319 void usb_autopm_put_interface(struct usb_interface *intf);
320 int usb_autopm_set_interface(struct usb_interface *intf);
321 int usb_autopm_get_interface_async(struct usb_interface *intf); 320 int usb_autopm_get_interface_async(struct usb_interface *intf);
322 void usb_autopm_put_interface_async(struct usb_interface *intf); 321 void usb_autopm_put_interface_async(struct usb_interface *intf);
322 void usb_autopm_get_interface_no_resume(struct usb_interface *intf);
323 void usb_autopm_put_interface_no_suspend(struct usb_interface *intf);
323 324
324The functions work by maintaining a counter in the usb_interface 325The functions work by maintaining a counter in the usb_interface
325structure. When intf->pm_usage_count is > 0 then the interface is 326structure. When intf->pm_usage_count is > 0 then the interface is
@@ -331,11 +332,13 @@ considered to be idle, and the kernel may autosuspend the device.
331associated with the device itself rather than any of its interfaces. 332associated with the device itself rather than any of its interfaces.
332This field is used only by the USB core.) 333This field is used only by the USB core.)
333 334
334The driver owns intf->pm_usage_count; it can modify the value however 335Drivers must not modify intf->pm_usage_count directly; its value
335and whenever it likes. A nice aspect of the non-async usb_autopm_* 336should be changed only be using the functions listed above. Drivers
336routines is that the changes they make are protected by the usb_device 337are responsible for insuring that the overall change to pm_usage_count
337structure's PM mutex (udev->pm_mutex); however drivers may change 338during their lifetime balances out to 0 (it may be necessary for the
338pm_usage_count without holding the mutex. Drivers using the async 339disconnect method to call usb_autopm_put_interface() one or more times
340to fulfill this requirement). The first two routines use the PM mutex
341in struct usb_device for mutual exclusion; drivers using the async
339routines are responsible for their own synchronization and mutual 342routines are responsible for their own synchronization and mutual
340exclusion. 343exclusion.
341 344
@@ -347,11 +350,6 @@ exclusion.
347 attempts an autosuspend if the new value is <= 0 and the 350 attempts an autosuspend if the new value is <= 0 and the
348 device isn't suspended. 351 device isn't suspended.
349 352
350 usb_autopm_set_interface() leaves pm_usage_count alone.
351 It attempts an autoresume if the value is > 0 and the device
352 is suspended, and it attempts an autosuspend if the value is
353 <= 0 and the device isn't suspended.
354
355 usb_autopm_get_interface_async() and 353 usb_autopm_get_interface_async() and
356 usb_autopm_put_interface_async() do almost the same things as 354 usb_autopm_put_interface_async() do almost the same things as
357 their non-async counterparts. The differences are: they do 355 their non-async counterparts. The differences are: they do
@@ -360,13 +358,11 @@ exclusion.
360 such as an URB's completion handler, but when they return the 358 such as an URB's completion handler, but when they return the
361 device will not generally not yet be in the desired state. 359 device will not generally not yet be in the desired state.
362 360
363There also are a couple of utility routines drivers can use: 361 usb_autopm_get_interface_no_resume() and
364 362 usb_autopm_put_interface_no_suspend() merely increment or
365 usb_autopm_enable() sets pm_usage_cnt to 0 and then calls 363 decrement the pm_usage_count value; they do not attempt to
366 usb_autopm_set_interface(), which will attempt an autosuspend. 364 carry out an autoresume or an autosuspend. Hence they can be
367 365 called in an atomic context.
368 usb_autopm_disable() sets pm_usage_cnt to 1 and then calls
369 usb_autopm_set_interface(), which will attempt an autoresume.
370 366
371The conventional usage pattern is that a driver calls 367The conventional usage pattern is that a driver calls
372usb_autopm_get_interface() in its open routine and 368usb_autopm_get_interface() in its open routine and
@@ -400,11 +396,11 @@ though, setting this flag won't cause the kernel to autoresume it.
400Normally a driver would set this flag in its probe method, at which 396Normally a driver would set this flag in its probe method, at which
401time the device is guaranteed not to be autosuspended.) 397time the device is guaranteed not to be autosuspended.)
402 398
403The usb_autopm_* routines have to run in a sleepable process context; 399The synchronous usb_autopm_* routines have to run in a sleepable
404they must not be called from an interrupt handler or while holding a 400process context; they must not be called from an interrupt handler or
405spinlock. In fact, the entire autosuspend mechanism is not well geared 401while holding a spinlock. In fact, the entire autosuspend mechanism
406toward interrupt-driven operation. However there is one thing a 402is not well geared toward interrupt-driven operation. However there
407driver can do in an interrupt handler: 403is one thing a driver can do in an interrupt handler:
408 404
409 usb_mark_last_busy(struct usb_device *udev); 405 usb_mark_last_busy(struct usb_device *udev);
410 406