Exploring Windows Embedded CE 6.0 Power Management

Power management initialization process has been done in the pminit() function of pminit.cpp file.

Plug and Play device management plays the role of maintaining the list of devices enrolled under the power management device classes. This process is done by the PnPThreadProc thread.  This thread waits for the notification sent from the device driver belongs to the power management device classes, add or remove the devices from the device list maintained by the power manager..

Power manager maintaining the device in the form of device classes and each device class is having the unique GUID.  There are four types of power management device classes currently supported by the Windows CE 6.0.

Generic Devices:

All streaming devices are come under this class. (Ex) serial port driver (com1)

NDIS Miniport Devices:

All Network devices are come under this class. (Ex) Ethernet.

Block Devices:

Block devices like PCMCIA CF cards are example for this class.

Display Devices:

Display devices, overlay devices are come under this class.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\Timeouts]

"ACSuspend"=dword:0                 ; in seconds

Setting the “ACSuspend = 0” avoid the suspend state automatically through the power state transitions when the system Idle timeout is happened. A system suspend/resume event occurs when PowerOffSystem() is called, device drivers are notified via PowerUp()/PowerDown() entry points, and OEMPowerOff() is invoked.  However this PowerOffSystem() and SetSystemPowerOff() are done through the “DefaultPowerStateManager”. This SetSystemPowerOff() will call “PmSetSystemPowerState_I()” function, this will call “DefaultPowerStateManager” functions to maintain the control. So this APIs won’t create chaos in the power state machine. “DefaultPowerStateManager” will be explained in the upcoming sections.

During the resume process "ResumeThreadProc "is responsible for determining why the system woke up and initiating the appropriate system power state transition and restart the activity timers.

For example consider the class PowerStateUserIdle. This power state class handles the two activity events.

In the normal case, switching directly to System Idle state using the SetSystemPowerState() API is not allowed. In some cases we may need to do this through our application. For example your requirement is only to shutdown the GWES but not to enter the suspend state and this may be controlled through your application instead of through the automatic state transitions. In this case there is no direct support in the power manager. So the power manager driver is needed to be customized for our requirement. Let us see the implementation of switching directly to user idle state.

SetSystemPowerState() API will call the PmSetSystemPowerState_I() function in the pmsysstate.cpp file. This function will call the DefaultPowerStateManager's PlatformMapPowerStateHint() function in the pwsdef.cpp file to get the current power state, but in this function this current power state is checked for the eligibility to allow an application to change the state through the AppsCanRequestState() function. For the default case of system idle this function is not implemented for the PowerStateSystemIdle class. In the base PowerState class this function is implemented as follows,

Changing the User Idle and System Idle Timeout through the application can be achieved by simple changing the following registry settings through the registry functions.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\Timeouts]

1.  Each power state is represented as class in pwstates.cpp, add your new power state by creating a new class structure.

Example: I have created PowerStateUsbCharge class.

2. Implement a virtual function "EnterState"; this function will be getting called before the system enters the power state corresponds to this class.

3. Add an Activity state for the new power state in PLATFORM_ACTIVITY_STATE enum in pwstates.cpp

Example: I have added "Usbcharge" state for my new power state

4. Implement GetState( ) and GetStateString( ) functions with corresponding return value in the new power state class.

Example: GetState function returns the "Usbcharge" enum value.
GetStateString returns the name of the current power state in wide char.

6. Implement WaitForEvent function to wait for the required events for switching to next power state.

7. After implementing all the required functions we need to add this power state class to the power state list, this can be done by modifying PowerStateManager::CreatePowerStateList function in pwstates.cpp.

Example: I have added PowerStateUsbCharge class to the power state list.

10. For adding the event to event array, increment PM_BASE_TOTAL_EVENT in pwsdef.h by 1 for accompanying the new event and add a definition for this new event.

Example: #define PM_USBCHARGE_EVENT 8

11. In pwstates.cpp GetEventHandle( ) function add a case for the new event created in pminit.cpp.

12. In PowerState Class constructor add a call to GetEventHandle with index as PM_USBCHARGE_EVENT to get the event handle.

14. In WaitforEvent ( ) function of PowerState Class (pwsdef.cpp) add a new case for the custom event, and return the PLATFORM _EVENT specific to the new power state.

Example: In this case I am mapping the event to PowerSourceChange platform event.

15. Now add a new case in WaitforEvent function (in all the required power state class) to handle our new state.

Example: We are assigning the next state as "Usbcharge" based on the activity event.

Note: Here "usbcharge" is the string returned by the GetStateString function of PowerStateUsbCharge

Above registry setting sets the USB host device to D3 state when in usbcharge mode is entered.