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 aren't 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 aren't 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 substates, D3hot and D3cold. The D3hot substate 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's 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's 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 aren't 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's 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's present, it's 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's 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's an SxW object for each supported system power state, Sx. Because SoC platforms are always in S0, the only object of interest here's _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're 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're turned on when they're 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.