Power Management

Power manager

The power manager manages the transition between power states. It co-ordinates the change in the power state of peripherals and the CPU (hardware), and provides the necessary interactions with the device (peripheral) drivers and the power controller (software). It also manages interactions with the user-side model.

The power manager is an instance of the DPowerManager class, an object that is private to Symbian platform. This object is created when the system is initialised, but is not installed as the power manager until the power controller has been created and registered. Until the DPowerManager object is installed as the system's power manager, Symbian platform manages power using built-in default behaviour.

The user-side uses the Power class, a set of static functions, as an interface to the power manager. This allows the user side to request a transition to the Standby or Off state, and to request notification of wake-up events, i.e. events that will cause a transition back to the Active state.

The power manager object is the anchor point for the power controller object and the power handler objects.

Power controller

The power controller manages the device-specific power management hardware such as an on-chip power management controller, oscillators etc.

The power controller is an instance of a DPowerController class. This is an abstract class that requires an implementation . A concrete implementation supports power management hardware that is Variant specific. Typically, the Variant creates a power controller object when the Variant is initialised, and then registers it with the power manager through a call to DPowerController::Register(). Registration puts a pointer to the DPowerController object into the Symbian platform internal DPowerManager object.

The power controller is responsible for tracking wake-up events, notifying the power manager of such events through a call to DPowerController::WakeUpEvent().

Power handlers

Device drivers interface to the power manager through the DPowerHandler class. This is an abstract class that requires a concrete implementation by device (peripheral) drivers.

How a DPowerHandler object fits into a driver's own object model is a matter of individual device driver design. However, after construction of this object, the driver is expected to register it with the power manager by calling DPowerHandler::Add(), after which it will receive notification of changes to the power state.

The power manager calls DPowerHandler::PowerDown() when it requests a power state transition to either the Off or the Standby state. The power manager calls DPowerHandler::PowerUp() when it requests a power state transition to the Active state. The driver must respond to a power transition notification after it has dealt with it by calling DPowerHandler::PowerUpDone() or DPowerHandler::PowerDownDone() as appropriate.

Shared power sources

The set of power sources on a device, how they are connected to peripherals, and their power states are totally dependent on the specific device. This means that Symbian platform cannot provide a comprehensive API for handling such sources.

However, Symbian platform does provide an interface, MPowerInput, through which drivers register their use of a power source and their release of that power source. Symbian platform makes the following recommendations:

• Each (shared) power source is represented by a separate object.

• The class, or class hierarchy, that represents the power source should implement the MPowerInput interface so that device (peripheral) drivers can register their use or their release of that power source.

• Define a custom interface with the power controller. It is likely that the Variant will be responsible for providing the implementation for the power inputs, and for providing this custom interface.

Drivers that need power from a specific power source call MPowerInput::Use() on the object that represents that power source. To release dependence on that power source, the driver calls MPowerInput::Release().

To represent a shared power source, a suggested implementation of MPowerInput might be to associate a counting value with the power source object. A call to Use() would increment the counter, while a call to Release() would decrement it. On construction of the object, the initial value might be 0, indicating that no peripherals require power from this source. A value of 1 or higher would indicate that one or more peripherals require power from this source. The implementation would, therefore, cause this power source to be kept on while at least one peripheral needs it; the power source would only be switched off when no peripherals need power from it.