A. Appendix A: Device Class Specifications¶
This section defines the behavior of devices as that behavior relates to power management and, specifically, to the four device power states defined by ACPI. The goal is enabling device vendors to design power-manageable products that meet the basic needs of OSPM and can be utilized by any ACPI-compatible operating system.
A.1. Overview¶
The power management of individual devices is the responsibility of a policy owner in the operating system. This software element will implement a power management policy that is appropriate for the type (or class) of device being managed. Device power management policy typically operates in conjunction with a global system power policy implemented in the operating system.
In general, the device-class power management policy strives to reduce power consumption while the system is working by transitioning among various available power states according to device usage. The challenge facing policy owners is to minimize power consumption without adversely impacting the system’s usability. This balanced approach provides the user with both power savings and good performance.
Because the policy owner has very specific knowledge about when a device is in use or potentially in use, there is no need for hardware timers or such to determine when to make these transitions. Similarly, this level of understanding of device usage makes it possible to use fewer device power states. Generally, intermediate states attempt to draw a compromise between latency and consumption because of the uncertainty of actual device usage. With the increased knowledge in the OS, good decisions can be made about whether the device is needed at all. With this ability to turn devices off more frequently, the benefit of having intermediate states diminishes.
The policy owner also determines what class-specific events can cause the system to transition from sleeping to working states, and enables this functionality based on application or user requests. Notice that the definition of the wake events that each class supports will influence the system’s global power policy in terms of the level of power management a system sleeping state can attain while still meeting wake latency requirements set by applications or the user.
A.2. Device Power States¶
The following definitions apply to devices of all classes:
D0. State in which device is on and running. It is receiving full power from the system and is delivering full functionality to the user.
D1. Class-specific low-power state (defined in the following section) in which device context may or may not be lost. Buses in D1 cannot do anything to the bus that would force devices on that bus to lose context.
D2. Class-specific low-power state (defined in the following section) in which device context may or may not be lost. Attains greater power savings than D1. Buses in D2 can cause devices on that bus to lose some context (for example, the bus reduces power supplied to the bus). Devices in D2 must be prepared for the bus to be in D2 or higher.
D3. State in which device is off and not running. Device context is lost. Power can be removed from the device.
Device power-state transitions are typically invoked through bus-specific mechanisms (for example, ATA Standby, USB Suspend, and so on). In some cases, bus-specific mechanisms are not available and device-specific mechanisms must be used. Notice that the explicit command for entering the D3 state might be the removal of power.
It is the responsibility of the policy owner (or other software) to restore any lost device context when returning to the D0 state.
A.2.1. Bus Power Management¶
Policy owners for bus devices (for example, PCI, USB, Small Computer System Interface [SCSI]) have the additional responsibility of tracking the power states of all devices on the bus and for transitioning the bus itself to only those power states that are consistent with those of its devices. This means that the bus state can be no lower than the highest state of one of its devices. However, enabled wake events can affect this as well. For example, if a particular device is in the D2 state and set to wake the system and the bus can only forward wake requests while in the D1 state, then the bus must remain in the D1 state even if all devices are in a lower state.
Below are summaries of relevant bus power management specifications with references to the sources.
A.2.2. Display Power Management¶
Refer to the Display Power Management Signaling Specification (DPMS), available from:
A DPMS-compliant video controller and DPMS-compliant monitor use the horizontal and vertical sync signals to control the power mode of the monitor. There are 4 modes of operation: normal, standby, suspend and off. DPMS-compliant video controllers toggle the sync lines on or off to select the power mode.
A.2.3. PCMCIA/PCCARD/CardBus Power Management¶
PCMCIA and PCCARD devices do not have device power states defined. The only power states available are on and off, controlled by the host bus controller. The CardBus specification is a superset of the PCCARD specification, incorporating the power management specification for PCI bus. Power management capabilities query, state transition commands and wake event reporting are identical.
A.2.4. PCI Power Management¶
For information on PCI Power Management, see the PCI Special Interest Group (PCI-SIG) website. You can find a link to this site at http://uefi.org/acpi, under the heading “PCI Sig”.
PCI Bus Power Management Capabilities Query. PCI Bus device capabilities are reported via the optional Capabilities List registers, which are accessed via the Cap_Ptr.
PCI Bus Power Management State Transition Commands. PCI Bus device power states are controlled and queried via the standard Power Management Status/Control Register (PMCSR).
PCI Bus Wakeup Event Reporting. PCI wake events are reported on the optional PME# signal, with setting of the Wake_Int bit in the PMCSR. Wake event reporting is controlled by the Wake_En bit in the PMCSR register.
A.2.5. USB Power Management¶
See the Universal Serial Bus Implementers Forum (USB-IF ) Web site, as listed at http://uefi.org/acpi under the heading “Universal Serial Bus Power Management”.
USB Power Management Capabilities Query. USB device capabilities are reported to the USB Host via the standard Power Descriptors. These address power consumption, latency time, wake support, and battery support and status notification.
USB Power Management State Transition Commands. USB device power states are controlled by the USB Host via the standard SET_FEATURE command. USB device power states are queried via the standard USB GET_STATUS command.
USB Wakeup Event Reporting. USB wake event reporting is controlled using the SET_FEATURE command, with value DEVICE_REMOTE_WAKEUP. USB wake events are reported by sending remote wake resume signaling.
A.2.6. Device Classes¶
Below is a list of the class-specific device power management definitions available in this specification. Notice that there exists a default device class definition that applies to all devices, even if there is a separate, class-specific section that adds additional requirements.
Audio Device Class. Applies to audio devices.
COM Port Device Class. Applies to COM ports devices.
Display Device Class. Applies to CRT monitors, LCD panels, and video controllers for those devices.
Input Device Class. Applies to standard types of input devices such as keyboards, keypads, mice, pointing devices, joysticks, and game pads, plus new types of input devices such as virtual reality devices.
Modem Device Class. Applies to modem and modem-like (for example, ISDN terminal adapters) devices.
Network Device Class. Applies specifically to Ethernet and token ring adapters. ATM and ISDN adapters are not supported by this specification.
PC Card Controller Device Class. Applies to PC Card controllers and slots.
Storage Device Class. Applies specifically to ATA hard disks, floppy disks, ATAPI and SCSI CD-ROMs, and the IDE channel.
A.3. Default Device Class¶
The requirements expressed in this section apply to all devices, even if there is a separate, class-specific power management definition that identifies additional requirements.
Table A-1: Default Power State Definitions
State |
Definition |
|---|---|
D0 |
Device is on and running. It is receiving full power from the system, and is delivering full functionality to the user. |
D1 |
This state is not defined and not used by the default device class. |
D2 |
This state is not defined and not used by the default device class. |
D3 |
Device is off and not running. Device context is assumed lost, and there is no need for any of it to be preserved in hardware. This state should consume the minimum power possible. Its only requirement is to recognize a bus-specific command to re-enter D0. Power can be removed from the device while in D3. If power is removed, the device will receive a bus-specific hardware reset upon reapplication of power, and should initialize itself as in a normal power on. |
A.3.1. Default Power Management Policy¶
Table A-2: Default Power Management Policy
Present State |
Next State |
Cause |
|---|---|---|
D0 |
D3 |
Device determined by the OS to not be needed by any applications or the user. System enters a sleeping state. |
D3 |
D0 |
Device determined by the OS to be needed by some application or the user. |
A.3.2. Default Wake Events¶
There are no default wake events, because knowledge of the device is implicit in servicing such events. Devices can expose wake capabilities to OSPM, and device-specific software can enable these, but there is no generic application-level or OS-wide support for undefined wake events.
A.3.3. Default Minimum Power Capabilities¶
All devices must support the D0 and D3 states. Functionality available in D0 must be available after returning to D0 from D3 without requiring a system reboot or any user intervention. This requirement applies whether or not power is removed from the device during D3.
A.4. Audio Device Class¶
The requirements expressed in this section apply to audio devices
A.4.1. Audio Device Power State Definitions¶
Table A-3: Audio Device Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
Power is on. Device is operating. |
D1 |
Optional |
Power consumption is less than D0 state. Device must be able to transition between D0 and D1 states within 100 ms. No audio samples may be lost by entering and leaving this state. |
D2 |
Required |
Power consumption is less than D0 state. Device must be able to transition between D0 and D2 states within 100 ms. Audio samples may be lost by entering and leaving this state. |
D3 |
Required |
The device is completely off or drawing minimal power. For example, a stereo will be off, but a light-emitting diode (LED) may be on and the stereo may be listening to IR commands. |
If a device is in the D1 or D2 state it must resume within 100 ms. A device in the D3 state may take as long as it needs to power up. It is the responsibility of the policy owner to advertise to the system how long a device requires to power up.
All audio devices must be capable of D0, D2 and D3 states. It is desirable that an audio device be capable of D1 state. The difference between D1 and D2 is that a device capable of D1 can maintain complete state information in reduced power mode. The policy owner or other software must save all states for D2-capable devices. Some audio samples may be lost in transitioning into and out of the D2 state.
Notice that the D1 state was added to allow digital signal processor (DSP)-equipped audio hardware to exploit low-power modes in the DSP. For example, a DSP may be used to implement Dolby AC-3 Decode. When paused it stops playing audio, but the DSP may contain thousands of bytes worth of state information. If the DSP supports a low-power state, it can shut down and later resume from exactly the audio sample where it paused without losing state information.
A.4.2. Audio Device Power Management Policy¶
For the purpose of the following state transition policy, the following device-specific operational states are defined:
Playing. Audio is playing.
Recording:
Foreground. Normal application is recording. Recording is considered foreground unless specifically designated low priority.
Background. Speech recognition or speech activity detection is running. Recording may be preempted by foreground recording or playing. Any audio recording may be designated as background.
Full Duplex. Device is simultaneously playing and recording.
Paused. File handle is open. Only devices that are playing, foreground recording or in full duplex operation may be paused. Background recording may not be paused. State is static and never lost. The paused state assumes that a device must transition to the resumed state rapidly. Playing or recording must be resumed within 100 ms. No audio samples may be lost between the device is paused and later resumed.
Closed. No file handle is open.
Table A-4: Audio Device Power Management Policy
Present State |
Next State |
Cause |
|---|---|---|
D3 |
D0 |
Audio device moves from closed to open state or paused when the device receives the resume command. |
D0 |
D1 |
Audio device receives pause command. If device is D1 capable, this state is preferred. If not, the device driver will preserve context, and the device will be set to D2. |
D2/D1 |
D0 |
Audio device receives a resume command. |
D0 |
D2 |
Audio device is closed. Audio inactivity timer started. |
D2 |
D3 |
Audio inactivity timer expires. |
D0 |
D3 |
Audio device is in background record mode and receives power-down command. |
When an audio device is in the D0 state it will refuse system requests to transition to D3 state unless it is in background record mode. When an audio device is paused (D1 or D2) and it receives a request to transition to the D3 state, it will save the state of the audio device and transition to the D3 state.
Since multimedia applications often open and close audio files in rapid succession, it is recommended that an inactivity timer be employed by the policy owner to prevent needless shutdowns (D3 transitions) of the audio hardware. For example, frequent power cycling may damage audio devices powered by vacuum tubes.
A.4.3. Audio Device Wake Events¶
An audio device may be a wake device. For example, a USB microphone designed for security applications might use the USB wake mechanism to signal an alarm condition.
A.4.4. Audio Device Minimum Power Capabilities¶
All audio devices must be capable of D0, D2 and D3 power states. If the device is capable of maintaining context while in a low-power state it should advertise support for D1. Transitional latency for the D2 or D3 states must be less than 100 ms. There are no latency restrictions for D3 transitions, but the policy owner should advertise the amount of time required.
A.5. COM Port Device Class¶
The requirements expressed in this section apply to Universal Asynchronous Receiver/Transmitters (UARTs) such as the common NS16550 buffered serial port and equivalents.
The two required states for any power-managed COM Port are full on (D0) and full off (D3). This in turn requires that the COM port hardware be power-manageable by ACPI control methods for COM ports that are on system boards, or by standard bus power management controls for COM ports that are on add-in cards (for example, PCI). Because of this, ISA-based COM port add-in cards will not be able to meet this requirement, and therefore cannot be compliant with this specification.
A.5.1. COM Port Power State Definitions¶
Table A-5: COM Port Device Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
Line drivers are on. UART context is preserved. |
D1 |
N/A |
This state is not defined for COM Ports. Use the D3 state instead. |
D2 |
N/A |
This state is not defined for COM Ports. Use the D3 state instead. |
D3 |
Required |
Line drivers are off (unpowered; outputs isolated from devices attached to the port). UART context is lost. Latency to return to D0 is less than 1 second. |
A.5.2. COM Power Power Management Policy¶
Table A-6: COM Port Device Power Management Policy
Present State |
Next State |
Cause |
|---|---|---|
D3 |
D0 |
Power-on reset COM port opened by an application |
D0 |
D3 |
COM port closed System enters sleeping state while wake is disabled on this device. System enters sleeping state while wake is enabled on this device and the device is capable of generating wake to the system from state D3. |
A.5.3. COM Port Wake Events¶
If the COM port is capable of generating wake events, asserting the “ring indicator” line (V.24 circuit 125) will cause the COM port to assert a wake event. There are two common mechanisms that may be employed (either one or both) for performing machine wake using COM ports.
The first provides a solution that is capable of waking the PC whether the UART is powered (D0) or not (D3). Here, the “ring indicator” line (from V.24 circuit 125) is commonly connected directly to the system wake device in addition to being connected to the UART. While this implementation is normative for COM ports located on system motherboards (see the ACPI specification), it could also be done by add-in cards with COM ports that reside on buses supporting system wake from devices in D3 (for example, PME# signal on PCI).
The second mechanism requires that the UART be powered (D0) to use the UART’s interrupt output pin to generate the wake event instead. When using this method, the OS COM port policy owner or power management control methods are expected to configure the UART. Although any UART interrupt source (for example, ‘data ready’) could theoretically be used to wake the system, these methods are beyond the scope of this document.
A.5.4. COM Port Minimum Power Capabilities¶
A COM port conforming to this specification must support the D0 and D3 states.
A.6. Display Device Class¶
The requirements expressed in this section apply to all devices engaged in the display of program content, which includes full screen display devices, display controllers, and graphics adapters. This class does not include video capture devices unless they are children of the graphics adapter. This class does not include edge displays or hardware indicators for device states.
While saving power from the display and adapter are primary goals of Display Device Class power management definitions, the definitions are also intended to ensure that the user perceives the system as “off” during system sleeping states, as required above. When the system enters a lower power state, the screen must go black so the user knows the system is idle. This is important because devices that cannot actually save power (standard televisions, for example) can still support the user notice of system idle by going black.
A.6.1. Display Device Power State Definitions¶
Table A-7: CRT Monitors Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
This state is equivalent to the “On” state defined in the VESA DPMS specification (see Related Documents) and is signaled to the display using the DPMS method. Display is fully on Video image is active |
D1 |
Optional |
This state is equivalent to the “Standby” state defined in the VESA DPMS and is signaled to the display using the DPMS method. Display is functional but may be conserving energy Video image is blank Latency to return to D0 must be less than 5 seconds |
D2 |
Required |
This state is equivalent to the “Suspend” state defined in the VESA DPMS specification and is signaled to the display using the DPMS method. Display is functional and conserving energy Video image is blank Latency to return to D0 is less than 10 seconds |
D3 |
Required |
This state is equivalent to the “Off” state defined in the VESA DPMS specification and is signaled to the display using the DPMS method. Display is non-functional Video image is blank |
CRT Monitors are a special case in power management. On the one hand, they support a common defined method (DPMS) for changing power states. On the other hand, that procedure and the CRT support is extremely slow and out of keeping with other faster power control methods used by other forms of display. This definition should not preclude the use of faster and more effective methods of transitioning the CRT if they are available and known to the controller. DPMS is not recommended as solution for new display devices in the future.
Table A-8: Internal Flat Panel Displays Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
This state is equivalent to the “On” state for a DPMS device, but is signaled to the panel by the correct application of power and/or controller specific signaling. Display is fully on Backlight (if present) is fully on(subject to performance state requirements - see below) Video image is active |
D1 |
Optional |
This state is not required to be physically different than a D3 state if the device is able to meet the resume requirement and the driver is able to restore state. Display retains internal state but may be conserving energy Backlight(if present) is fully off Video image is blank Latency to return to D0 must be less than 500 milliseconds |
D2 |
Optional |
This state is not required to be physically different than a D3 state if the device is able to meet the resume requirement and the driver is able to restore state. Display retains state but is conserving energy Backlight (if present) is fully off; Video image is blank Latency to return to D0 is less than 500 milliseconds |
D3 |
Required |
This state is equivalent to the “Off” state defined in the VESA DPMS specification. It is signaled by the removal of power or possibly by controller-specific signaling. Display is non-functional Backlight (if present) is fully off. Video image is blank Latency to return to D0 is less than 500 milliseconds |
Internal flat panels (also known as local flat panels or sometimes as LCDs) do not normally support or require DPMS signaling to change power states. Instead, controllers capable of managing such panels tend to provide vendor-specific methods to control internal flat panels, often involving special sequencing of power signals to the panel. Some may be managed only by the application or removal of power.
Backlight control for power management states is likewise controller and even platform specific. Note that on-off backlight control for power management states is often unrelated to backlight intensity or brightness control that is used while in the D0 state.
The 500 milliseconds is only to allow some existing hardware to function . The target for new devices should be 100 milliseconds.
Table A-9: External Digital Displays Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
This state is equivalent to the “On” state for a DPMS device, but is signaled to the display by the correct application of power and/or controller specific signaling. Display is fully on. Video image is active. |
D1 |
Optional |
This state is not required to be physically different than a D3 state if the device is able to meet the resume requirement and the driver is able to restore state. It is signaled by the removal of display output and time expiring. The physical state entered is no different than D2. Display retains internal state but may be conserving energy Video image is blank Latency to return to D0 must be less than 250 milliseconds*. |
D2 |
Optional |
This state is not required to be physically different than a D3 state if the device is able to meet the resume requirement and the driver is able to restore state. It is signaled by the removal of display output and time expiring The physical state entered is no different than D1. Display retains state but is conserving energy. Video image is blank. Latency to return to D0 is less than 250 milliseconds*. |
D3 |
Required |
This state is equivalent to the “Off” state defined in the VESA DPMS specification. It is signaled by the removal of display output and time expiring. Display is non-functional. Video image is blank. Latency to return to D0 is less than 250 milliseconds*. |
Note
* Although a latency of 250 milliseconds is shown here, because not all devices in this group are faster, the target resume time for a new device should be less than 100 milliseconds.
Table A-10: Standard TV Devices and Analog HDTVs Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
This state is equivalent to the “On” state for a DPMS device. Display is fully on Video image is active |
D1 |
Optional |
Video image is blank Latency to return to D0 must be less than 100 milliseconds |
D2 |
Optional |
Video image is blank Latency to return to D0 must be less than 100 milliseconds |
D3 |
Required |
This state is not equivalent to the “Off” state defined in the VESA DPMS specification because not power is actually saved. Video image is blank Latency to return to D0 is less than 100 milliseconds |
Table A-11: Other (new) Full Screen Display Devices Power State Definitions
Some devices not specifically defined above already exist, such as projectors that emulate CRTs or HDTVs. Others may be coming. It is important for any device used for full screen display to support power transitions and power management states, but the primary requirement for the method should be low overhead.
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
This state is equivalent to the “On” state for a DPMS device, but is signaled to the panel by the correct application of power and/or device specific signaling known to the controller. Display is fully on Video image is active |
D1 |
Optional |
This state is not required to be physically different than a D3 state if the device is able to meet the resume requirement and the driver is able to restore state. It is signaled to the panel by the correct application of power and/or device specific signaling known to the controller. Display retains internal state but may be conserving energy Video image is blank Latency to return to D0 must be less than 100 milliseconds |
D2 |
Optional |
This state is not required to be physically different than a D3 state if the device is able to meet the resume requirement and the driver is able to restore state. It is signaled to the panel by the correct application of power and/or device specific signaling known to the controller. Display retains state but is conserving energy Video image is blank Latency to return to D0 is less than 100 milliseconds |
D3 |
Required |
This state is equivalent to the “Off” state defined in the VESA DPMS specification. It is signaled by the removal of display output and/or device specific methods known to the controller. Display is non-functional Video image is blank Latency to return to D0 is less than 250 milliseconds |
Note
* Although a latency of 250 milliseconds is shown here, because not all devices in this group are faster, the target resume time for a new device should be less than 100 milliseconds.
Table A-12: Video Controllers (Graphics Adapters) Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
Back-end is on Video controller context is preserved Video memory contents are preserved |
D1 |
Optional |
Back-end is off, except for CRT control signaling (DPMS) Video controller context is preserved Video memory contents is preserved Latency to return to D0 is less than 100 milliseconds |
D2 |
Optional |
Back-end is off, except for CRT control signaling (DPMS) Video controller context is lost Video memory contents is lost Latency to return to D0 is less than 200 milliseconds |
D3 |
Required |
Back-end is off Video controller context is lost (power removed) Video memory contents is lost (power removed) Latency to return to D0 is less than 200 milliseconds |
A.6.1.1. Display Codecs¶
Like the displays they control, display codecs are children of the adapter and cannot be in a higher state than the adapter or a lower state than the displays they control . It is generally not helpful to deal with codecs entirely separately from the adapter or the displays they control. While it may vary from device to device, a codec will either be safely powered down when its display is powered down or it may require power as long as the adapter receives power.
A.6.2. Display Device Power Management Policy¶
Table A-13: Display Device Power Management Policy
Present State |
Next State |
Cause |
|---|---|---|
D0 |
D1 |
User inactivity for a period of time (T1) |
D1 |
D2 |
User inactivity for a period of time (T2 > T1) |
D2 |
D3 |
User inactivity for a period of time (T3 > T2) |
D1/D2/D3 |
D0 |
User activity or application UI change (for example, dialog pop-up) |
These state transition definitions apply to both the full screen display and the video controller. However, the control of the two devices is independent, except that a video controller will never be put into a lower power state than its full screen display. Also, while full screen displays can transition directly from D1 to D3 or from D2 to D3, the adapters require a transition to D0 from D1 or D2 before entering D3.
Transitions for the video controller are commanded via the bus-specific control mechanism for device states. Monitor/LCD transitions are commanded by signaling from the video controller and are only generated as a result of explicit commands from the policy-owner. Full screen display power control is functionally independent from any other interface the monitor may provide (such as USB). For instance, Hubs and HID devices in the monitor enclosure may be power-managed by their driver over the USB bus, but the Monitor/LCD device itself may not; it must be power-managed from the video controller using the methods above.
A.6.3. Display Device Wake Events¶
Display devices incorporating a system power switch should generate a wake event when the switch is pressed while the system is sleeping.
A.6.4. Display Device Minimum Power Capabilities¶
A CRT monitor conforming to this specification must support the D0, D2, and D3 states. Other full screen displays only need to support D0 and D3. Support for the D1 state is optional in all cases. Transitional latencies for the D1 or D2 state must meet the requirements above.
A video controller conforming to this specification must support the D0 and D3 states. Support for the D1 and D2 states is optional. Transitional latencies for the D1 must be less than 100 milliseconds while D2 and D3 must transition to D0 in less than 200 milliseconds.
A.6.5. Display Device Performance States¶
Performance states for display devices and adapters have one clear difference from defined power management states. There is no display in any power management state higher than D0. However, performance states are all applied within D0, which means they save power while continuing to display. Not all display class devices will support performance states, but in all cases, they must allow continued display where they exist.
A.6.5.1. Common Requirements for Display Class Performance States¶
The definition of each state (up the line toward the OSPM) must include maximum latency information on transitions into the state and transitions out of the state. (For states other than DPS1, it may be necessary to indicate whether the latency is the time from DPS0 to DPSx or only from DPSx-1 to DPSx.)
Each state has to have a relative weight indicator or a relative power savings indicator (i.e., it can make a difference in OSPM policies whether DPS1 saves 2% power and DPS2 save 75% power even if latency is longer.)
While ASL NameSpace structures may provide some of this information, it is recommended that display class performance states be entered and exited by driver and not by control method wherever possible.
A.6.5.2. Performance states for Full Screen Displays¶
A.6.5.2.1. CRT Performance States¶
Some CRTs (in theory) have the capability for “reduced on” – a mode which displays but uses less power than full performance. Even without this capability, a CRT may be able to use reduced refresh or other methods to reduce the total power of displaying.
A.6.5.2.2. Internal Flat Panel¶
In general, panels consume a fixed amount of power. However, some panels are also capable of supporting reduced refresh. More important, the amount of backlight brightness is a major factor in system power. This clearly needs to be coordinated with direct ASL control methods for brightness and with ambient light sensing when present. However, a performance state may be achieved by offsetting the brightness value computed by other methods, either by a fixed amount or a fixed percentage.
A.6.5.2.3. DVI Full Screen Devices¶
DVI Devices are normally capable of frequency control and may be able to benefit by frequency control. However, because of sensitivity to signal loss, DVI devices may have limitations on other types of performance control.
A.6.5.2.4. Standard TV and Analog HDTVs¶
Standard TV and Analog HDTVs do not appear capable of performance states. Codecs controlling them may be capable of power saving, however.
A.6.5.2.5. New Devices¶
The ability to reduce power while continuing to display will be increasingly important.
A.6.5.3. Performance States for Video Controllers/Display Adapters¶
Adapters are somewhat limited during performance states because they have to continue to support display on one or more full screen devices. However, they can still do a number of things to support performance states, including
Changes to basic display and render capabilities, including speed or frequency range supported.
Feature/Capability/Quality Control - limiting specific hardware features, limiting refresh rates, limiting resolutions.
The limiting factor on what can be supported may sometimes be in the OSPM. If the OSPM support dynamic changes in these features during a performance state change (even if no other time), more opportunities arise.
Once again, the latency on transitions and the power saved by specific states have to be made available to the OSPM in order to use these options effectively.
A.7. Input Device Class¶
The requirements expressed in this section apply to standard types of input devices such as keyboards, keypads, mice, pointing devices, joysticks, game pads, to devices that combine these kinds of input functionality (composite devices, and so on), and to new types of input devices such as virtual reality devices, simulation devices, and so on.
A.7.1. Input Device Power State Definitions¶
Table A-14: Input Device Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
Device is receiving full power from its power source, delivering full functionality to the user, and preserving applicable context and state information. |
D1 |
Optional |
Input device power consumption is greatly reduced. In general, device is in a power management state and is not delivering any functionality to the user except wake functionality if applicable. Device status, state, or other information indicators (for example, LEDs, LCD displays, and so on) are turned off to save power. The following device context and state information should be preserved by the policy owner or other software: Keyboard. Num, caps, scroll lock states (and Compose and Kana states if applicable) and associated LED/indicator states, repeat delay, and repeat rate. Joystick. Forced feedback effects (if applicable). Any input device. All context and state information that cannot be preserved by the device when it’s conserving power. |
D2 |
N/A |
This state is not defined for input devices, use D1 as the power management state instead. |
D3 |
Required |
Input device is off and not running. In general, the device is not delivering any functionality to the user except wake functionality if applicable. Device context and state information is lost. |
A.7.2. Input Device Power Management Policy¶
Table A-15: Input Device Power Management Policy
Present State |
Next State |
Cause |
|---|---|---|
D3 |
D0 |
Requested by the system |
D0 |
D1/D3* |
Requested by the system (for example, system goes to sleep with wake enabled) |
D0/D1 |
D3 |
Requested by the system (for example, system goes to sleep with wake disabled) Power is removed |
D1/D3 |
D0 |
Device with enabled wake capability requests transition by generating a wake event Requested by the system |
Note
This depends on whether the device features D1 or D3 wake capability or not; device will be put in the state with the lowest possible power consumption.
A.7.3. Input Device Wake Events¶
It is recommended, but not required, that input devices implement and support bus-specific wake mechanisms if these are defined for their bus type. This is recommended because a user typically uses an input device of some kind to wake the system when it is in a power management state (for example, when the system is sleeping).
The actual input data (particular button or key pressed) that’s associated with a wake event should never be discarded by the device itself, but should always be passed along to the policy owner or other software for further interpretation. This software implements a policy for how this input data should be interpreted, and decides what should be passed along to higher-level software, and so on.
It is recommended that the device button(s) or key(s) used for power management purposes are clearly labeled with text and/or icons. This is recommended for keyboards and other input devices on which all buttons or keys are typically labeled with text and/or icons that identify their usage.
For example, a keyboard could include a special-purpose power management button (for example, “Power”) that, when pressed during a system sleeping state, generates a wake event. Alternatively, the button(s) on mice and other pointing devices could be used to trigger a wake event.
Examples of more advanced wake events include keyboard wake signaling when any key is pressed, mouse wake signaling on detection of X/Y motion, joystick wake signaling on X/Y motion, and so on. However, in order to avoid accidental or unintentional wake of the system, and to give the user some control over which input events will result in a system wake, it’s suggested that more advanced types of wake events are implemented as features that can be turned on or off by the user (for example, as part of the OSPM user interface).
A.7.4. Input Device Minimum Power Capabilities¶
An input device conforming to this specification must support the D0 and D3 states. Support for the D1 state is optional.
A.8. Modem Device Class¶
The requirements expressed in this section apply to modems and similar devices, such as USB controlled ISDN Terminal Adapters (“digital modems”) and computer-connected telephone devices (“CT phones”). This specification will refer to these devices as “modems; the same considerations apply to digital modems and CT phones unless explicitly stated otherwise.
The scope of this section is further restricted to modems that support power management using methods defined by the relevant PC-modem connection bus. These include PCI, USB, PCCARD (PCMCIA), CardBus, and modems on the system motherboard described by ACPI system firmware control methods. The scope does not include bus-specific means for devices to alert the host PC (for example, how to deliver a “ringing”’ message), nor does it address how those alerting operations are controlled.
A.8.1. Technology Overview¶
Modems are traditionally serial devices, but today modems may be attached to a PC by many different means. Further, many new modems expose a software serial interface, where the modem controller function is implemented in software. This specification addresses three different connection types:
Traditional connections without power-managed connections (for example, COM, LPT, ISA)
Power managed connections (for example, PCCARD, CardBus, PCI, USB)
Motherboard modems
For some of the above modem connection types mentioned, there are three different modem architectures possible:
Traditional modem (DAA, DSP, and controller in hardware)
Controller-less design (DAA and DSP in hardware)
“Soft modem” design (DAA and CODEC only in hardware)
The hardware components of the modem shall be controlled by the relevant bus commands, where applicable (USB, PCI, CardBus). The software components are dependent on the power state of the CPU.
A.8.1.1. Traditional Connections¶
In older methods (COM, LPT, ISA) the modem is controlled primarily by serialized ASCII command strings (for example, V.25ter) and traditional V.24 (RS-232) out-of-band leads. In these legacy devices, there are no common means for power management other than the power switch for the device, or the entire system unit.
An external modem connected to a COM port or LPT port typically has its own power supply. An LPT port modem might run from the current on the LPT port +5V supply. For COM or LPT port modems, power is typically controlled by a user switch.
The most common modem type is an ISA card with an embedded COM port. From a software standpoint, they are logically identical to external modems, but the modems are powered by the PC system unit. Power is drawn from the ISA bus without independent power switching.
A.8.1.2. Power-Managed Connections¶
PCMCIA, PCCARD and CardBus slots are powered and power-managed by the system, using means defined in the relevant bus specifications. For PCMCIA and PCCARD devices, only D0 and D3 states are available, via Socket Services in the OS and/or ACPI system firmware. CardBus adds intermediate states, using the same mechanisms defined for PCI Bus.
PCI bus slots are powered and power-managed by the system, using means defined in the PCI specification.
USB devices may be powered by the USB itself (100mA or 500mA), or have their own external power supply. All USB devices are power-managed by the USB bus master, using means defined in the USB specification.
A.8.1.3. Motherboard Modems¶
A modem embedded in the motherboard is powered by controls on the motherboard. It should be power-managed by using control methods exposed via ACPI system firmware tables.
A.8.2. Modem Device Power State Definitions¶
Table A-16: Modem Device Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
Phone interface is on (may be on or off hook) Speaker is on Controller Context is preserved |
D1 |
N/A |
Not defined (do not use) |
D2 |
Optional |
Phone interface is not powered by the host (on hook) Speaker is off Controller context is preserved 2 seconds maximum restore time |
D3 |
Required |
Phone interface is not powered by host (on hook) Speaker is off Controller context may be lost 5 seconds maximum restore time |
A.8.3. Modem Device Power Management Policy¶
Table A-17: Modem Device Power Management Policy
Present State |
Next State |
Cause |
|---|---|---|
D2/D3 |
D0 |
System issues a bus command to enter the D0 state (for example, an application is answering or originating a call). |
D0 |
D2 |
System issues a bus command to enter the D2 state. (for example, an application is listening for an incoming call). |
D0 |
D3 |
System issues a bus command to enter the D3 state (for example, all applications have closed the Modem device). |
A.8.4. Modem Device Wake Events¶
For any type of modem device, wake events (if supported and enabled) are only generated in response to detected “ringing” from an incoming call. All other events associated with modems (V.8bis messages, and so on) require that the PC be in the “working” state to capture them. The methods and signals used to generate the wake may vary as a function of the modem connection (bus) type and modem architecture.
Machine wake is allowed from any modem power state (D0, D2, and D3), and is accomplished by methods described in the appropriate bus power management specification (PCI, USB, PCCARD), or by ACPI system board control methods (for Modem on Motherboard implementations).
If the specific modem implementation or connection type does not enable it to assert system wake signaling, these modems will not be able to wake the machine. The OS modem policy owner will have to retain the PC in the “working” state to perform all types of event detection (including ringing).
A.8.5. Modem Device Minimum Power Capabilities¶
A modem or similar device conforming to this specification must support the D0 and D3 states. Support of the D2 state is optional.
A.9. Network Device Class¶
The requirements expressed in this section apply to Ethernet and token ring adapters. ATM and ISDN adapters are not supported by this specification.
A.9.1. Network Device Power State Definitions¶
For the purpose of the following state definitions “no bus transmission” means that transmit requests from the host processor are not honored, and “no bus reception” means that received data are not transferred to host memory.
Table A-18: Network Device Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
Device is on and running and is delivering full functionality and performance to the user Device is fully compliant with the requirements of the attached network |
D1 |
Optional |
No bus transmission allowed No bus reception allowed No interrupts can occur Device context may be lost |
D2 |
Optional |
No bus transmission allowed No bus reception allowed No interrupts can occur Device context may be lost |
D3 |
Required |
Device context is assumed to be lost No bus transmission allowed No bus reception allowed No interrupts can occur |
This document does not specify maximum power and maximum latency requirements for the sleeping states because these numbers are very different for different network technologies. The device must meet the requirements of the bus that it attaches to.
Although the descriptions of states D1 and D2 are the same, the choice of whether to implement D1 or D2 or both may depend on bus services required, power requirements, or time required to restore the physical layer. For example, a device designed for a particular bus might include state D1 because it needs a bus service such as a bus clock to support Magic Packet™ wake, and that service is available in the bus device’s D1 power state but not in D2. Also, a device might include both state D1 and state D2 to provide a choice between lower power and lower latency.
A.9.2. Network Device Power Management Policy¶
Table A-19: Network Device Power Management Policy
Present State |
Next State |
Cause |
|---|---|---|
D0 |
Dx |
System enters sleep state. If wake is enabled, Dx is the lowest power state (for example, D1, D2, D3) from which the network device supports system wake. An appropriate time-out has elapsed after a “link down” condition was detected. Dx is the lowest power state in which the network device can detect “link up.” |
D0 |
D3 |
System initiated network shutdown. System enters sleep state and wake is either not enabled or the network device is capable of waking from D3. |
D1/D2/D3 |
D0 |
System wake (transition to S0), including a wake caused by a network wake event. |
A.9.3. Network Device Wake Events¶
Network wake events are generally the result of either a change in the link status or the reception of a wake frame from the network.
A.9.3.1. Link Status Events¶
Link status wake events are useful to indicate a change in the network’s availability, particularly when this change may impact the level at which the system should re-enter the sleeping state. For example, a transition from “link off” to “link on” may trigger the system to re-enter sleep at a higher level (for example, S2 versus S3) so that wake frames can be detected. Conversely, a transition from “link on” to “link off” may trigger the system to re-enter sleep at a deeper level (for example, S3 versus S2) since the network is not currently available. The network device should implement an internal delay to avoid unnecessary transitions when the link status toggles on or off momentarily.
A.9.3.2. Wake Frame Events¶
Wake frame events are used to wake the system whenever meaningful data is presented to the system over the network. Examples of meaningful data include the reception of a Magic Packet™, a management request from a remote administrator, or simply network traffic directly targeted to the local system. In all of these cases the network device was pre-programmed by the policy owner or other software with information on how to identify wake frames from other network traffic. The details of how this information is passed between software and network device depend on the OS and therefore are not described in this specification.
A.9.4. Network Device Minimum Power Capabilities¶
A network device conforming to this specification must support the D0 and D3 states. Support for the D1 and D2 states is optional.
A.10. PC Card Controller Device Class¶
The requirements expressed in this section apply to PC Card controller devices and the PC Card slots.
Power management of PC Cards is not defined by this specification. PC Card power management is defined by the relevant power management specification for the card’s device class (for example, network, modem, and so on), in conjunction with the PC Card standard (for 16-bit cards) or the PCI Power Management Specification (for CardBus cards).
A.10.1. PC Card Controller Device Power State Definitions¶
Table A-20: PC Card Controller Device Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
Card status change interrupts are fully functional. Card functional interrupts are fully functional. Controller context (for example, memory, I/O windows) is fully functional. Controller interface is fully functional (processor can access cards). Power to cards (slots) is available (may be on or off under software control). The controller is at its highest power consumption level. Bus command response time is at its fastest level. PC Cards can be in any Dx power state (D0-D3). Note: In D0 state, CSTSCHG interrupts can be passed to a system from a powered down PC Card (for more detail, refer to section 5.2.11.2 of PC Card Standard, Electrical Specification). |
D1 |
Optional |
Card status change interrupts are disabled. CSTSCHG interrupt events are still detectable by the controller and cause the bus-specific wake signal to be asserted if wake is enabled on the controller. Card functional interrupts are disabled. Controller context is preserved (all register contents must be maintained but memory and I/O windows need not be functional). Controller interface is non-functional (processor cannot access cards). Power to cards (slots) is available (may be on or off; retains power setting it had at time of entry to D1). Power-level consumption for the controller is high but less than D0. The time required to restore the function from the D1 state to the D0 state is quicker than resumption from D3. Bus command response time is equal to or slower than in D0. PC Cards can be in the D1, D2, or D3 power states (not D0). Note: In D1 state, CSTSCHG interrupts can be passed to a system from a powered-down PC Card (for more detail, refer to section 5.2.11.2 of PC Card Standard, Electrical Specification). |
D2 |
Optional |
Functionally the same as D1 (may be implemented instead of D1 in order to allow bus and/or system to enter a lower-power state). |
D3 |
Required |
Card status change interrupt: Disabled and need not be detected. Card functional interrupt: Disabled and need not be detected. Controller context (for example, memory, I/O windows): Lost. Controller interface: Non-functional (processor can not access cards). Clock to controller: Off. Power to cards (slots): Off (card context lost). Note: If Vcc is removed (for example, PCI Bus B3) while the device is in the D3 state, a bus-specific reset (for example, PCI RST#) must be asserted when power is restored and functions will then return to the D0 state with a full power-on reset sequence. Whenever the transition from D3 to D0 is initiated through assertion of a bus-specific reset, the power-on defaults will be restored to the function by hardware just as at initial power up. The function must then be fully initialized and reconfigured by software. |
A.10.2. PC Card Controller Device Power Management Policy¶
The PC Card controller is a bus controller. As such, its power state is dependent on the devices plugged into the bus (child devices). OSPM will track the state of all devices on the bus and will put the bus into the best possible power state based on the current device requirements on that bus. For example, if the PC Card cards are all in the D1 state, OSPM will put the PC Card controller in the D1 state.
Table A-21: PC Card Controller Device Power Management Policy
Present State |
Next State |
Cause |
|---|---|---|
D2/D3 |
D0 |
Any card in any slot needing to transition to state D0 due to a wake event or because of system usage. |
D0 |
D1 |
No card in any slot is in state D0. |
D0 |
D2 |
No card in any slot is in state D0 or D1. |
D0 |
D3 |
All cards in all slots are in state D3. |
A.10.3. PC Card Controller Wake Events¶
A wake event is any event that would normally assert the controller’s status change interrupt (for example, card insertion, card battery state change, card ReqAttn event, and so on) or ring-indicate signal.
A.10.4. PC Card Controller Minimum Power Capabilities¶
A PC Card controller device conforming to this specification must support the D0 and D3 states. Support for the D1 or D2 states is optional.
A.11. Storage Device Class¶
The requirements expressed in this section apply to ATA hard disks, floppy disks, ATAPI and SCSI CD-ROMs, and the IDE channel.
A.11.1. Storage Device Power State Definitions¶
Table A-22: Hard Disk, CD-ROM and IDE/ATAPI Removable Storage Devices Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
Drive controller (for example, interface and control electronics) is functional. Interface mode context (for example, communications timings) is programmed. |
D1 |
Optional |
Drive controller (for example, interface and control electronics) is functional. Interface mode context (for example, communications timings) is preserved. Drive motor (for example, spindle) is stopped, with fast-start mode enabled, if available. Laser (if any) is off. Recommended latency to return to D0 is less than 5 seconds. Power consumption in D1 should be no more than 80% of power consumed in D0. Note: For ATA devices, this state is invoked by the Standby Immediate command. |
D2 |
N/A |
This state is not defined for storage devices. |
D3 |
Required |
Drive controller (for example, interface and control electronics) is not functional; context is lost. Interface mode (for example, communications timings) is not preserved. Drive motor (for example, spindle) is stopped. Laser (if any) is off. Power consumption in D3 is no more than 10% of power consumed in D0. Note: For ATA devices, this state is invoked by the “sleep” command. |
Table A-23: Floppy Disk Devices Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
Drive controller (for example, interface and control electronics) is functional. Drive motor (for example, spindle) is turning. |
D1 |
N/A |
This state is not defined for floppy disk drives. |
D2 |
N/A |
This state is not defined for floppy disk drives. |
D3 |
Required |
Drive controller (for example, interface and control electronics) is not functional; context is lost. Drive motor (for example, spindle) is stopped. |
Table A-24: IDE Channel Devices Power State Definitions
State |
Status |
Definition |
|---|---|---|
D0 |
Required |
Adapter is functional. Adapter interface mode (for example, communications timings) is programmed. Power is applied to the bus (and all devices connected to it). |
D1 |
N/A |
This state is not defined for the IDE Channel. |
D2 |
N/A |
This state is not defined for the IDE Channel. |
D3 |
Required |
Adapter is non-functional. Adapter interface mode (for example, communications timings) is not preserved. Power to the bus (and all devices connected to it) may be off. |
A.11.2. Storage Device Power Management Policy¶
Table A-25: Hard Disk, Floppy Disk, CD-ROM and IDE/ATAPI Removable Storage Devices Power Management Policy
Present State |
Next State |
Cause |
|---|---|---|
D3 |
D0 |
Device usage (high-priority I/O). |
D0 |
D1* |
Device inactivity (no high-priority I/O) for some period of time (T1). |
D0 |
D3 |
Device inactivity (no high-priority I/O) for a period of time (T2=>T1). System enters sleeping state. |
D1 (if supported) |
D0 |
Device usage (High-priority I/O). |
Note
For ATA, the D3-to-D0 transition requires a reset of the IDE channel. This means that both devices on a channel must be placed into D3 at the same time.
Table A-26: IDE Channel Devices Power Management Policy
Present State |
Next State |
Cause |
|---|---|---|
D3 |
D0 |
Any device on the channel needing to transition to a state other than state D3. |
D0 |
D3 |
All devices on the channel in state D3. |
A.11.3. Storage Device Wake Events¶
Storage devices with removable media can, optionally, signal wake upon insertion of media using their bus-specific notification mechanism. There are no other wake events defined for Storage devices.
A.11.4. Storage Device Minimum Power Capabilities¶
A hard disk, CD-ROM or IDE/ATAPI removable storage device conforming to this specification must support the D0 and D3 states. Support for the D1 state is optional.
A floppy disk and IDE channel device conforming to this specification must support the D0 and D3 states.