Run-Time Power Management
Before we talk about selective suspend, let’s understand a more generic concept: run-time power management.
One way of conserving power in a system is to send the whole system to a low-power state such as sleep or hibernate. Because this mechanism requires turning off the system, it is only possible when the whole system is not in use. Even when the whole system is in use and is in working state, it is quite likely that certain components of the system are not active. Those components are said to be in an idle state. Run-time power management refers to sending idle components to a lower power state, until they need to be used again. The components can be hardware such as processor, memory, and so on; however in this discussion, we are only interested in run time power management of devices.
Devices and device drivers should aggressively pursue run-time power management of devices because the mechanism can lead to significant power savings. Because a driver stack includes more than one driver, coordination between drivers is required while sending the device to a lower 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 in the device stack, typically the function driver, is the power policy owner. This power policy owner is responsible for detecting that the device is idle and initiating the process of transitioning the device into a lower power state. The power policy owner is also responsible for bringing the device back to working state, (also referred to as waking up the device) when the user needs to use that device.
Host-Initiated and Device-Initiated Wake-up
How would the power policy owner driver know about the user’s intent to use a device, so that the driver can wake up the device? That depends on the kind of device. Let us say, a storage device 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 policy owner gets an I/O request from the application, and knows that it needs to wake up the device. However, if the device is a mouse, the device must send some sort of signal to initiate the wake-up process. The device-initiated power transition is known as remote wake-up feature in the USB world. Because the mouse needs to generate such a resume signal, it cannot completely turn itself off. Typically, the ability of the device to generate the resume signal is programmable. Therefore, before putting the device to sleep, the driver must instruct the device to turn on the remote wake-up feature when the device is suspended. This process is called arming the device for remote wake-up.
Read more: Microsoft Windows USB Core Team Blog
Posts
0 comments:
Post a Comment