demystifying usb selective suspend - microsoft windows usb core team blog - site home - msdn blogs

Demystifying USB Selective Suspend5USB Blog 10 May 2011 4:08 PM

Hi, I am Vivek Gupta, a software developer on the USB team. In this blog, I am going to talkabout why USB selective suspend mechanism is needed and important, and how to implementit correctly in devices and drivers. I will start by discussing the concept of run-time powermanagement in devices, discuss the USB specific mechanism of selective suspend and finallycover how this mechanism is implemented in USB 3.0.

Run-Time Power ManagementBefore we talk about selective suspend, lets understand a more generic concept: run-timepower management.

One way of conserving power in a system is to send the whole system to a low-power statesuch as sleep or hibernate. Because this mechanism requires turning off the system, it is onlypossible when the whole system is not in use. Even when the whole system is in use and is inworking state, it is quite likely that certain components of the system are not active. Thosecomponents are said to be in an idle state. Run-time power management refers to sending idlecomponents to a lower power state, until they need to be used again. The components can behardware such as processor, memory, and so on; however in this discussion, we are onlyinterested in run time power management of devices.

Devices and device drivers should aggressively pursue run-time power management of devicesbecause the mechanism can lead to significant power savings. Because a driver stack includesmore than one driver, coordination between drivers is required while sending the device to alower power state and bringing it back to working state. Both Windows Driver Model (WDM)and Kernel-Mode Driver Framework provide mechanisms for this coordination. One driver inthe device stack, typically the function driver, is the power policy owner. This power policyowner is responsible for detecting that the device is idle and initiating the process oftransitioning the device into a lower power state. The power policy owner is also responsiblefor bringing the device back to working state, (also referred to as waking up the device) whenthe user needs to use that device.

Host-Initiated and Device-Initiated Wake-upHow would the power policy owner driver know about the users intent to use a device, so thatthe driver can wake up the device? That depends on the kind of device. Let us say, a storagedevice that is in a low-power state, and a user needs to transfer a file from or to that device.When the user initiates the transfer process (by using a certain application), the power policyowner gets an I/O request from the application, and knows that it needs to wake up thedevice. However, if the device is a mouse, the device must send some sort of signal to initiatethe wake-up process. The device-initiated power transition is known as remote wake-up featurein the USB world. Because the mouse needs to generate such a resume signal, it cannotcompletely turn itself off. Typically, the ability of the device to generate the resume signal isprogrammable. Therefore, before putting the device to sleep, the driver must instruct thedevice to turn on the remote wake-up feature when the device is suspended. This process iscalled arming the device for remote wake-up.

Wake-up Propagation in SoftwareTypically, the bus driver (driver that manages the PDO) in a device stack receives notificationabout the resume signal from the device and notifies the function driver about the arrival ofthe signal. In Windows, to get that notification, the function driver sends a wait wake IRP(IRP_MN_WAIT_WAKE) to the bus driver. The bus driver keeps the IRP pending during the timethe device is in the low-power state. When the bus driver receives notification about the wakesignal from the device, the bus driver notifies the function driver by completing the previouslysent wait wake IRP.

Parent/Child Power RelationshipA device stack managing a parent device cannot transition to lower power state until all of itschildren are in low-power states. That is because a child device in working state typicallyrequires its parent device to be in working state. For example, if a USB device is connectedthrough a hub, the hub must be in working state for transfers to complete successfully.

After all of the children device stacks enter low-power states, the parent device stack can thengo to a lower power state as well. Thus in a tree of devices, first the leaf nodes go to lower

Demystifying USB Selective Suspend - Microsoft Windows USB Core... http://blogs.msdn.com/b/usbcoreblog/archive/2011/05/11/demystifying...

1 of 8 26.10.2014 15:53

power, then their parent nodes go to lower power (assuming that they are idle), and so onuntil the root of the tree goes to lower power. Note that the wake-up mechanism described inthe previous section will be repeated at each level in this node. Before any device can enterworking state, all nodes (between that device and the root) must be in working state.

