adulau/aha
1
0
Fork 0
mirror of https://github.com/adulau/aha.git synced 2024-12-27 03:06:10 +00:00
Code Issues Projects Releases Packages Wiki Activity

USB: power management documentation update

Browse source 
This patch (as1313) updates the documentation concerning USB power
management.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This commit is contained in:
Alan Stern 2009-12-08 15:49:48 -05:00 committed by Greg Kroah-Hartman
parent f42ecb2808
commit baf67741bf
2 changed files with 25 additions and 34 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
Documentation/ABI/testing/sysfs-bus-usb
View file

@ -21,25 +21,27 @@ Contact: Alan Stern <stern@rowland.harvard.edu>
Description: Description:
Each USB device directory will contain a file named Each USB device directory will contain a file named
power/level. This file holds a power-level setting for power/level. This file holds a power-level setting for
the device, one of "on", "auto", or "suspend". the device, either "on" or "auto".
"on" means that the device is not allowed to autosuspend, "on" means that the device is not allowed to autosuspend,
although normal suspends for system sleep will still although normal suspends for system sleep will still
be honored. "auto" means the device will autosuspend be honored. "auto" means the device will autosuspend
and autoresume in the usual manner, according to the and autoresume in the usual manner, according to the
capabilities of its driver. "suspend" means the device capabilities of its driver.
is forced into a suspended state and it will not autoresume
in response to I/O requests. However remote-wakeup requests
from the device may still be enabled (the remote-wakeup
setting is controlled separately by the power/wakeup
attribute).
During normal use, devices should be left in the "auto" During normal use, devices should be left in the "auto"
level. The other levels are meant for administrative uses. level. The "on" level is meant for administrative uses.
If you want to suspend a device immediately but leave it If you want to suspend a device immediately but leave it
free to wake up in response to I/O requests, you should free to wake up in response to I/O requests, you should
write "0" to power/autosuspend. write "0" to power/autosuspend.
Device not capable of proper suspend and resume should be
left in the "on" level. Although the USB spec requires
devices to support suspend/resume, many of them do not.
In fact so many don't that by default, the USB core
initializes all non-hub devices in the "on" level. Some
drivers may change this setting when they are bound.
What: /sys/bus/usb/devices/.../power/persist What: /sys/bus/usb/devices/.../power/persist
Date: May 2007 Date: May 2007
KernelVersion: 2.6.23 KernelVersion: 2.6.23

41
Documentation/usb/power-management.txt
View file

@ -71,12 +71,10 @@ being accessed through sysfs, then it definitely is idle.
Forms of dynamic PM Forms of dynamic PM
------------------- -------------------
Dynamic suspends can occur in two ways: manual and automatic. Dynamic suspends occur when the kernel decides to suspend an idle
"Manual" means that the user has told the kernel to suspend a device, device. This is called "autosuspend" for short. In general, a device
whereas "automatic" means that the kernel has decided all by itself to won't be autosuspended unless it has been idle for some minimum period
suspend a device. Automatic suspend is called "autosuspend" for of time, the so-called idle-delay time.
short. In general, a device won't be autosuspended unless it has been
idle for some minimum period of time, the so-called idle-delay time.
Of course, nothing the kernel does on its own initiative should Of course, nothing the kernel does on its own initiative should
prevent the computer or its devices from working properly. If a prevent the computer or its devices from working properly. If a
@ -96,10 +94,11 @@ idle.
We can categorize power management events in two broad classes: We can categorize power management events in two broad classes:
external and internal. External events are those triggered by some external and internal. External events are those triggered by some
agent outside the USB stack: system suspend/resume (triggered by agent outside the USB stack: system suspend/resume (triggered by
userspace), manual dynamic suspend/resume (also triggered by userspace), manual dynamic resume (also triggered by userspace), and
userspace), and remote wakeup (triggered by the device). Internal remote wakeup (triggered by the device). Internal events are those
events are those triggered within the USB stack: autosuspend and triggered within the USB stack: autosuspend and autoresume. Note that
autoresume. all dynamic suspend events are internal; external agents are not
allowed to issue dynamic suspends.
The user interface for dynamic PM The user interface for dynamic PM
@ -145,9 +144,9 @@ relevant attribute files are: wakeup, level, and autosuspend.
number of seconds the device should remain idle before number of seconds the device should remain idle before
the kernel will autosuspend it (the idle-delay time). the kernel will autosuspend it (the idle-delay time).
The default is 2. 0 means to autosuspend as soon as The default is 2. 0 means to autosuspend as soon as
the device becomes idle, and -1 means never to the device becomes idle, and negative values mean
autosuspend. You can write a number to the file to never to autosuspend. You can write a number to the
change the autosuspend idle-delay time. file to change the autosuspend idle-delay time.
Writing "-1" to power/autosuspend and writing "on" to power/level do Writing "-1" to power/autosuspend and writing "on" to power/level do
essentially the same thing -- they both prevent the device from being essentially the same thing -- they both prevent the device from being
@ -377,9 +376,9 @@ the device hasn't been idle for long enough, a delayed workqueue
routine is automatically set up to carry out the operation when the routine is automatically set up to carry out the operation when the
autosuspend idle-delay has expired. autosuspend idle-delay has expired.
Autoresume attempts also can fail. This will happen if power/level is Autoresume attempts also can fail, although failure would mean that
set to "suspend" or if the device doesn't manage to resume properly. the device is no longer present or operating properly. Unlike
Unlike autosuspend, there's no delay for an autoresume. autosuspend, there's no delay for an autoresume.
Other parts of the driver interface Other parts of the driver interface
@ -527,13 +526,3 @@ succeed, it may still remain active and thus cause the system to
resume as soon as the system suspend is complete. Or the remote resume as soon as the system suspend is complete. Or the remote
wakeup may fail and get lost. Which outcome occurs depends on timing wakeup may fail and get lost. Which outcome occurs depends on timing
and on the hardware and firmware design. and on the hardware and firmware design.
More interestingly, a device might undergo a manual resume or
autoresume during system suspend. With current kernels this shouldn't
happen, because manual resumes must be initiated by userspace and
autoresumes happen in response to I/O requests, but all user processes
and I/O should be quiescent during a system suspend -- thanks to the
freezer. However there are plans to do away with the freezer, which
would mean these things would become possible. If and when this comes
about, the USB core will carefully arrange matters so that either type
of resume will block until the entire system has resumed.