Peripheral +Power Domains

diff -r 578be2adaf3e -r 307f4279f433 Adaptation/GUID-2E402D4E-53A9-5BA6-9FBD-B2713DBC7858.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Adaptation/GUID-2E402D4E-53A9-5BA6-9FBD-B2713DBC7858.dita Fri Oct 15 14:32:18 2010 +0100 @@ -0,0 +1,101 @@ + + + + + +Peripheral +Power DomainsA peripheral power domain can be defined as being a peripheral, +or group of peripherals, whose power supply can be controlled independently +from the rest of the device, but not independently from other peripherals +within the same power domain. +

Power domains depend on the physical wiring of a device, and this must +be taken into account by the base port. They are usually manipulated when +peripherals or groups of peripherals transition between the Operational +Power and Off states.

The following diagram is an example of such an arrangement.

+ +Example of peripheral power domains + + +

To reduce power leakage, it may be useful to cut the power supply to an +area or a group of peripherals in the ASIC or the hardware platform, when +all peripherals on that peripheral power domain have moved to the Off state.

In the arrangement shown here, when all peripherals on a power domain have +been powered down, the power supply to that domain can be cut off, using the +RESn signal.

A suggested implementation would have peripheral power domains modelled +by a MPowerInput reference counted object, and controlled +using the MPowerInput::Use() and MPowerInput::Release() interfaces +that would enable the domain on request. The peripheral driver’s request on +that power resource would only be changed when entering the Operational +Power state from the Off state, or when entering or exiting the Off states. +In other words, a peripheral power domain should only be turned off when all +peripherals in that domain have transitioned to their Off state.

This is a suggested definition for a peripheral power domain class.

+class PeripheralPowerDomain : public MPowerInput + { +public: + void InitPowerDomain(); // (optional) handles any initialisation + void Use(); // implementation of pure virtual + void Release() // implementation of pure virtual + TUint GetCount(); +private: + TInt TurnSupplyOn(); // re-establishes power supply to this domain (asynch) + TInt TurnSupplyOff(); // cuts power supply to this domain + }; + +

The Use() and Release() functions implement +a usage count. Peripheral drivers for peripherals on that domain will call +these functions whenever their power handler’s PowerUp() and PowerDown() member +functions are called, respectively. If the usage count is 0 and Use() is +called, it should call TurnSupplyOn(). If Release() is +called and the usage count is decremented to 0, TurnSupplyOff() is +called.

Often, re-establishing the power supply to a power domain is a lengthy +operation and should be modelled by an asynchronous operation. In that case TurnSupplyOn() should +be able to sleep the thread in which this function is called until the power +supply is stable.

We recommend that peripheral power domains are defined as part of, and +accessed through, a resource manager object as suggested in the discussion +of Controllable Power +Resources. Extending the original A +suggested implementation of a resource manager would give us:

+class ResourceManager + { +public: + void InitResources(); // called by your Asic::Init3()/Asic::Init1() + void Modify(TUint aSetMask, TUint aClrMask); // only 32 simple Resources can be managed + TBool GetResourceState(TUint aResBitMask); // only 1 bit set on this mask, returns On/Off +public: + (MPowerInput-derived) iSharedResource1; // 1 per shared resource + (MPowerInput-derived) iSharedResource2; + ... + PeripheralPowerDomain iPeripheralPowerDomain1; + PeripheralPowerDomain iPeripheralPowerDomain2; + PeripheralPowerDomain iPeripheralPowerDomain3; + ... + }; + +

where InitResources() could call each PeripheralPowerDomain::InitPowerDomain().

Peripheral power domains may also be a useful concept when transitioning +peripherals to low power mode after peripheral inactivity detection. It is +only after all peripherals on a peripheral power domain have requested moving +the resource to the level corresponding to low power that the resource level +can be changed. This is exemplified again in the block diagram above: when +all peripherals in a domain have requested transitioning to low power (using +a ReleaseToLevel() -type call) the power supply level to +that power domain can be set to VLowPwr.

The following base port software architecture diagram could be used to +address control of the peripheral power domains shown in the hardware block +diagram above:

+ +Base port software architecture diagram + + + \ No newline at end of file