Selective SuspendNow that we understand the concept of run-time power management, let us get into moredetails about USB devices. A USB 2.0 device is sent to suspend state by first putting the port towhich the device is attached, into a suspend state. That is done by sending a control transfer tothe hub if the device is attached through a hub, or by manipulating port registers if the deviceis connected directly to the root hub.

After the port is suspended, the parent controller or the hub stops sending SOFs (Start ofFrames) to the USB device. When a USB device does not receive SOFs for 3ms, the device goesinto suspend state. This mechanism is known as selective suspend. The term selective suspendrefers to sending only a part of the USB tree to suspend state as opposed to global suspendthat 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 anexample of a USB mouse attached to a USB host controller as shown in the followingillustration.

Device in Working StateTypically, multiple device stacks are involved in the management of a USB mouse. However, forthe purposes of this discussion, we will collectively refer to all the drivers above the USB driverstack as the mouse driver. In the simplistic illustration that shows the device stacks, hubdriver is the bus driver for the device and the mouse driver is the function driver. The mousedriver is also the power policy owner for the device. Arrow labeled Power Policy Owner in thepreceding illustration points to the specific drivers that are power policy owner in the devicestack for the USB HID device. The device has an interrupt endpoint that it uses to send dataabout various user-initiated events like button presses. The mouse driver typically keeps one ormore interrupt transfers pending with the USB core stack to receive this data from the mouse


2 of 8 26.10.2014 15:53

as it arrives. Because the mouse driver is the power policy owner, the driver keeps track of themouse usage and detects when the mouse is idle. The preceding diagram illustrates this setup.

Going to Lower PowerAfter the mouse driver detects that the device is idle, the driver starts the process of sendingthe mouse to lower power. The mouse driver sends a wait wake IRP to the hub driver. The hubdriver pends and stores away that IRP. The mouse driver then initiates transition to lowerpower state by requesting a set-power IRP (IRP_MN_SET_POWER) with D2 as the target stateon its device stack. The D2 IRP first arrives on the mouse driver and as part of handling the IRP,the mouse driver cancels its pending interrupt transfers. Then, the hub driver receives the D2IRP. Because the wait wake IRP is pending, the hub driver sends a control transfer to the deviceto arm the device for remote wake-up, and then suspends the port by manipulating certainport registers on the controller. The device transitions to a lower power state and only retainsenough power to detect wake-up events and generate a resume signal on those events. Thefollowing diagram illustrates this process.

Note: If there is a hub in between the controller and mouse, the port-suspend operation isaccomplished by sending a control transfer to that hub rather than performing registeroperations. Also, the hub driver and other drivers in the USB driver stack are coordinated tointeract with the hardware. That interaction is not shown in the preceding illustration forbrevity.

Remote Wake-upWhen a user wiggles the mouse, the mouse generates a particular resume signal on the wireupstream. The controller receives that resume signal and propagates back the signal to themouse downstream. The controller then notifies the USB driver stack that the port hasresumed by completing the interrupt transfer. The USB driver stack notifies the mouse driverthat the mouse has entered working state by completing the wait wake IRP that the mousedriver had sent earlier. The mouse driver then sends a set-power IRP requesting D0 power


3 of 8 26.10.2014 15:53

state (D0 IRP) to its device stack to bring the mouse back to working state. The D0 IRP is firsthandled by the hub driver. Because the port has already resumed, the hub driver completesIRP without any processing. Upon completion, the D0 IRP then reaches the mouse driver. Inthe completion routine, the mouse driver can send an interrupt transfer to get mouse activityand 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 mouseis in suspend state. If the mouse is not in suspend state, the mouse driver sends one or morepending interrupt transfers to know about user events. Thus, software can always respond touser 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, ithas used the generic mechanisms consisting of D-IRPs and wait wake IRPs, provided byWindows to implement selective suspend. Certain USB client drivers cannot use thosemechanisms and need to implement a more involved method that requires sending theIOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION I/O control request. Let us see why that isthe case.

