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

See the Power Resource Manager documentation for more information.

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.