Self-Management Example (Windows Embedded CE 6.0)
1/6/2010
A device that implements all five power states manages its power dynamically by stepping down from D0 to D1, or D1 to D2, if it has been inactive for some period of time. The device does this in stages because power consumption is lower but the device is also much less responsive in the higher-numbered states. If the device detects activity, and it is not in D0, it attempts to go to D0.
The interrupt service thread of such a device might look like the following code example.
while(!fDone) {
dwStatus = WaitForSingleObject(hInterruptEvent, dwTimeout);
switch(dwStatus) {
case WAIT_OBJECT_0: // device activity
// Service device
if(deviceDx != D0 && !fBoostRequested)
{
fBoostRequested = TRUE;
DevicePowerNotify(pszDeviceName, D0, POWER_DRIVER | POWER_NAME);
}
dwTimeout = INACTIVITY_TIMEOUT;
break;
case WAIT_TIMEOUT: // device inactive
if(deviceDx < D2 && !fReductionRequested)
{
fReductionRequested = TRUE;
DevicePowerNotify(pszDeviceName, deviceDx + 1, POWER_DRIVER | POWER_NAME);
}
if(deviceDx >= D2)
{
dwTimeout = INFINITE;
}
default:
// error handling
break;
}
}
The DeviceIoControl routine of the device might include the following code example.
case IOCTL_POWER_SET:
// update device registers
deviceDx = *(PCEDEVICE_POWER_STATE) pOutBuf;
fBoostRequested = FALSE;
fReductionRequested = FALSE;
break;
The driver code keeps track only of whether it has requested a state transition, not whether the transition has occurred. This is important because the device might request D0 while at D2, but Power Manager might set it to D1 because of the current power state. On the next device activity, the device would request D0 again, and Power Manager might leave it at D1. Keeping track of the fact that it requested a state transition would prevent further unnecessary Power Manager function calls while the device is active. The same logic applies to power state reductions due to inactivity timeouts.
The interrupt service thread (IST) of the device sets the fBoostRequested and fReductionRequested flags before calling DevicePowerNotify because the DevicePowerNotify invocation may result in an IOCTL_POWER_SET call into the driver on the same thread. The DeviceIoControl call clears the flags, enabling the driver to make further adjustments to the device power state in the future.