Implementing Selective Suspend in Multi-Function DevicesUSB specification allows a USB device to implement multiple functions that are activesimultaneously, such multi-function devices are also known as composite devices. For examplea composite device might contain a function for keyboard and another function for mouse.The Microsoft-provided USBCCGP driver typically loads as the function driver for compositedevices and enumerates a PDO for each of the supported functions. Those individual PDOs aremanaged by their respective USB function drivers like the mouse driver. The followingillustration shows the device stacks for the example.


4 of 8 26.10.2014 15:53

Issue with D-IRP mechanism for Composite DevicesNow let us see what happens if the function drivers managing individual functions of thecomposite device, in the preceding example, tried to use the D-IRP mechanism to do run-timepower management. Each of those function drivers will have interrupt transfers pending totheir respective interrupt endpoints. Each of the functions can become idle independently. Forinstance, consider the scenario where the mouse function becomes idle while the keyboard isstill being used. The mouse driver for the mouse sends a wait wake IRP, cancels its interrupttransfer, and then sends a D2 IRP. Because the keyboard is still in the working state, USBCCGPstack cannot go to a low-power state. In USB 2.0, the only way for any part of the device to goto a low-power state is for the entire device to enter selective suspend. The device cannot turnon its ability to send a resume signal because the device is not in suspend state. So, if a userevent occurs on the mouse, there is no way for the mouse to notify the mouse driver as thereare no pending interrupt transfers with the mouse. In other words, mouse is unusable until thekeyboard also becomes idle, which could be indefinitely long!

Idle IRP MechanismBased on the preceding scenario, it becomes clear that the only time a composite device canenter suspend state is when all of the functions are idle. In addition, each function driver caninitiate transition to lower power only when the function knows that all other functions are inidle state. In order to accomplish this, Windows defines a two-step process called the idle IRPmechanism:

1. The function driver notifies the USB driver stack about the drivers intent to go to a lowpower state by sending the IOCTL_INTERNAL_USB_SUBMIT_IDLE_NOTIFICATION I/O controlrequest.

2. When all of the functions are ready to go to idle state, USB driver stack notifies the functiondrivers by invoking the idle callback routines implemented by the function driver. Only thencan the function driver go to a low-power state.

In case of a composite device, USBCCGP implements the task of coordinating differentfunction drivers and invoking their callbacks. Note that the Windows USB driver stack isdesigned in a way such that the function drivers do not need to distinguish between the caseswhere they are loaded on top of one of the functions of a multi-function device and the casewhere they are managing a single-function (non-composite) device. To achieve this goal, incase of a non-composite device, the hub driver invokes the idle callback instead of USBCCGP,which is not present.

When is the D-IRP Mechanism Good Enough


5 of 8 26.10.2014 15:53

A function driver need not implement the idle IRP mechanism and can use the D IRPmechanism in the following cases:

A function driver, which does not depend on the resume signal notification, does notneed to know whether or not other functions are idle. In that case, it is ok even if thedevice 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 inthe above scenarios, a driver might still need to implement the Idle IRP mechanism, if thedriver is intended to run on versions of the Windows operating system earlier than WindowsVista. For information about the combination of OS versions and device types, which requirethe idle IRP mechanism, see USB Selective Suspend.

Certain function drivers are written to work for both non-composite devices and compositedevices, so those drivers end up implementing the idle IRP mechanism and using it regardlessof whether they are working on single-function and multi-function devices.

