Adaptation/GUID-2E402D4E-53A9-5BA6-9FBD-B2713DBC7858.dita
author Graeme Price <GRAEME.PRICE@NOKIA.COM>
Fri, 15 Oct 2010 14:32:18 +0100
changeset 15 307f4279f433
permissions -rw-r--r--
Initial contribution of the Adaptation Documentation.

<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-2E402D4E-53A9-5BA6-9FBD-B2713DBC7858" xml:lang="en"><title>Peripheral
Power Domains</title><shortdesc>A 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. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>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 <i>Operational
Power</i> and <i>Off</i> states. </p>
<p>The following diagram is an example of such an arrangement. </p>
<fig id="GUID-A9CA379B-F3B9-550C-9BDC-C072BFCA642D">
<title>Example of peripheral power domains</title>
<image href="GUID-A568F9D3-58E3-58D6-8A6E-4EC6BEC41A4D_d0e29723_href.png" placement="inline"/>
</fig>
<p>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 <i>Off</i> state. </p>
<p>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. </p>
<p>A suggested implementation would have peripheral power domains modelled
by a <xref href="GUID-10105403-AF16-3908-AE9E-96CF2A03AD3A.dita"><apiname>MPowerInput</apiname></xref> reference counted object, and controlled
using the <xref href="GUID-10105403-AF16-3908-AE9E-96CF2A03AD3A.dita#GUID-10105403-AF16-3908-AE9E-96CF2A03AD3A/GUID-2BCA5312-43D9-3763-9636-3B2EB046D2C1"><apiname>MPowerInput::Use()</apiname></xref> and <xref href="GUID-10105403-AF16-3908-AE9E-96CF2A03AD3A.dita#GUID-10105403-AF16-3908-AE9E-96CF2A03AD3A/GUID-606ECD77-A5F7-3408-9B63-C68C0A7B73C6"><apiname>MPowerInput::Release()</apiname></xref> interfaces
that would enable the domain on request. The peripheral driver’s request on
that power resource would only be changed when entering the <i>Operational
Power</i> state from the <i>Off</i> state, or when entering or exiting the <i>Off</i> states.
In other words, a peripheral power domain should only be turned off when all
peripherals in that domain have transitioned to their <i>Off</i> state. </p>
<p>This is a suggested definition for a peripheral power domain class. </p>
<codeblock id="GUID-49E76C4B-F162-5735-8499-3198071111CD" xml:space="preserve">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 
    };
      </codeblock>
<p>The <codeph>Use()</codeph> and <codeph>Release()</codeph> functions implement
a usage count. Peripheral drivers for peripherals on that domain will call
these functions whenever their power handler’s <codeph>PowerUp()</codeph> and <codeph>PowerDown()</codeph> member
functions are called, respectively. If the usage count is 0 and <codeph>Use()</codeph> is
called, it should call <codeph>TurnSupplyOn()</codeph>. If <codeph>Release()</codeph> is
called and the usage count is decremented to 0, <codeph>TurnSupplyOff()</codeph> is
called. </p>
<p>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 <codeph>TurnSupplyOn()</codeph> should
be able to sleep the thread in which this function is called until the power
supply is stable. </p>
<p>We recommend that peripheral power domains are defined as part of, and
accessed through, a resource manager object as suggested in the discussion
of <xref href="GUID-3B6544CD-FA6E-5AB2-AA63-61186F52167D.dita">Controllable Power
Resources</xref>. Extending the original <xref href="GUID-3B6544CD-FA6E-5AB2-AA63-61186F52167D.dita#GUID-3B6544CD-FA6E-5AB2-AA63-61186F52167D/GUID-37A4098A-5E44-5744-BCE1-CDC8B876E654">A
suggested implementation of a resource manager</xref> would give us: </p>
<codeblock id="GUID-F4D57698-C77F-5CD0-BF7B-FCBECD96F64F" xml:space="preserve">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;
    ...
    };
      </codeblock>
<p>where <codeph>InitResources()</codeph> could call each <codeph>PeripheralPowerDomain::InitPowerDomain()</codeph>. </p>
<p>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 <codeph>ReleaseToLevel()</codeph> -type call) the power supply level to
that power domain can be set to VLowPwr. </p>
<p>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: </p>
<fig id="GUID-2C8E6AF1-D82A-5539-96C3-921D9B3E2846">
<title>Base port software architecture diagram</title>
<image href="GUID-C3CE35FF-240E-5385-9088-38EF926ABB7B_d0e29836_href.png" placement="inline"/>
</fig>
</conbody></concept>