PCI Power Management and Device Drivers

This article clarifies some confusion that vendors have experienced about how hardware that complies with PCI Power Management (PCI-PM) interacts with device drivers in the operating system and about how PCI-PM integrates with ACPI. For more information, see https://www.uefi.org/specifications

Device drivers and PCI power management

This discussion assumes that you are familiar with how Windows Driver Model (WDM) drivers handle power management events, as described in the current Windows DDK. In general, the responsibilities for device drivers are as follows:

Bus drivers: Bus drivers are responsible for enumerating, configuring, and controlling devices. For PCI-PM, the PCI driver is responsible for reading the PCI-PM registers to determine the capabilities of the hardware. When POWER IRPs request power state changes, the PCI driver writes to the PCI power management registers to set the hardware to different Dx states.

When a device is enabled for wake-up, the PCI driver writes to PCI-PM registers to enable the device to fire PME (ACPI will also take an action, see the next section). Finally, when ACPI determines that the PCI bus is waking the system, the PCI driver scans PCI configuration space looking for which device is asserting PME, disables PME in that device, and notifies the driver for that device.

Device driver: The specific driver for the device is responsible for saving and restoring device context, and requesting power state changes as the policy owner for the device. When the device driver receives a POWER IRP requesting a lower device power state change, the device driver is responsible for saving any proprietary device context needed to later turn on the device. In some cases, there may be nothing to save.

PCI-PM registers are strictly the domain of the PCI driver—the IHV’s device driver does not need to access any of these registers. Doing so would cause the system to not work reliably. The device driver’s responsibility is to perform only proprietary actions.

Integrating ACPI and PCI PM

Some devices, particularly motherboard video devices in portables, may require both PCI Power Management as well as ACPI Source Language Assembler (ASL) to completely power manage the device. The PCI Power Management registers would control the internal state of a device, such as internal clocks and power planes. ASL would control the external state, such as external clocks and power planes, or in the case of video controllers, ASL would control the video backlights. Note that ASL and PCI-PM can only be combined on motherboard devices.

The OnNow architecture is a layered architecture, handling the integration of the device driver, PCI driver, and ACPI driver (and ASL) naturally. The following scenarios show the order in which drivers are called to handle these devices.

For the above scenarios to work as described, a WDM driver must forward POWER IRPs correctly as described in the current version of the Microsoft Windows DDK.

Device power management

The ACPI 6.3 specification defines a set of namespace objects to specify device power information for a device. For example, one set of objects can specify the power resources that a device requires in each supported device power state. Another object type can describe the ability of the device to wake from a low-power state in response to hardware events.

Device power management in Windows

While a system is running (that is, the system is in the ACPI-defined working state, S0), individual devices can make transitions between device power states, depending on activity, to save power. In traditional PC systems, ACPI-defined sleeping states (S1 through S4) are also used to save power, but these disconnected, high-latency sleep states are not used on Windows SoC platforms. Therefore, battery life is highly dependent on how platforms implement run-time device power management.

Devices that are integrated into the SoC can be power-managed through the Windows Power Framework (PoFx). These framework-integrated devices are power-managed by PoFx through a SoC-specific power engine plug-in (microPEP) that knows the specifics of the SoC’s power and clock controls. For more information about PoFx, see Overview of the Power Management Framework.

For peripheral devices that are not integrated into the SoC, Windows uses ACPI Device Power Management. For these ACPI-managed devices, the power policy owner in a device driver stack (typically the function or class driver) makes device power state transition decisions, and the Windows ACPI driver, Acpi.sys, invokes ASL control methods to apply the required platform-specific power controls.

It is possible to, and some device stacks do, use ACPI Device Power Management — alone, or in combination with the microPEP — for on-SoC device power management.

As described in Device power management in ACPI, Windows supports the D3cold power management capabilities that are defined in the ACPI 5.0 specification. By using this support, devices, platforms and drivers can opt-in to having device power completely removed during run-time idle periods. This capability can significantly improve battery life. However, removing power must be supported by all affected components in order to be able to return to D0 successfully. For this reason, drivers (bus and function), as well as the platform itself, must indicate that they support it. For more information about D3cold driver opt-in, see Supporting D3cold in a Driver.

