OnNow Power Management and WDM
This paper describes the requirements and the implications for Microsoft Windows Driver Model (WDM) device drivers in an OnNow power-managed system. Descriptions of the driver interfaces are presented.
The OnNow design initiative aims to make the PC more convenient to access and more energy efficient by integrating fundamental power management capabilities into the users' environment. The OnNow Architecture provides a fully integrated PC power management system that defines the requirements for the various components of the PC to work together to deliver consistent, intuitive, and effective power management to the user.
Power management requirements are defined for device and system hardware to implement power states and controls, for applications to participate in system power management, and for the operating system to direct power management throughout and to provide the necessary interfaces. The device driver is the key component where the hardware and software come together to result in energy savings and intuitive system behavior.
Microsoft has designed support for OnNow power management in WDM. It is the responsibility of driver writers to implement power management support in their WDM drivers.
On This Page
 | OnNow Power Management |
| Device Power Management in WDM |
| Device Power Policy |
| Device Power Control |
| Enabling Power Management with Bus Drivers |
| WDM Interface Reference |
| Conclusion and References |
OnNow Power Management
In an OnNow system, the operating system directs power management and integrates the activities of other components. The operating system's goal is to conserve energy while the PC is working and to put the PC to sleep when it is not doing work. The decisions that determine how to save energy and when to go to sleep are referred to as the power policy. In OnNow, power policy is based on end-user preferences, application needs, and system hardware capabilities.
The implementation of power policy is distributed throughout the system, with different policy owners for different aspects. The operating system itself is responsible for the policy of when the system as a whole should go to sleep and how deep a sleep to go into, as well as how to operate the processor to obtain energy conservation and to meet thermal and audible noise goals.
System power states derive from the Advanced Configuration and Power Interface (ACPI) specification. They are defined as follows:
| • | S0/Working - The CPU is fully up and running, devices are powering up and down as needed. |
| • | S1 - The CPU is stopped; RAM is refreshed; the system is running in a low power mode. |
| • | S2 - The CPU has no power; RAM is refreshed; the system is in a lower power mode than S1. |
| • | S3 - The CPU has no power; RAM is in slow refresh; the power supply is generally in a reduced power mode (for example, it can't supply much power and is running in a lower power efficiency mode). |
| • | S4 - The hardware is completely off, system memory has been saved to disk. |
| • | S5/Off - the hardware is completely off, the operating system has shut down; nothing has been saved. |
System power states are primarily defined in terms of motherboard/CPU/core logic characteristics and dont relate to individual devices themselves.
Every device in the system has its own power states. These are defined as follows:
| • | D0 - fully on |
| • | D1 - low power; context may be saved in hardware (depends on the device class) |
| • | D2 - low power; context may be lost by hardware (depends on the device class) |
| • | D3 - power may be lost; all context lost by hardware |
There is a separate policy-owner for each device class, or subsystem, in the PC. The policy-owner for a particular device class is that component which has the best knowledge of the device's usage from the perspective of the end-user and the applications. This is generally a high-level component and, in most cases, is a WDM Class Driver. Each policy owner is tasked with making appropriate power management decisions for its class and for working consistently with the operating system's policy for putting the PC to sleep.
Carrying out power policy -- that is, actually controlling devices such that power consumption or capabilities change -- is not the concern of the policy owner. Responsibility for this power control falls to the device drivers for the affected device and is shared among the drivers in the stack.
Device Power Management in WDM
WDM provides facilities for drivers to implement power policy and control. Device Drive Interfaces (DDIs) are defined for synchronizing power state changes with other power management activities in the system and for detecting device idleness. I/O request packets (IRPs) are defined for setting power state, enabling wake up, and determining device capabilities.
Power management policy decisions generally result in the kernel sending an IRP to a specific device object (often the policy owner itself) to affect some power management control. The IRP is passed along to the device object's parent as needed to cause the actual control functionality. This can involve many sets of child-parent pairs between the policy owner and the actual power control (for example, a modem connected to a USB port which is connected to the PCI bus, and so on). Drivers implementing power policy or control use kernel services via the WDM DDIs.
Device Power Management
Devices that are not being used should be put into low-power states to conserve power. Under OnNow, the responsibility for power-managing devices is divided into three parts:
| • | Policy owners decide when a device should switch power states. |
| • | Device drivers save and restore any hardware context lost by switching to a low-power state. |
| • | Bus drivers (including the ACPI System Bus driver) use standard interfaces to signal hardware to switch to a low-power state; they may possibly remove power from the device. |
This section describes the roles of policy owners, device drivers, and bus drivers in the process of device power management.
Power Management and Device Classes
Power management should be handled as follows for each device class:
Network Adapters - Drivers for network adapters implement power management by conforming to NDIS 5 and power management interfaces. These drivers do not use the interfaces described in this white paper.
Video Capture, DVD, and other Streaming WDM drivers - These drivers handle the D0 and D3 power states using the power management interfaces in the WDM Streaming class driver. See the current version of the Windows DDK documentation on the WDM Stream Class driver for details. For the D1 and D2 power states, these drivers must call the power management interfaces described in this document.
USB, IEEE 1394, Human Interface Devices (HID), still-image capture, audio, and other WDM drivers - These drivers must be written as WDM drivers, and thus must use the WDM power management interfaces described in this document, the WDM class-specific power management interfaces, or both.
Windows 98/ME-specific drivers (COM devices, display miniports, other classes not described above) - These drivers must be written as Windows Plug and Play drivers, complying with the power management interfaces described in this document or as the class-specific power management interfaces or both. For implementation details, see the current version of the Windows DDK.
Windows 2000/Windows XP-specific drivers (COM and display devices, SCSI miniports, other classes not described above) - These drivers must be written as Windows 2000/Windows XP Plug and Play drivers, complying with the class-defined power management interfaces and/or the power management interfaces described in this paper. For implementation details, see the current version of the Windows DDK.
Power Management Checklist
Vendors should use the following checklist while implementing power management in drivers:
All Drivers:
| • | Add support for setting power capabilities |
| • | Add support for a power policy if not already provided by the class driver or elsewhere |
| • | Add support to handle device power state transitions |
| • | Add support to handle system power state transitions |
| • | If the hardware supports signaling wake up, add support to enable, disable, and detect wake up |
| • | Add support for handling application interfaces |
Bus Drivers (in addition to the above):
| • | Add support to set initial power capabilities of child devices |
| • | Add support for controlling the power state of child devices |
| • | Add support to enable and disable wake up on child devices |
| • | Add support to handle wake up events and determine the waking device |
| • | Add power management policy for the bus (host controller device states and related bus states) |
| • | Add support to handle power sequence tracking |
Device Power Policy
Implementing power policy for a device class is often simple (just a few lines of code). Communications ports, for example, can have an extremely simple power policy. When an application opens the COM port, the policy owner simply has to turn the device on; when an application closes the port, it just turns it off.
In general, the policy owner makes use of its application interface for information about device usage, a Device Class Power Management Specification for information about device power states and capabilities, and the WDM DDIs described in this paper to determine idleness and to invoke power control. Developers of Policy Owners should refer to the current version of the Windows DDK documentation for the class of device for specifics about the application interfaces, and refer to the Device Class Power Management Specification for the class of device for specifics about expected device states and capabilities.
All Device Class Power Management Specifications are available from the OnNow home page at http://www.microsoft.com/whdc/system/pnppwr/powermgmt/devicepm.mspx.
Device Power Control
Once power policy decisions are made, the policy owner uses the WDM interfaces and the lower level drivers in the stack to implement the power control. In the OnNow model, power control is bus specific and is carried out by a WDM bus driver. However, this requires standards at the bus level, and OnNow includes efforts to define the necessary functions in the PCI, USB, and IEEE 1394 bus specifications.
For buses that do not support power control functionality, the Advanced Configuration and Power Interface (ACPI) specification provides a way for system makers to add these capabilities to integrated devices and slots. If no support exists in these specifications, then non-standard power control can be implemented in a WDM minidriver.
Bus-centric Control Model
Bus drivers generally know how to control power state changes or enable wake up on devices residing on their bus, based on the specifications for the bus. Further, these drivers are policy owners for the bus itself.
For example, bus drivers are responsible for policy related to the host controller for the bus and any other resources associated with the bus (such as power planes and clocks). This policy includes tracking the power states of all devices on the bus and ensuring that the host controller and resources are in a compatible state. The policy also includes responsibility for ensuring that a device set for wake up has all of the bus resources it needs to cause a wake up (that is, the bus is in the necessary state).
Device Power Management and System Power States
System power states and device power states are managed separately by different policy owners in the system. In general, device drivers do not need to concern themselves with system power states. However, the two types of states do interact, and some understanding of this is necessary for device driver developers.
In the low-power system states S1-S3, the system cannot support having all devices on. System designers make tradeoffs in designing their motherboards, based on how much power they want to consume in each state and, therefore, which devices will be powered in each state. For a particular device on a particular motherboard, it may not be physically possible to keep the device in the D0 or D1 state when the machine is in S2-S3. This results in a system-specific matrix of device states that can be supported in each system state.
This device state capabilities matrix implies a maximum device power state that the device can be in for any given system state. Device drivers need to use this information in deciding how to appropriately manage their device when the operating system requests to put the system to sleep. In most cases, the device state for any system sleep state is D3, but this may be affected if wakeup is enabled.
Control Flow
The following sections describe the events that take place to handle power management.
Determining Device Capabilities for Power Management
Before power-managing a device, the policy owner and device driver need to determine which power states are supported on the platform and whether the device is capable of waking the system. The hardware and the software (device driver) each have their own capabilities. To determine which power states are supported, the device driver must determine the capabilities of the hardware and then merge those capabilities with its own.
Device drivers determine the supported power states using the following procedure:
1. | When the device driver loads, the operating system will send the device's Functional Device Object (FDO; which is owned by the device driver) an IRP_MJ_PNP/IRP_MN_QUERY_CAPABILITIES IRP to determine the capabilities of the device. | ||||||
2. | The device driver must first forward this IRP to its Physical Device Object (PDO; which is owned by the bus driver) to determine what capabilities are supported by the hardware. | ||||||
3. | When the bus driver receives the QUERY_CAPABILITIES IRP, it interrogates the hardware using standards for that bus and fills out the DEVICE_CAPABILITIES structure including the DeviceWake, SystemWake, and DeviceState fields. These fields are defined as follows:
| ||||||
4. | When this IRP completes, the device driver adjusts these capabilities based on the capabilities of the driver itself, and any private information it has about the device hardware. Note that the device driver can only remove capability; it cannot add capabilities. | ||||||
5. | The device driver completes the IRP to the operating system. |
Summary of key points:
| • | Bus drivers fill in the DEVICE_CAPABILITIES structure based on the capabilities reported using hardware standards. |
| • | Device drivers adjust these capabilities based on their own capabilities. |
| • | Policy owners send the QUERY_CAPABILITIES IRP before requesting any power state changes to be aware of what power states the device supports. |
Switching to a Low Power State
When the policy owner decides to put a device into a low-power state, the following actions occur:
1. | The policy owner calls PoRequestPowerIrp to create an IRP_MJ_POWER/IRP_MN_SET_POWER IRP for the required device state and send it to the FDO at the top of the device's IRP stack. |
2. | When the device driver receives the SET_POWER IRP, it saves any device context it will need to restore the device to the D0 state. |
3. | The device driver calls PoSetPowerState to tell the operating system that the device is leaving the D0 power state. |
4. | If necessary, the device driver may exercise any hardware controls it has to put the device into the targeted power state. |
5. | As with all other POWER IRPs, the device driver must forward the IRP to its PDO by calling PoStartNextPowerIrp (to indicate to the system that it is done with the current IRP and that the next one may be sent), then PoCallDriver (to send the current IRP to the PDO). |
6. | When the bus driver receives the SET_POWER IRP for its child device, it exercises any hardware standard controls to put the device into the targeted power state. It then completes the IRP. |
Summary of key points:
| • | The policy owner makes the decision of when to change power states and what state to go to and executes that decision by calling PoRequestPowerIrp to request a SET_POWER IRP |
| • | The device driver saves device context and forwards the IRP to its PDO using PoStartNextPowerIrp and PoCallDriver. |
| • | The bus driver turns off the device using bus-standard controls. |
Turning on a Device
When the policy owner decides to turn a device on (due to a received I/O request that requires the device to be on), the following actions occur:
1. | The policy owner calls PoRequestPowerIrp to create an IRP_MJ_POWER/IRP_MN_SET_POWER IRP for the D0 state and send it to the FDO at the top of the device's IRP stack. |
2. | When the device driver receives the SET_POWER IRP, it merely fills in a completion routine, then forwards the IRP to its PDO using PoStartNextPowerIrp and PoCallDriver. |
3. | When the bus driver receives the SET_POWER IRP at the PDO, it exercises its standard hardware mechanisms to restore power to the device and then completes the IRP. |
4. | In its completion routine, the device driver restores all device context to return the device to D0. |
5. | The device driver calls PoSetPowerState to tell the operating system that the driver is now fully in the D0 power state. |
Summary of key points:
| • | The policy owner decides when to turn on the device and initiates that change by calling PoRequestPowerIrp to request a SET_POWER IRP. |
| • | The bus driver turns on the device using industry-standard mechanisms. |
| • | The device driver restores device context in the completion routine for the SET_POWER IRP. |
System Power Management
Computers can be put into low-power sleep states in response to a user command or when the computer has been idle for some period of time. When a computer goes into a system sleeping state, most of the devices in the computer must either be turned off or put in a low-power state. Devices enter low-power states using the process described in the topic "Switching to a Low Power State" earlier in this paper.
This section builds on the information provided in the previous section and describes the processes used for system power management.
System Sleep States and Device Drivers
From the device driver's perspective, the operating system puts the computer into a sleeping state using the following steps:
| • | Query phase, during which the operating system asks each driver if it can go to sleep now by sending it a QUERY_POWER IRP with a system power state. |
| • | Sleep phase, during which the operating system tells each driver to go into a low-power state by sending it a SET_POWER IRP with a system power state. |
| • | Signal hardware phase, during which the ACPI driver signals the motherboard chip set to go to sleep. |
Query Phase
The operating system determines whether the machine can be put into a system sleeping state and which system sleeping state to use by sending system power state queries to each device driver. The operating system begins by sending queries for the lowest power system sleeping state the platform supports. If a driver fails a query, the operating system sends the queries again, this time with the next higher power system state and repeats the process until all drivers succeed or the operating system runs out of power states.
1. | The operating system sends each driver (in sequence from leaf nodes towards the root) a IRP_MJ_POWER/IRP_MN_QUERY_POWER IRP with a requested system state. | ||||
2. | Upon receiving the QUERY_POWER IRP, the device driver determines whether it can go into that system sleep state and returns success or failure accordingly. Device drivers should fail this query only for the following reasons:
| ||||
3. | If any device driver returns success, it must stop any activity on the device that would prevent the system from going to sleep (that is, any activity that would cause the driver to report failure to this message). | ||||
4. | If any device driver fails the query, the operating system attempts higher system power states until it finds a state that will work or it runs out of states. If the operating system runs out of power states, it sends a SET_POWER IRP with a system state of SystemWorking to indicate that the system will not be going to sleep and drivers can resume normal activity. |
Sleep Phase
During the Sleep phase, the operating system tells each device driver to go into the selected system sleeping state.
1. | The operating system sends each driver (in the same sequence used for queries) an IRP_MJ_POWER/IRP_MN_SET_POWER with the targeted system power state. | ||||
2. | Upon receiving the SET_POWER IRP, the driver determines which device power state to go to as follows:
| ||||
3. | If the device is to be a wake-up device, it sends a WAIT_WAKE IRP using PoRequestPowerIrp. | ||||
4. | The device driver switches to the chosen device state by calling PoRequestPowerIrp. This will cause the process to take place as described in the section "Switching to a Low Power State" earlier in this paper. | ||||
5. | The device driver completes the SET_POWER IRP it received in step 2. |
Summary of key points
| • | Device drivers must listen for and handle system QUERY_POWER IRPs. |
| • | Device drivers must listen for system SET_POWER IRPs and generate the appropriate device SET_POWER IRP. |
Wake Up Devices
Some devices can wake the system in response to some event. By default, this wake up feature is disabled in each device until an application requests it.
Enabling Wake Up
Applications request that devices wake the machine by calling the RequestDeviceWakeup Win32 API, or directly via Windows Management Instrumentation (WMI) extensions to WDM. For information, see the current version of the Windows DDK.
Drivers support enabling wake up by doing the following:
1. | After loading, the device driver registers with WMI extensions to receive WMI requests. |
2. | The device driver receives WMI extensions set information on GUID_DEVICE_WAKE_ENABLE. The buffer for this information contains a boolean that describes whether or not wake up should be enabled. |
3. | If the WMI extension request is to enable wake up and wake up is not currently enabled, the driver must send an IRP_MJ_POWER/IRP_MN_WAIT_WAKE to itself using PoRequestPowerIrp. If the request is to disable wake up, the driver must cancel the IRP_MN_WAIT_WAKE IRP it previously sent. Note: The device driver is responsible for tracking the number of applications that have requested wake up and only cancel the WAIT_WAKE IRP when the last application has disabled wake up. |
4. | When the device driver receives the WAIT_WAKE IRP, it activates the wake up features in the hardware and fills in a completion routine (described in the following section). |
5. | As always, the device driver forwards the WAIT_WAKE IRP to its PDO using PoStartNextPowerIrp and PoCallDriver. |
6. | When it receives the WAIT_WAKE IRP at the PDO, the bus driver exercises its bus standard hardware controls to enable wake up. |
7. | If the bus itself is not enabled for wake up, the bus driver sends itself a WAIT_WAKE IRP by calling PoRequestPowerIrp. (Thus all parent buses of a given device are enabled for wake up.) |
Summary of key points:
| • | Device drivers enable wake up only when requested using WMI extensions for WDM. |
| • | Device drivers enable wake up by sending a WAIT_WAKE IRP to themselves (the FDO at the top of the IRP stack) using PoCallDriver. |
Signaling System Wake Up
When the system wakes, the device drivers work together to determine the source of the wake up as follows:
1. | When a bus driver finds that its bus is signaling wake up (by seeing its WAIT_WAKE IRP complete), it uses the mechanisms defined in the standard for that bus to determine which children are signaling wake up. |
2. | The bus driver completes the WAIT_WAKE IRP for each device signaling wake up. |
3. | In the completion routine, each child device handles the wake up event. This may require turning on the device by calling PoRequestPowerIrp. If the child device driver is a bus driver, it should repeat the process at step 1. |
Summary of key points:
| • | At system wake up, bus drivers must complete the WAIT_WAKE IRPs for any children that are signaling wake up. |
| • | Device and bus drivers must handle the wake-up event in their completion routines. |
Enabling Power Management with Bus Drivers
The preceding sections describe the general steps to perform device and system power management. This section describes additional steps that must be taken to enable power management with a bus driver.
Bus Power Policy
The power policy for most buses is the same: the bus will be in the same power state as the highest power state of its children. For example, if all the devices on a bus are in either D2 or D3, the bus can be put into D2. Bus drivers must track the power states of all child devices and adjust their own power state accordingly:
| • | After putting a child device into a low-power state, the bus driver puts itself into a power state that matches the highest of the power states set for the devices on that bus. |
| • | Before turning on a child device (putting it into D0), the bus driver turns on the bus (puts it into D0) if it is not already on. |
Note that the bus power policy must also account for wake-up events generated by the bus itself. The PCMCIA bus, for example, should not be turned off when its devices have all reached the D3 state if the host controller can only detect device insertions and removals (wake-up events) when it is on. The bus should instead be put in the lowest state that can still detect these events and signal wakeup, as indicated by the bus controller's capabilities.
Handling Power Sequencing
On many buses, a device cannot be put into a low power state until all other devices on the bus have also been put in a low power state. As a result, when device drivers go into a low-power state, their hardware does not always reach that power state. Device drivers can use power sequence numbers to determine whether their device really reached the low-power state and thus optimize the power on path (if the device did not reach the low-power state, there's no need to spend time restoring device context). The power sequence number tracks how many times a device has reached a given low-power state.
To allow device drivers to do this optimization, bus drivers must maintain power sequence numbers for each device on the bus. Bus drivers should increment this number every time the device reaches the given power state.
A device driver gets its power sequence numbers by sending an IRP_MJ_POWER/IRP_MN_POWER_SEQUENCE IRP to its PDO using IoAllocateIrp.
Handling System Wake Events
When a bus driver's WAIT_WAKE IRP is completed, it puts its bus(es) into the lowest power state sufficient to detect device insertions and removals. Bus drivers do not automatically perform re-enumeration at this time. If re-enumeration is required, the operating system will request it using Plug and Play services.
WDM Interface Reference
The following table summarizes the usage of the interfaces mentioned previously. A detailed reference follows.
| Interface | Called by | When/Why |
PoSetPowerState | Device Driver | Whenever the device is about to leave or has just returned to the D0 state. To notify the system and any interested components. |
PoCallDriver | Device Driver | Whenever processing for a Power IRP is completed. To forward the IRP to the next driver in the IRP stack. Note: A driver must call PoStartNextPowerIrp before calling PoCallDriver. |
PoRequestPowerIrp | Policy Owner | When a policy decision has been made to change the devices power state. To start a device power state change (Set_Power IRP) operation. |
PoRequestPowerIrp | Device Driver | 1) When a system power state change request is received. To start a device power state change (Set_Power IRP) operation. 2) When device wakeup is requested via the WMI interface. To enable wakeup (Wait_Wake IRP) on the device. |
PoStartNextPowerIrp | Device Driver | Whenever processing of one Power IRP is completed, and the driver is ready to process the next Power IRP. To serialize all power IRPs sent to the driver. |
PoSetDeviceBusy | Device Driver or Policy Owner | Whenever a device I/O operation is started. Called only if system idle timing services are being used. |
PoRegisterDeviceNotify1 | Any driver or system component | To request notifications of power state changes for another device in the same power plane. |
PoCancelDeviceNotify1 | Any driver or system component | To cancel a previous PoRegisterDeviceNotify. |
1Note: PoRegisterDeviceNotify and PoCancelDeviceNotify are not supported on Windows 98.
WDM DDIs
The DDIs provided by WDM for implementing power policy and control are described below. Note that in WDM, the Power Manager -- designated by 'PO' -- is the kernel component that provides these services.
PoRequestPowerIRP
Used to start any power action on a device. The kernel will synchronize the request with other events going on in the system (like global power state changes, or sequencing powering on devices to prevent in-rush current from overloading the power supply, and so on). When the kernel is ready, it will send the requested IRP to the driver at the top of the device's driver stack. PoCallDriver, below, will subsequently be used to forward the IRP to other drivers in the IRP stack.
PoCallDriver
Used to send power management IRPs to the next driver in the IRP stack. When the kernel is ready, and when the driver has indicated it is ready to receive another power IRP (via the PoStartNextPowerIRP function), it will send the IRP to the driver. Note: A driver MUST call PoStartNextPowerIrp before calling PoCallDriver.
PoStartNextPowerIrp
Used to inform the system that a particular driver is done with a particular power IRP. It is called by each device driver in the IRP stack. When this function is called, the calling driver is done with the specified IRP and the next power IRP will be allowed in.
PoSetPowerState
Used by a device driver during power state transitions to update its device object with new power management information. It must be called before leaving the D0 state on power-down transitions, and after entering the D0 state on power-up transitions. This function is used by the system to perform notifications (see the following DDI).
PoRegisterDeviceNotify
Called by a device driver to receive notifications when another device in its power plane changes power state. Note: This routine is not supported on Windows 98.
PoCancelDeviceNotify
Called by a device driver to cancel a previous PoRegisterDeviceNotify. Note: This routine is not supported on Windows 98.
PoRegisterDeviceForIdleDetection
Called by a device driver to register to have the PO system automatically send the device a power-change IRP if the device is idle for a defined time-out period.
PoSetDeviceBusy
Used to determine whether a device is idle. A device driver must call PoSetDeviceBusy on every I/O request to tell the PO system that it is busy. If the PO system has not heard from a device within the registered time-out period, it signals the device to change power state.
WDM IRPs
All the power management IRPs are minor functions of IRP_MJ_ POWER IRP. The power management functions are described here.
IRP_MN_QUERY_ POWER
Sent when global power state changes are made to ask drivers if it is OK to go to this power state. The system power state is passed as a parameter. When a driver receives this IRP, it must determine whether it cannot go to this power state and fail the IRP. Otherwise, it must prepare itself for a SET_POWER IRP and return success.
IRP_MN_SET_POWER
Sent when the device is to change its power state. The system power state (for system-wide power state transitions) or the device power state (D0, D1, D2, D3) is passed as a parameter. If going to a low power state (states other than D0), the driver must save any device context it will need to restore the device to the same state later. Then it must forward the IRP to its parent device.
If going to the D0 state (On), the driver must first forward the IRP to its parent to get power turned on to the device, then restore the device's context in the completion routine for this IRP.
IRP_MN_WAIT_WAKE
Tells the driver that its device is needed to wake the computer. It should do whatever it needs to prepare the device for wake up. Then it must forward the IRP to its parent to enable wake up.
IRP_MN_QUERY_CAPABILITIES
This IRP is a minor function of IRP_MJ_PNP. It is used by device drivers to determine the power management capabilities of their device. The bus driver uses bus power management standards to determine the capabilities of the device and returns it to the calling driver. Information is included about the system states and corresponding device states from which the device can wake the machine.
IRP_MN_POWER_SEQUENCE
This IRP provides a power sequence number for each power state of a device. The number tracks the actual power state transitions the device makes (for example, it is incremented each time the device enters the given power state). Because of bus-specific or system-specific considerations, a device may not actually enter a requested lower-power state. Power sequence numbers can be used by a device driver to detect this case and enable it to optimize the power-up routine by not performing time-intensive operations that are not required because state was not actually lost.
Conclusion and References
The Windows Driver Model has been designed from the start to support the needs of OnNow power management. WDM provides a robust set of services and simple interfaces that enable all device drivers to integrate smoothly into a power-managed PC. As WDM drivers and OnNow-compliant hardware becomes available, customers will be able to realize the OnNow benefits as a standard feature of PCs and available on a wide range of add-on and peripheral products.
OnNow white papers, presentations and Device Class Power Management Reference Specifications:
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/devicepm.mspx
ACPI and PCI Power Management Specifications and Presentations:
http://www.acpi.info/ 
The latest version of the Windows DDK --
http://www.microsoft.com/whdc/devtools/ddk/default.mspx