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:

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

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.

- +

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.

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.

-Domain Manager - -Power Management - Tutorials -Power Resource -Manager (PRM) +Domain +Manager +Power +Management Tutorials +Power +Resource Manager (PRM) \ No newline at end of file