Device power management in ACPI

Namespace devices support up to four device power states, numbered D0 (full-function, or «on») to D3 (no function, or «off»). Each state can have different power requirements, with higher-numbered states consuming less power than lower-numbered states. In addition, the D3 (off) state has two sub-states, D3hot and D3cold. The D3hot sub-state requires the device to remain accessible on its parent bus so that it can respond to bus-specific software commands. This requirement, and the power used to meet it, are removed in D3cold. Finally, a device can be armed to wake itself from a low-power state due to a hardware event, and, if necessary, to also bring the platform out of an idle state.

The platform indicates its support for D3cold by granting the OS control of the «_PR3 Support» feature (bit 2) when requested by using the platform-wide OSPM Capabilities Method. For more information, see section 6.2.10.2, «Platform-wide OSPM Capabilities», in the ACPI 5.0 specification.

Power-managed devices use child objects to describe their power capabilities to the operating system. The following sections describe these capabilities and objects.

Power resources and states

A device declares its support for a power state by listing the set of power resources it requires in order to be in that state. ACPI Power Resources represent the voltage rails that power devices and the clock signals that drive them. These resources are declared at the root of the namespace. Each power resource has an _ON and an _OFF method through which it is controlled, and an _STA method to report its state. For more information, see section 7.1, «Declaring a Power Resource Object», of the ACPI 5.0 specification.

The Windows ACPI driver, Acpi.sys, monitors the power dependencies among devices that share resources, and, as these devices transition between power states, ensures that only the power resources that are actually needed by a device are turned on at any particular time.

Power Resource Requirements (_PRx)

There is a Power Resource Requirements (_PRx) object, where x = 0, 1, 2, or 3, for each supported device power state. When the device driver decides to transition to a new power state, Acpi.sys ensures that any power resources required for the new state are turned on, and that any resources no longer in use are turned off.

Device state supported	Resource requirements object to use	Resources to include in requirements object
D0 (required)	_PR0	All power and clocks required for full function of the device.
D1	_PR1	Any power or clocks required for the class-defined reduced-functionality of this state.
D2	_PR2	Any power or clocks required for the class-defined reduced-functionality of this state.
D3hot (required)	_PR3	Only the power or clocks required for the device to appear on its bus and respond to a bus-specific command.

If a particular platform supports the D3cold feature, and the device driver for a device opts-in to D3cold, the device’s _PR3 power resources will, if they are not being used by any other device, be turned off sometime after the transition to D3Cold.

For more information about the power resource requirements for a device that supports D3cold, see Firmware Requirements for D3cold.

Device Power State (_PSx)

There is a Power State method, _PSx, where x = 0, 1, 2, or 3, for each supported device power state Dx. This method is optional, but, if it is present, it is invoked before the power resources for the state are turned off, and after the power resources for the state are turned on. _PSx is intended to perform any platform-specific actions required around the power cycle. _PSx must not access device registers that are assigned to the function driver, access bus-standard registers that are assigned to the bus driver, or switch power resources on or off, which is an operation reserved for Acpi.sys.

Wake capabilities

Power-managed devices might be able to detect events when in a low-power state and cause the platform to wake up to handle them. To enable this feature, Windows needs information about the capabilities of both the platform and the device.

Sx Device Wake State (_SxW)

On a given platform, there is a specific mapping between device states that support the wake capability and system states that can respond to wake events. ACPI defines the _SxW object to provide this information to the operating system. There is an SxW object for each supported system power state, Sx. Because SoC platforms are always in S0, the only object of interest here is _S0W. This object specifies the platform’s ability to wake from a low-power idle state in response to a device’s wake signal. The object is used by Windows to determine the target D-state for the device during system low-power idle. For more information about _S0W, see section 7.2.20, «_S0W (S0 Device Wake State)», in the ACPI 5.0 specification.

For most SoC platforms, devices are aggressively power-managed to the D3 state when idle, and the system is capable of waking from low-power idle while the device is in this state. For such a system, the _S0W object returns 3 (or 4, if it also supports D3cold).

_S0W(4) is a requirement for D3Cold regardless of whether or not the device supports wake.

