Power +Management

The kernel-side framework manages the transition between power states on +the device. A base port can implement a kernel extension to interface to the +power management hardware that is provided on the phone. The framework also +provides an interface for device drivers to use the power

The user-side interface to the framework is provided by the Power class +in the User Library. This allows applications can be notified about, and can +react to, changes in power state, and indeed can initiate changes to power +state. The Domain Manager component +provides a way to manage the power needs and dependencies of applications.

In Symbian platform, an initial port of the system does not require the +existence of a power model. In this sense it is optional, and its absence +will result in default behaviour provided by Symbian platform. However, this +is not likely to result in optimal power usage, so the development of a power +model based on the framework provided by Symbian platform will be required +for commercial devices.

The interfaces for power management on the kernel-side are shown in the +following diagram:

+ + + +

The power manager manages +the transition between power states.
The power controller +is a kernel extension that manages the device-specific power management hardware +such as an on-chip power management controller, oscillators etc. The power +controller kernel extension is provided in the base port.
Power handlers are device +drivers that interface to the power manager.

The following sections describes these concepts in more detail.

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

Note: this information applies to Symbian platform before +v9.5. For v9.5 and after, see the Power +Resource Manager documentation.

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.