Customizing Power Manager for SetSystemPowerState()

Changing the system state can be as simple as a cup of tea! by calling SetSystemPowerstate() API. But not all power states can be allowed to set through this API in the default cases. For example setting to “SystemIdle” using this API will be failed.

There are some use cases, we may need to set “systemIdle” through our application/driver or we may need to deny the application/driver to set some power states.  Sometimes, we would like to have our own power state created and it may be allowed to set from the application/driver.  To do this, we have to customize the Windows CE power manager.

Customizing the Power Manager (Windows CE)

• Since PM driver is the public component, it is not advisable to change the public code directly. We have to copy the PM driver from \WINCE600\PUBLIC\COMMON\OAK\DRIVERS\PM to your BSP driver folder and perform sysgen capture on the PM driver.

• All power states codes are available on PM\PDD\DEFAULT\pwstates.cpp. PowerStateOn, PowerStateUserIdle, PowerStateSystemIdle, PowerStateSuspended, PowerStateResuming, PowerStateColdReboot and PowerStateReboot are the power states classes derived from PowerState class of PM\PDD\DEFAULT\pwsdef.cpp and pwsdef.hclass PowerStateUserIdle : public PowerState {public:
  PowerStateUserIdle(PowerStateManager *pPwrStateMgr, PowerState * pNextPowerState = NULL )
  :   PowerState(pPwrStateMgr,pNextPowerState)
  {;  };
  .   /*Remaining power states
  .       code */
  .
  .
  .
  virtual BOOL AppsCanRequestState() { return TRUE; }
  };
  

The above code snippet is the power state class for user idle, derived from PowerState class. Similarly, all power states are having their own classes  as explained above.

Allowing or denying to set the corresponding power state by calling SetSystemPowerState () is evaluated by the “power state manager” through   virtual BOOL AppsCanRequestState () { return TRUE; } function of each power state class. This function is defined as a virtual function in PowerState base class and it can be overridden by the derived power state class based on their needs. Below given figure explains the call flow of SetSystemPowerState () API.

Fig: Call flow of SetSystemPowerStateAPI

• If AppsCanRequestState() is return TRUE, Application/driver can set the corresponding power states through SetSystemPowerState() API. AppsCanRequestState() will return FALSE in the PowerState base class and the derived class will override this function to return TRUE, if they need to set through SetSystemPowerstate() API.

• AppsCanRequestState() function is not overridden by the SystemIdle state. Because of this, calling SetSystemPowerState() with this state as a parameter will not work. If you want to enable, you have to override the AppsCanRequestState() function as explained in the above code snippet.

• If you have your own power state, you have to override the function as explained above to set from application/driver.