Power -Management

Power -ManagementThe Kernel provides a framework for managing power within the system, -and the management of the transition between power states. -

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.

-Domain Manager - -Power Management - Tutorials -Power Resource -Manager (PRM) + + + + + +Power +ManagementThe Kernel provides a framework for managing power within the system, +and the management of the transition between power states. +

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.

+Domain Manager + +Power Management + Tutorials +Power Resource +Manager (PRM)

\ No newline at end of file