Additional -System Wide Power States

The Kernel defines three system wide power states. A base port can add -new power states to improve power management for phone hardware.

The generic system wide power states that are defined are Active, Standby and Off. -Any additional sub-states of the Active power state must be wholly -managed by the base port. These states may not need to be declared explicitly -and may result from peripherals, or groups of peripherals, having moved to -their low power state (see also moving -to their low power state). The device will then “trickle“ into one -of these sub-states instead of transitioning into them as a result of a user -action or system policy decision.

Usually, the transition of the system into one of the additional low power -states happens when the CPU enters the idle mode. The transition may be automatic -and wholly managed by the ASSP hardware or may result from an action taken -by the software routine that prepares the CPU to go to idle mode.

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:

-System power use over time - -

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.