Importance of Selective SuspendThe selective suspend feature conserves power significantly. Therefore it is imperative for USBdevices and their function drivers to implement this feature. Any USB device that does notimplement the selective suspend feature might prevent other components of the system fromtransitioning to lower power. For instance, a device that is attached through a hub prevents thehub and also the host controller from going to a low-power state. This could in turn preventother system components, like the processor, from going to lower power. Thus, any device thatdoes not implement the feature appropriately can lead to a significant power drain on thesystem depending on the systems configuration. This is particularly important for USB 2.0devices because the 2.0 protocol is very chatty. For example, a pending interrupt transferrequires constant polling between the host controller and the device. Even if the device doesnot have an interrupt endpoint, a hub (between the device and the controller) with an interruptendpoint keeps the periodic scheduler in the controller active.

Implementing Selective Suspend Correctly in Function DriversImplementing power management correctly in a WDM function driver is a not a trivial task. Inaddition, implementing the idle IRP mechanism adds more complexity. I will not explain theseimplementation details but I think it is worth mentioning that WDF greatly reduces thecomplexity of implementing power management and also takes care of implementing the idleIRP mechanism. I strongly recommend that you use WDF if you are planning to add selectivesuspend support in the driver. For information about run-time power management in KMDF,see Supporting Idle Power-Down. For implementing selective suspend, choose the right optionin the run-time power management method WdfDeviceAssignS0IdleSettings. For UMDF driver,see Power Policy Ownership in UMDF. This blog entry outlines how to implement selectivesuspend when WinUSB is being used as the function driver.

In a rare scenario where there might really be a valid reason why a driver cannot be written inWDF, I recommend that you carefully read MSDN documentation, Selective Suspend in USBDrivers, and Increase System Power Efficiency with Idle Detection.

Implementing Selective Suspend Correctly in DevicesBecause selective suspend occurs even when there is no user activity, it is very important thattransitions to and from the selective suspend be completely transparent to the user. Anydeviation from such behavior could lead to inconsistent end-user experience.

For example, if a device is implemented in a way that it drops off the bus in suspend state, theuser can see unexpected delays and might hear system sounds due to PnP re-enumeration ofthe device. Hardware vendors must implement and extensively test selective suspend ondevices and hubs.

A device that is in selective suspend should be able to send resume signal when any useraction that it would normally respond to. For example, if a mouse goes into selective suspend,it should be able to send a resume signal not only when the user clicks a button on it but alsowhen the user moves the mouse. It should be noted that the requirement to wake up on anyevent does not apply to system suspend. For system suspend, it might make sense for thedevice to wake up only on some special events.

Devices should also have enough buffers to cache the data associated with any user actionthat initiated the resume. Upon resume, the device driver can start interacting with the device


6 of 8 26.10.2014 15:53

and the device can communicate that data back to the driver. This ensures that the user doesnot have to repeat an action such as pressing keys of a keyboard.

Selective Suspend in USB 3.0Now let us see how USB3.0 affects selective suspend. USB 3.0 defines link power management(LPM) with different link states from U1 to U3 in the increasing order of power savings and inthe increasing order of exit latencies. For U1 and U2 link states, after the software performs theinitial setup, those states are entered and exited automatically at the hardware level, withoutfurther software intervention. The USB driver stack handles this setup, without the interventionof function drivers.

U3 Link State and Selective SuspendWhen the link state of a USB 3.0 port goes to U3, the attached device goes to selectivesuspend state. Let us look at this mechanism in more detail and compare it to the USB 2.0selective suspend state, particularly from the point of view of drivers. Unlike USB 2.0, there areno SOFs that the hub stops sending. Instead, when the driver sends a particular link to U3 bysending a control transfer to the hub, the downstream device connected to that link goesdirectly into a suspend state. Like USB 2.0, a device is armed for remote wake-up by sending acontrol transfer directed to an interface in the device rather than the control endpoint(described in a subsequent section). When a device in suspend state is armed for remotewake-up detects a user directed event, the device sends a resume signal (U3 wake-up signal).The hub responds with the same signal back to the device. However unlike USB 2.0, the hubdoes not send a port status change interrupt event for the resume event. Instead, the devicesends a FUNCTION_WAKE device notification that informs the host about the resume event.

