Additional System Wide Power States

Sleeping in idle mode

An example of this is when the base port uses the idle mode to put the CPU and the device into hardware “Sleep” mode similar to that which can be achieved with a transition to Standby mode as described in the implementation issues for implementing DPowerController::PowerDown()

When called, the power controller’s DPowerController::CpuIdle() implementation could take the necessary steps to prepare the CPU and the platform to go to “Sleep”.

There is a balance between the power savings obtained from moving the CPU and platform into “Sleep” mode in Idle and the performance hit resulting from spending time restoring the status after coming out of “Sleep” mode. Usually the CpuIdle() routine investigates the timer queue (using NTimerQ::IdleTime()) for the next timer expiration and decides to move or not to move the CPU and platform into “Sleep” mode based on how much time there is before the next timer expiration. The threshold above which it is considered productive to move into “Sleep” is dependent on the base port.

The decision to move into “Sleep” mode may also be based on the current level of activity, or collected metrics on the length of time spent in Idle, or other historical information. This can be implemented entirely by the base port, or it may require the services of an external component (such as, for example, Speed Management).

The transition to a hardware “Sleep” mode may also depend on shared peripherals being in a particular state, for example, no pending requests from other peripherals. This means that the power controller may need to check with the peripheral driver before initiating the change. The power controller could use the ASSP/Variant method to access the resource manager and check the usage of a shared peripheral using its GetCount() API.

The decision to move into “Sleep” mode could be dependent on a number of peripherals (shared and not shared) being in Standby and a number of controllable power resources being turned off. Therefore the power controller may also need to check with the resource manager (through the Variant or ASSP) for the state of a specific set of controllable power resources (using the ResourceManager::GetResourceState() API).

On going to “Sleep”, an action or set of actions might need to be taken that would affect the whole platform. An example of this is when DRAM is put into self-refresh mode on entering the CPU Idle mode after all peripherals that might access it (including the LCD controller and DSP) are in low power state. Unused DRAM banks may also be powered down.

The following diagram exemplifies how the evolution of system power would look like on a system when the most power saving “Sleep” mode can only be reached – from Idle - when Peripherals A, B and C are already in their low power mode. On going to the most power saving “Sleep” mode, additional actions can be taken to lower the system power level:

• The system is active when a request for service is made on peripheral A; the peripheral driver for peripheral A requests its transition to operational state increasing the system power requirement (a).

• After a period of activity related to servicing the request, the system enters the idle thread; in CpuIdle() the time for the next timer expiration is investigated and is found to be long enough to send the system to sleep, powering down peripherals A, B and C to their low power state and other system resources (b).

• The timer expires and the system wakes up to the same power level as before (c).

• The inactivity timer implemented in the peripheral driver for peripheral A expires: the peripheral is transitioned to the low power state (d).

• At (e) the system enters the idle thread again: the timer queue is investigated and then enters sleep mode, waking up again when an interrupt occurs (f).

• The inactivity timer associated with the peripheral drive for peripheral B expires and the peripheral is transitioned to its low power state (g).

• On the next call to CpuIdle() the time for the next timer expiration is not long enough to power off peripherals and other system resources: only limited power savings can be made (h) until the system wakes up again (i).

• Finally, the inactivity timer for peripheral C expires and the peripheral is transitioned to low power state (j). On reaching another period of system idle all conditions are met to send the system to the deepest sleep mode available accompanied by the switching off other power resources (k).

• On waking up (l) the system resources are restored to the same power level as before.

Any transition to and from these low power states must be transparent to the rest of the system. A transparent transition is one that can be instantly reversed, perhaps automatically in hardware, and has no noticeable impact on system performance. In other words, it should be possible to wake the processor up and move the entire device to Active Mode as if coming from a “normal” Idle Mode.

To perform a system wide power change which is not transparent, peripherals that may be affected by the transition would need to be examined, and interfaces would have to be provided so that the users of these peripherals could query the peripheral and allow or disallow the system transition into that state.