OnNow Device Power Management
On This Page
 | Purpose and Related Topics |
| Introduction |
| Bus Requirements for Power Management |
| Device Power States |
| Device Class Requirements |
| Conclusion |
Purpose and Related Topics
Microsoft Windows operating systems have a common architecture to deliver the necessary capabilities for power management of individual devices. However, specific requirements are implied for hardware.
This paper describes these bus- and device-class-specific hardware requirements. This information is intended to serve as a guide for development of bus and device specifications or for modifications to existing specifications that will enable individual devices to become power manageable in a standard fashion.
See related topics on the OnNow home page.
Introduction
Dynamic management of power consumption for individual devices is the key advancement required for PC power management. A fully integrated, power-aware PC in which each device is power-managed individually will deliver the increased battery life, decreased power consumption, and increased system availability that users expect.
Customers are demanding that their computers be automatically available at all times, even when turned off. For example, network administrators want to manage computers late at night, and home users want to use their computer to receive faxes. Users with computers hidden away under desks want to be able to turn them on using a button on the keyboard or monitor. Customers also want to decrease the amount of power that PCs use, whether power comes from a wall outlet or a battery. Ideally, when the computer is turned "off," it goes into a lower power state and can then be wakened by any device in the system, such as the network card, modem, keyboard, or monitor.
To meet these ever-increasing user demands, the operating system must be able to manage the power use of any device in the system, including add-in boards such as network adapters and sound cards, in addition to peripherals such as printers, keyboards, and modems. Currently, however, only a few devices in a computer can be power managed: devices built onto the main board, monitors, and disk drives that support spin down. In addition, the current support for device-level power management is, for the most part, based on hardware-level heuristics and timers that are inefficient and often misleading.
The result of the power management scenario in Windows 95/Windows NT 4.0 systems is suboptimal device power management for only a subset of devices. To effectively manage power and meet the increasing end-user demands, the PC software, hardware, and operating system must work together in a framework that enables every device to be power managed in a consistent manner.
At the center of this framework is the device driver, which is the component that has the most intimate knowledge of the device's usage pattern and power consumption characteristics. This makes the device driver the correct component to determine when the device should change power states and to determine which states are appropriate for current usage. However, the driver needs support from the operating system, applications, and hardware in determining and setting power state changes in the following ways:
| • | The operating system must provide an application interface that enables it to determine when applications are using or will need to use various devices. |
| • | The operating system must provide this information and appropriate control interfaces to each device driver so that the driver can manage its device's power state effectively. |
| • | Device hardware must support defined power management states and class-specific interpretations of these states so that the driver (and the end user) can expect consistent behavior among devices of a particular type. |
| • | Bus-specific mechanisms must be available for determining device power capabilities and status and for manipulating device power states. Such mechanisms will free the driver from having to understand a wide variety of power-state control mechanisms and will allow the operating system to provide bus-independent power control services to the driver. |
Beginning with Windows 98 and Windows 2000, all Microsoft operating systems implement an architecture that meets these requirements.
This paper summarizes the following aspects of hardware requirements for device power management:
| • | A set of definitions and controls at the bus level so power management control can be abstracted and handled generically by the operating system. |
| • | A set of characteristics and behaviors at the device-class level so appropriate power management policies can be defined and consistently applied for each different class of device. |
Bus Requirements for Power Management
Four basic power management operations ensure that devices on the bus can be power managed. These operations provide information and commands that help create a robust power management solution:
| • | Capabilities reporting operation. This operation informs the operating system of the power management capabilities and features of a given device. |
| • | Set power state operation. This operation puts the device in a specific power state and enables power management features. |
| • | Power status operation. This operation returns information about the current power state and the status of any batteries in the device. Devices must have a notification mechanism that does not require polling (which wastes bus bandwidth). This allows the device to send alerts to the operating system when necessary. |
| • | PC wake-up operation. This is a mechanism for having a device wake the PC from a lower power state. |
Generally speaking, bus power operations are defined so that they work for each function of a multifunction device if the bus supports multifunction devices. The following sections summarize the requirements for each of the four operations.
Get Capabilities Operation
The Get Capabilities operation is performed as part of the operating system's device enumeration process and describes the following:
| • | Whether this device supports power management or reports the level of power management that this device supports. |
| • | The power states into which this device can be placed. For example, for the Wakeup state: Does the device support wakeup? If so, from which device states can the system signal wakeup? |
| • | Battery capabilities. Is the battery available? (This means the device is capable of having a battery; it does not mean the device currently has the battery inserted.) If so, does the battery supply system power? Does the battery support capacity status reporting? (See the description in the "Get Power Status Operation" section later in this paper.) |
Set Power State Operation
The Set Power State operation places a device in one of the four device power states, as described in "Device Power States" section later in this paper. The Set Power State operation also enables certain power management features. The operating system will use this operation to fulfill a device driver's request to have its device set into a particular power state. This service is available to device drivers as a supplement or alternative to any device-specific power control it might use and allows device drivers to be bus-independent.
Although the bus might not remove power from the device when the device is in a low-power state, the device should minimize the amount of power it is drawing from the bus power supply. When all of the devices on a bus are in the same state, the operating system will command the bus controller to put the bus into the appropriate low power state. In any power state, the device must still respond to Set Power State commands.
The Set Power State function performs the following:
| • | Enables and disables power management on this device (the default might be "off" for legacy compatibility reasons) |
| • | Enables and disables wakeup |
| • | Sets the power state |
Get Power Status Operation
The Get Power Status operation is used to get the current power status of the device. The bus must have an interrupt-like method for informing the operating system of status changes.
The Get Power Status operation performs the following:
| • | Determines the current power state: Is wakeup enabled? Is power management enabled? |
| • | Determines the battery status: Is a battery installed? Is the battery charging? What is the device's current power source (bus, battery, or AC)? Is the battery level critical (and so the device must be shut off)? What are the battery capacities? Total capacity (not time)? Capacity remaining? |
Optional items to determine (of benefit to the user interface): manufacturer, product ID, and serial number.
Wakeup Operation
A device uses the Wakeup operation to wake the computer from a low-power state or to request that the PC wake it (the device) from a low-power state. The Wakeup operation must be able to wake the PC without requiring input from the CPU or operating system. To support the Wakeup operation, bridges must forward wakeup signals to upstream buses, so eventually the core chipset will receive the signal and wake the PC. Once the PC is running, there must be a way for the software to determine which device awakened the PC. This can be done by using status bits or by asserting a functional interrupt for the device that requested the wakeup.
Device Power States
Until now, the only description of device power states has been in the APM specification. Unfortunately, these definitions are not precise and have led to a wide variety of interpretations, which has caused problems. To standardize the nomenclature, the definitions presented in this section are used for the power states of devices on any bus. These states are defined in terms of the following four criteria:
| • | Power consumption: how much power the device uses. |
| • | Device context: how much of the operational context of the device is retained. |
| • | Device driver: what the driver must do to restore the device to be fully on. |
| • | Restore time: how long it takes to restore the device to be fully on. |
D3 State for Device Power
| • | Power consumption: Power may have been fully removed from the device. |
| • | Device state: Device context saved by hardware when in the state. The device must be reinitialized, or restored, to fully-on operation upon entering the D0 power state. |
| • | Device drivers: Any device driver associated with the device must reinitialize or restore the device to fully-on operation when exiting the D3 state for the D0 power state. |
| • | Restore time: Total restore time for the device is highest because of the possible need to completely reinitialize the device. |
D2 State for Device Power
| • | Power consumption: Power consumption is equal to or greater than the D3 state. Power usage should be reduced to the minimum level where device state restoration is still possible. |
| • | Device context: Device context might be preserved or might be lost, depending on class-specific definitions. |
| • | Device drivers: Device driver function in this state is according to class-specific definitions. |
| • | Restore time: The time required to restore the device from the D2 state to the D0 state is equal to or slower than resumption from the D1 state. It is acceptable for device restoration time from D2 to be slower than D1 in the interests of additional power conservation. Actual response times are according to class-specific definitions. |
D1 State for Device Power
| • | Power consumption: Power consumption is equal to or greater than the D2 state, but less than the D0 state. |
| • | Device context: Device context might be preserved or might be lost, depending on class-specific definitions. |
| • | Device drivers: Device driver function in this state is according to class-specific definitions. |
| • | Restore time: The time required to restore the device from the D1 state to the D0 state is quicker than resumption from D2 whenever possible. Resumption should incur the least possible delay to avoid user perception of delay. Minimizing delay in restoring the device is a higher priority than power consumption in this state. Actual response times are according to class-specific definitions. |
D0 State for Device Power
| • | Power consumption: This is assumed to be the highest level of power consumption. |
| • | Device context: The device is completely active and responsive. |
| • | Device drivers: The driver is functioning normally. |
| • | Restore time: Not applicable. |
Device Class Requirements
When a bus supports power management as described in the previous sections, devices on that bus must support some consistent set of power-related characteristics. Specifically, for each of the four bus power operations, the device will implement a class-specific set of characteristics and behaviors in response. For example, when the bus-specific mechanism is invoked to set the device power state to a certain level, there will be variations from device type to device type in what a specific device actually does (and what specific sorts of behaviors the operating system can assume while the device is in that state).
For a fully integrated device power management system, these class-specific power characteristics must be understood by the driver. Each major device class must have a Power Management Reference Specification that all manufacturers can use to integrate smoothly with the system. These specifications are used by hardware engineers, device driver writers, and operating system designers to ensure smooth integration.
The Power Management Reference specifications cover the following areas:
| • | Device-class power characteristics. Each class of device has a detailed definition for each bus power state. This includes target power consumption levels, command response latencies, and state-change latencies. Implementation details for achieving these levels (such as whether an entire functional block is powered-off or the clock is stopped) might be important to a particular device class and, if so, are included. |
| • | Minimum device-class power capabilities. Each class of device defines a baseline set of power capabilities appropriate to the class. An example might be to require support either for all four power states or for some lesser number. Requirements are also specified for accuracy and frequency of power status updates. Finally, there may be class-specific requirements for wakeup capabilities. For example, all modems should be able to wake the PC from D2, and so on. |
| • | Device-class functional characteristics. Each class of device has a definition of the available subset of device capabilities and features in each power state. For example, the network adapter can receive but cannot transmit, the sound card is fully functional except the power amps are off, and so on. |
| • | Device-class wakeup characteristics. Each class of device defines its Wakeup events. This includes specifying which events can wake the system, and the power states from which the wakeup can be signaled, with implementation details where appropriate. |
Conclusion
The comprehensive architecture for Device Power Management in Windows operating systems supports moving PC power management to a higher level of usability. All components of the PC are affected, from the applications to the operating system software to the board design and silicon. For complete information about driver implementation, see the current Windows DDK.
For complete information about hardware, firmware, and driver requirements for power management, see the current requirements for the Windows Logo Program for hardware.