Function SuspendThe USB 3.0 specification also defines the function suspend feature, which is related to theselective suspend feature, from the point of the function drivers. In a USB 3.0 compositedevice, a function can be suspended independent of whether other functions in the device arein working or idle state. So when a function driver requests a low power transition, thecorresponding function must be sent to suspend state. When all the functions are in suspendstate, the device can be sent to suspend state by sending the upstream link to U3. Not onlycan the individual functions be suspended, they can also be armed for remote wake-upindependently. Therefore, a function can be suspended and woken up, even if other functionsare not in a suspended state. Therefore, the idle IRP mechanism that was described previouslyis not needed for USB 3.0 composite devices. When a function wakes up, it sends a wake upnotification 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 functionthat 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 firstinterface of the function. Non-composite devices are considered a special case of compositedevices. To arm a non-composite device for wake-up, the function driver must send a controltransfer to the first interface in the selected configuration. Note that arming the device forremote wake-up does not apply. One consequence of this design is that depending onwhether a device is a non-composite or composite, different drivers in the USB driver stack areresponsible for arming the device for remote wake-up. If a composite device uses acustomized driver instead of the USBCCGP, the custom driver must inform the USB driver stackthat the driver will handle the arming process.

Changes in Function Driver for 3.0A USB driver stack for supporting USB 3.0 devices should ideally be designed in a way thatlittle changes, if any, are needed in the function drivers to work with 3.0 devices. That is truefor power management as well; differences between USB 2.0 and 3.0 should be absorbed bythe USB driver stack. Existing function drivers written for USB 2.0 devices should work as is onUSB 3.0 devices, provided of course that the class protocol remains unchanged. As I pointedout earlier, USB 3.0 devices do not require any coordination between functions for powermanagement and hence the function drivers managing them do not need to implement theidle IRP mechanism. Of course, a lot of function drivers will be written generically to work onboth USB 2.0 and 3.0 devices and so they will end up implementing the idle IRP mechanismanyways. Particularly because the USB 3.0 devices are required to work as 2.1 devices whenthere is no SuperSpeed support in the host.

In this blog, I mainly focused on selective suspend. I briefly covered LPM states U1 and U2 butdid not go into details. LPM is a powerful mechanism for saving power but brings some new


7 of 8 26.10.2014 15:53

challenges. I will discuss that in my next blog post.

Comments

Hannes #25 May 2011 11:44 PM Excellent atricle, thanks for demystifying ;-)

But please re-post the diagram images without the drop shadow, it makes the image text difficult toread.

7flavor #16 Aug 2011 11:03 AM It's already high time MS developed generic XHCI drivers for Windows XP, Vista, 7 and 8.

WiseMan #13 Sep 2011 12:47 PM Under the section "importance of Selective Suspend" can you elaborate if the Hubs and controllersactually goto Dx if the dveices connected to them are all in Dx? I dont see the root hubs goto Dx?

Thx,

Tony #12 Jun 2013 8:34 AM This is an excellent article. The only thing I would ask is if there is a way to know the default timeout forSelective Suspend to occur. After how long and under what conditions does Selective Suspend activate?

[email protected] #24 Aug 2014 9:25 AM I enjoy music over the internet but this function, selective suspend, causes the streaming to stop. Mypower settings are at "never" for causing my computer to go to sleep and for turning off the screen, butall of a sudden, my music ends because it says selective suspend was implemented. I've had badexperiences with CD players breaking and one needs to constantly change the CD. I am recovering frominjuries to my brain and I would like to just listen non-stop to music until I desire to turn it off. Yourarticle is good and I am understanding somewhat the importance of selective suspend (and having mycomputer going into low power) but what do I do if I want the music to keep playing throughout theday? Thank you.


8 of 8 26.10.2014 15:53

demystifying usb selective suspend - microsoft windows usb core team blog - site home - msdn blogs

Documents