Power State Configuration
As illustrated in Figure 3-8, Power Manager associates system power states with device power states to keep system and devices synchronized. Unless configured otherwise, Power Manager enforces the following default system-state-to-device-state mappings: On = D0, UserIdle = D1, SystemIdle = D2, and Suspend = D3. Overriding this association for individual devices and device classes can be accomplished by means of explicit registry settings.
Overriding the Power State Configuration for an Individual Device
The default Power Manager implementation maintains system-state-to-device-state mappings in the registry under the HKEY_LOCAL_MACHINE\System\CurrentControlSet\State key. Each system power state corresponds to a separate subkey and you can create additional subkeys for OEM-specific power states.
Table 3-19 shows a sample configuration for the system power state On. This configuration causes Power Manager to switch all devices, except the backlight driver BLK1: driver, into the D0 device power state. The backlight driver BLK1: can only go to the D2 state.
Table 3-19 Default and driver-specific power state definitions for system power state On
Location | HKEY_LOCAL_MACHINE\System\CurrentControlSet\State\On | ||
---|---|---|---|
Entry | Flags | Default | BKL1: |
Type | REG_DWORD | REG_DWORD | REG_DWORD |
Value | 0x00010000 (POWER_STATE_ON) | 0 (D0) | 2 (D2) |
Description | Identifies the system power state associated with this registry key. For a list of possible flags, see the Pm.h header file in the Public\Common\Sdk\Inc folder. | Sets the power state for drivers by default to the D0 state when the system power state is On. | Sets the backlight driver BLK1: to the D2 state when the system power state is On. |
Overriding the Power State Configuration for Device Classes
Defining device power state for multiple system power states individually can be a tedious task. Power Manager facilitates the configuration by supporting device classes based on IClass values, which can be used to define the power management rules. The following three default class definitions are found under the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\Interfaces registry key.
■ {A3292B7-920C-486b-B0E6-92A702A99B35} Generic power management-enabled devices.
■ {8DD679CE-8AB4-43c8-A14A-EA4963FAA715} Power-management-enabled block devices.
■ {98C5250D-C29A-4985-AE5F-AFE5367E5006} Power-management-enabled Network Driver Interface Specification (NDIS) miniport drivers.
Table 3-20 shows a sample configuration for the NDIS device class, which specifies that NDIS drivers only go as high as the D4 state.
Table 3-20 Sample power state definition for NDIS device class
Location | HKEY_LOCAL_MACHINE\SystemCurrentControlSet\Control\Power\State\On\{98C5250D-C29A-4985-AE5F-AFE5367E5006} |
---|---|
Entry | Default |
Type | REG_DWORD |
Value | 4 (D4) |
Description | Sets the device power state for NDIS drivers to the D4 state when the system power state is On. |
Processor Idle State
In addition to power-management-enabled applications and device drivers, the kernel also contributes to power management. The kernel calls the OEMIdle function, part of the OAL, when no threads are ready to run. This action switches the processor into idle state, which includes saving the current context, placing the memory into a refresh state, and stopping the clock. The processor idle state reduces power consumption to the lowest possible level while retaining the ability to return from the idle state quickly.
It is important to keep in mind that the OEMIdle function does not involve Power Manager. The kernel calls the OEMIdle function directly and it is up to the OAL to switch the hardware into an appropriate idle or sleep state. The kernel passes a DWORD value (dwReschedTime) to OEMIdle to indicate the maximum period of idle time. When this time passes or the maximum delay supported by the hardware timer is reached, the processor switches back to non-idle mode, the previous state is restored, and the scheduler is invoked. If there still is no thread ready to run, the kernel immediately calls OEMIdle again. Driver events, as in the response to user input via keyboard or stylus, may occur at any time and cause the system to stop idling before the system timer starts.
The scheduler is, by default, based on a static timer and system ticks at a one-millisecond frequency. However, the system can optimize power consumption by using dynamic timers and by setting the system timer to the next timeout identified by using the scheduler table content. The processor will then not switch back out of idle mode with every tick. Instead, the processor switches only to non-idle mode after the timeout defined by dwReschedTime expires or an interrupt occurres.
Lesson Summary
Windows Embedded CE 6.0 R2 provides a default Power Manager implementation with a set of power-management APIs that you can use to manage the power state of the system and its devices. It also provides the OEMIdle function, which it executes when the system does not have any threads scheduled in order to provide original equipment manufacturers (OEMs) a chance to put the system into a low power idle state for a specified period of time.
Power Manager is a kernel component that exposes a notification interface, an application interface, and a device interface. It acts as a mediator between kernel and OAL on one side and device drivers and applications on the other side. Applications and device drivers can use the DevicePowerNotify function to control the power state of peripheral devices at five different power levels. Device power states may also associate with default and custom system power states to keep system and devices synchronized. Based on activity times and corresponding events, Power Manger can automatically perform system state transitions. The four default system power states are On, UserIdle, SystemIdle, and Suspend. Customizations for system-state-to- device-state mapping take place in the registry settings of individual devices and device classes.