1 <?xml version="1.0" encoding="utf-8"?>

     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

     3 <!-- This component and the accompanying materials are made available under the terms of the License 

     4 "Eclipse Public License v1.0" which accompanies this distribution, 

     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

     6 <!-- Initial Contributors:

     7     Nokia Corporation - initial contribution.

     8 Contributors: 

     9 -->

    10 <!DOCTYPE concept

    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

    12 <concept id="GUID-2E402D4E-53A9-5BA6-9FBD-B2713DBC7858" xml:lang="en"><title>Peripheral

    13 Power Domains</title><shortdesc>A peripheral power domain can be defined as being a peripheral,

    14 or group of peripherals, whose power supply can be controlled independently

    15 from the rest of the device, but not independently from other peripherals

    16 within the same power domain. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    17 <p>Power domains depend on the physical wiring of a device, and this must

    18 be taken into account by the base port. They are usually manipulated when

    19 peripherals or groups of peripherals transition between the <i>Operational

    20 Power</i> and <i>Off</i> states. </p>

    21 <p>The following diagram is an example of such an arrangement. </p>

    22 <fig id="GUID-A9CA379B-F3B9-550C-9BDC-C072BFCA642D">

    23 <title>Example of peripheral power domains</title>

    24 <image href="GUID-A568F9D3-58E3-58D6-8A6E-4EC6BEC41A4D_d0e29723_href.png" placement="inline"/>

    25 </fig>

    26 <p>To reduce power leakage, it may be useful to cut the power supply to an

    27 area or a group of peripherals in the ASIC or the hardware platform, when

    28 all peripherals on that peripheral power domain have moved to the <i>Off</i> state. </p>

    29 <p>In the arrangement shown here, when all peripherals on a power domain have

    30 been powered down, the power supply to that domain can be cut off, using the

    31 RESn signal. </p>

    32 <p>A suggested implementation would have peripheral power domains modelled

    33 by a <xref href="GUID-10105403-AF16-3908-AE9E-96CF2A03AD3A.dita"><apiname>MPowerInput</apiname></xref> reference counted object, and controlled

    34 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

    35 that would enable the domain on request. The peripheral driver’s request on

    36 that power resource would only be changed when entering the <i>Operational

    37 Power</i> state from the <i>Off</i> state, or when entering or exiting the <i>Off</i> states.

    38 In other words, a peripheral power domain should only be turned off when all

    39 peripherals in that domain have transitioned to their <i>Off</i> state. </p>

    40 <p>This is a suggested definition for a peripheral power domain class. </p>

    41 <codeblock id="GUID-49E76C4B-F162-5735-8499-3198071111CD" xml:space="preserve">class PeripheralPowerDomain : public MPowerInput

    42     {

    43 public:

    44     void InitPowerDomain();        // (optional) handles any initialisation

    45     void Use();                    // implementation of pure virtual

    46     void Release()                // implementation of pure virtual

    47     TUint GetCount();

    48 private:

    49     TInt TurnSupplyOn();        // re-establishes power supply to this domain (asynch)

    50     TInt TurnSupplyOff();        // cuts power supply to this domain 

    51     };

    52       </codeblock>

    53 <p>The <codeph>Use()</codeph> and <codeph>Release()</codeph> functions implement

    54 a usage count. Peripheral drivers for peripherals on that domain will call

    55 these functions whenever their power handler’s <codeph>PowerUp()</codeph> and <codeph>PowerDown()</codeph> member

    56 functions are called, respectively. If the usage count is 0 and <codeph>Use()</codeph> is

    57 called, it should call <codeph>TurnSupplyOn()</codeph>. If <codeph>Release()</codeph> is

    58 called and the usage count is decremented to 0, <codeph>TurnSupplyOff()</codeph> is

    59 called. </p>

    60 <p>Often, re-establishing the power supply to a power domain is a lengthy

    61 operation and should be modelled by an asynchronous operation. In that case <codeph>TurnSupplyOn()</codeph> should

    62 be able to sleep the thread in which this function is called until the power

    63 supply is stable. </p>

    64 <p>We recommend that peripheral power domains are defined as part of, and

    65 accessed through, a resource manager object as suggested in the discussion

    66 of <xref href="GUID-3B6544CD-FA6E-5AB2-AA63-61186F52167D.dita">Controllable Power

    67 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

    68 suggested implementation of a resource manager</xref> would give us: </p>

    69 <codeblock id="GUID-F4D57698-C77F-5CD0-BF7B-FCBECD96F64F" xml:space="preserve">class ResourceManager

    70     {

    71 public:    

    72     void InitResources();                        // called by your Asic::Init3()/Asic::Init1()

    73     void Modify(TUint aSetMask, TUint aClrMask); // only 32 simple Resources can be managed

    74     TBool GetResourceState(TUint aResBitMask);   // only 1 bit set on this mask, returns On/Off

    75 public:

    76     (MPowerInput-derived) iSharedResource1;      // 1 per shared resource

    77     (MPowerInput-derived) iSharedResource2;

    78     ...

    79     PeripheralPowerDomain iPeripheralPowerDomain1;

    80     PeripheralPowerDomain iPeripheralPowerDomain2;

    81     PeripheralPowerDomain iPeripheralPowerDomain3;

    82     ...

    83     };

    84       </codeblock>

    85 <p>where <codeph>InitResources()</codeph> could call each <codeph>PeripheralPowerDomain::InitPowerDomain()</codeph>. </p>

    86 <p>Peripheral power domains may also be a useful concept when transitioning

    87 peripherals to low power mode after peripheral inactivity detection. It is

    88 only after all peripherals on a peripheral power domain have requested moving

    89 the resource to the level corresponding to low power that the resource level

    90 can be changed. This is exemplified again in the block diagram above: when

    91 all peripherals in a domain have requested transitioning to low power (using

    92 a <codeph>ReleaseToLevel()</codeph> -type call) the power supply level to

    93 that power domain can be set to VLowPwr. </p>

    94 <p>The following base port software architecture diagram could be used to

    95 address control of the peripheral power domains shown in the hardware block

    96 diagram above: </p>

    97 <fig id="GUID-2C8E6AF1-D82A-5539-96C3-921D9B3E2846">

    98 <title>Base port software architecture diagram</title>

    99 <image href="GUID-C3CE35FF-240E-5385-9088-38EF926ABB7B_d0e29836_href.png" placement="inline"/>

   100 </fig>

   101 </conbody></concept>