Beruflich Dokumente
Kultur Dokumente
1 of 8
http://blogs.msdn.com/b/usbcoreblog/archive/2011/05/11/demystifying...
Hi, I am Vivek Gupta, a software developer on the USB team. In this blog, I am going to talk
about why USB selective suspend mechanism is needed and important, and how to implement
it correctly in devices and drivers. I will start by discussing the concept of run-time power
management in devices, discuss the USB specific mechanism of selective suspend and finally
cover how this mechanism is implemented in USB 3.0.
26.10.2014 15:53
2 of 8
http://blogs.msdn.com/b/usbcoreblog/archive/2011/05/11/demystifying...
power, then their parent nodes go to lower power (assuming that they are idle), and so on
until the root of the tree goes to lower power. Note that the wake-up mechanism described in
the previous section will be repeated at each level in this node. Before any device can enter
working state, all nodes (between that device and the root) must be in working state.
Selective Suspend
Now that we understand the concept of run-time power management, let us get into more
details about USB devices. A USB 2.0 device is sent to suspend state by first putting the port to
which the device is attached, into a suspend state. That is done by sending a control transfer to
the hub if the device is attached through a hub, or by manipulating port registers if the device
is connected directly to the root hub.
After the port is suspended, the parent controller or the hub stops sending SOFs (Start of
Frames) to the USB device. When a USB device does not receive SOFs for 3ms, the device goes
into suspend state. This mechanism is known as selective suspend. The term selective suspend
refers to sending only a part of the USB tree to suspend state as opposed to global suspend
that refers to sending the entire bus in suspend state by stopping SOFs at the controller level.
To understand how software and hardware work together in selective suspend, consider an
example of a USB mouse attached to a USB host controller as shown in the following
illustration.
26.10.2014 15:53
3 of 8
http://blogs.msdn.com/b/usbcoreblog/archive/2011/05/11/demystifying...
as it arrives. Because the mouse driver is the power policy owner, the driver keeps track of the
mouse usage and detects when the mouse is idle. The preceding diagram illustrates this setup.
Note: If there is a hub in between the controller and mouse, the port-suspend operation is
accomplished by sending a control transfer to that hub rather than performing register
operations. Also, the hub driver and other drivers in the USB driver stack are coordinated to
interact with the hardware. That interaction is not shown in the preceding illustration for
brevity.
Remote Wake-up
When a user wiggles the mouse, the mouse generates a particular resume signal on the wire
upstream. The controller receives that resume signal and propagates back the signal to the
mouse downstream. The controller then notifies the USB driver stack that the port has
resumed by completing the interrupt transfer. The USB driver stack notifies the mouse driver
that the mouse has entered working state by completing the wait wake IRP that the mouse
driver had sent earlier. The mouse driver then sends a set-power IRP requesting D0 power
26.10.2014 15:53
4 of 8
http://blogs.msdn.com/b/usbcoreblog/archive/2011/05/11/demystifying...
state (D0 IRP) to its device stack to bring the mouse back to working state. The D0 IRP is first
handled by the hub driver. Because the port has already resumed, the hub driver completes
IRP without any processing. Upon completion, the D0 IRP then reaches the mouse driver. In
the completion routine, the mouse driver can send an interrupt transfer to get mouse activity
and resume normal functioning. The following figure illustrates this process.
Note that the ability of the mouse to send the resume signal is only activated after the mouse
is in suspend state. If the mouse is not in suspend state, the mouse driver sends one or more
pending interrupt transfers to know about user events. Thus, software can always respond to
user events on the mouse within a reasonable period of time.
If we look at the functionality implemented by the mouse driver in the preceding scenario, it
has used the generic mechanisms consisting of D-IRPs and wait wake IRPs, provided by
Windows to implement selective suspend. Certain USB client drivers cannot use those
mechanisms and need to implement a more involved method that requires sending the
IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION I/O control request. Let us see why that is
the case.
26.10.2014 15:53
5 of 8
http://blogs.msdn.com/b/usbcoreblog/archive/2011/05/11/demystifying...
26.10.2014 15:53
6 of 8
http://blogs.msdn.com/b/usbcoreblog/archive/2011/05/11/demystifying...
A function driver need not implement the idle IRP mechanism and can use the D IRP
mechanism in the following cases:
A function driver, which does not depend on the resume signal notification, does not
need to know whether or not other functions are idle. In that case, it is ok even if the
device does not end up going to selective suspend.
A function driver that controls a single function device.
It should be noted that even though I say that the D-IRP mechanism might be good enough in
the above scenarios, a driver might still need to implement the Idle IRP mechanism, if the
driver is intended to run on versions of the Windows operating system earlier than Windows
Vista. For information about the combination of OS versions and device types, which require
the idle IRP mechanism, see USB Selective Suspend.
Certain function drivers are written to work for both non-composite devices and composite
devices, so those drivers end up implementing the idle IRP mechanism and using it regardless
of whether they are working on single-function and multi-function devices.
26.10.2014 15:53
7 of 8
http://blogs.msdn.com/b/usbcoreblog/archive/2011/05/11/demystifying...
and the device can communicate that data back to the driver. This ensures that the user does
not have to repeat an action such as pressing keys of a keyboard.
Function Suspend
The USB 3.0 specification also defines the function suspend feature, which is related to the
selective suspend feature, from the point of the function drivers. In a USB 3.0 composite
device, a function can be suspended independent of whether other functions in the device are
in working or idle state. So when a function driver requests a low power transition, the
corresponding function must be sent to suspend state. When all the functions are in suspend
state, the device can be sent to suspend state by sending the upstream link to U3. Not only
can the individual functions be suspended, they can also be armed for remote wake-up
independently. Therefore, a function can be suspended and woken up, even if other functions
are not in a suspended state. Therefore, the idle IRP mechanism that was described previously
is not needed for USB 3.0 composite devices. When a function wakes up, it sends a wake up
notification packet that informs the host which device and the exact function that woke up.
Using that information, the USB driver stack can complete the wait wake IRP for the function
that woke up and avoid the need to wake other functions that are in suspend state.
A function is armed for remove wake-up and suspend by sending a control transfer to the first
interface of the function. Non-composite devices are considered a special case of composite
devices. To arm a non-composite device for wake-up, the function driver must send a control
transfer to the first interface in the selected configuration. Note that arming the device for
remote wake-up does not apply. One consequence of this design is that depending on
whether a device is a non-composite or composite, different drivers in the USB driver stack are
responsible for arming the device for remote wake-up. If a composite device uses a
customized driver instead of the USBCCGP, the custom driver must inform the USB driver stack
that the driver will handle the arming process.
26.10.2014 15:53
8 of 8
http://blogs.msdn.com/b/usbcoreblog/archive/2011/05/11/demystifying...
It's already high time MS developed generic XHCI drivers for Windows XP, Vista, 7 and 8.
Under the section "importance of Selective Suspend" can you elaborate if the Hubs and controllers
actually goto Dx if the dveices connected to them are all in Dx? I dont see the root hubs goto Dx?
Thx,
This is an excellent article. The only thing I would ask is if there is a way to know the default timeout for
Selective Suspend to occur. After how long and under what conditions does Selective Suspend activate?
I enjoy music over the internet but this function, selective suspend, causes the streaming to stop. My
power settings are at "never" for causing my computer to go to sleep and for turning off the screen, but
all of a sudden, my music ends because it says selective suspend was implemented. I've had bad
experiences with CD players breaking and one needs to constantly change the CD. I am recovering from
injuries to my brain and I would like to just listen non-stop to music until I desire to turn it off. Your
article is good and I am understanding somewhat the importance of selective suspend (and having my
computer going into low power) but what do I do if I want the music to keep playing throughout the
day? Thank you.
26.10.2014 15:53