Any D-state can be designated as the lowest-powered wake-capable state, and some device classes or buses use different values. For instance, SDIO- and USB-connected devices use state D2 for this state.

To facilitate the migration of device drivers from WindowsВ 7 to WindowsВ 8 or WindowsВ 8.1, your device might be required to supply _S4W as well. Currently, the only device class that has this requirement is networking (Ndis.sys).

Wake-capable interrupts (_CRS)

The resource description for a device indicates that the device is capable of detecting and signaling a wake event by marking an interrupt as «wake-capable» (either ExclusiveAndWake or SharedAndWake). Windows and device drivers provide special handling of such interrupts to ensure that they are enabled when the device transitions to a low-power state. For more information, see the descriptions of the Interrupt and GpioInt resource descriptors in section 6.4.3.6, «Extended Interrupt Descriptor», and section 6.4.3.8.1 , «GPIO Connection Descriptors», of the ACPI 5.0 specification.

Wake enablement

Depending on user scenario or system policy, wake-capable devices may or may not actually be armed for wake. Therefore, wake-capable interrupts may or may not be enabled when the device is idle. In addition to enabling interrupts, Windows uses the following mechanisms to enable wake on a device.

Device Sleep Wake (_DSW)

ACPI defines the _DSW object as a way for the operating system to inform the ACPI platform firmware about the next sleep or low-power idle period. This object is optional, and is used only if the platform has a need to configure platform-specific wake hardware in advance. The target D-state for the device and the target S-state for the system are both provided. The D-state and S-state combination will always comply with the information provided by the device’s _SxW object(s).

Power Resources for Wake (_PRW)

In some cases, additional power resources must be turned on for a device to be enabled for wake. In this case, the device can provide the _PRW object to list those additional power resources. The Windows ACPI driver, Acpi.sys, will manage these power resources as it normally does, making sure that they are turned on when they are needed by a device (that is, a wake-enabled device), and are turned off otherwise.

_PRW is also used to define the wake capability for traditional (full-ACPI hardware) PC platforms.

Introduction to Power Management

Microsoft Windows supports a power management architecture that provides a comprehensive approach to system and device power management. This power management architecture is designed to meet ever-increasing user requirements, which include:

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 by pressing a button on the keyboard or monitor.

Customers want to decrease the amount of power and total energy that a PC uses, whether the power comes from an electrical wall outlet or a battery.

To meet these ever-increasing user requirements, Windows must be able to manage the power that is used by any device in the system, including add-in boards such as graphics cards, network adapters, modems, and sound cards. To effectively manage power, the PC software, hardware, and Windows must work together in a framework that enables every device to be power managed in a consistent manner.

A PC configuration that takes full advantage of the Windows power management architecture, provides the following advantages to users:

Energy savings and extended battery life.

Reducing system power consumption results in lower energy costs and longer battery life.

Minimal startup and shutdown delays.

If a working state is not required, the system power state can be changed from the working state to a sleep state and, subsequently, quickly changed back to a working state as required. This allows the system to be responsive to the user, yet energy can be conserved during the time period that a working state is not required.

In many cases the full capabilities of a system might not be required. Powering down devices that are not being used can reduce noise. This capability is important in situations where near-silent operation is highly desirable, such as in Media Center PCs.

In systems that support power management, the computer and its peripheral devices are maintained at the lowest feasible power level to accomplish the tasks at hand. Drivers cooperate with the operating system to manage power for their devices. If all drivers support power management, the operating system can manage power consumption on a system-wide basis, thus conserving power, shutting down and resuming quickly, and waking up when required.

This integrated approach to power management—involving the operating system, system hardware, device drivers, and device hardware—results in the following:

More intelligent power management decisions. At each level, the best-informed component directs power usage.

Greater reliability. Better power management decisions reduce the chance of ill-timed shutdowns and loss of data.

Platform independence. The operating system manages power in a controlled, uniform way across different hardware platforms, allowing maximum conservation of power on various devices.

Better device integration. Device drivers that conform to industry-wide specifications ensure maximum conservation regardless of the hardware platform.

Combined, these advantages result in greater power conservation and more efficient usage than has previously been possible.

The industry-wide OnNow initiative defines the hardware and software requirements for power management. For more information, see Industry Initiatives for Power Management.