Symbian3/PDK/Source/GUID-73F220EA-F41F-56A5-BAEB-4A37174CFD1F.dita
changeset 1 25a17d01db0c
child 3 46218c8b8afa
equal deleted inserted replaced
0:89d6a7a84779 1:25a17d01db0c
       
     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-73F220EA-F41F-56A5-BAEB-4A37174CFD1F" xml:lang="en"><title>Power
       
    13 Management</title><shortdesc>Describes the power management policies. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
       
    14 <p>The MMC Controller manages the power to the MultiMediaCard hardware. </p>
       
    15 <section id="GUID-C54927A1-8631-5DA0-9DDF-C399577B44C0"><title>Normal power
       
    16 up and power down handling</title> <p>Before card commands can be issued to
       
    17 a card, three operations are required: </p> <ul>
       
    18 <li id="GUID-6E4702E7-FAC7-5AFE-BB83-73EAE2774E71"><p>power must be applied
       
    19 to the card, i.e. VDD must be turned on </p> </li>
       
    20 <li id="GUID-694FED8E-108D-564F-BDDD-078C1F91627D"><p>any requirement from
       
    21 the power model must be set, e.g. requesting a necessary system clock </p> </li>
       
    22 <li id="GUID-43728A53-CD2B-565A-B436-E3C59B61710E"><p>the clock to the card
       
    23 interface must be switched on. </p> </li>
       
    24 </ul> <p>All three operations are performed as part of the <xref href="GUID-B5193656-9819-3E00-A335-EEF1726115A5.dita#GUID-B5193656-9819-3E00-A335-EEF1726115A5/GUID-D8D3CFDC-5292-3853-8618-5D3A21F5C4D7"><apiname>DMMCStack::CIMInitStackSM()</apiname></xref> state
       
    25 machine function which then issues the sequence of commands involved in performing
       
    26 the CIM_UPDATE_ACQ macro to initialise a card stack. </p> <p>There are two
       
    27 cases: </p> <ul>
       
    28 <li id="GUID-EB3AC768-EF05-5BED-867F-E0C65E2AB43E"><p>Local drive requests,
       
    29 i.e. those originating from a media driver - if the card is not fully powered
       
    30 up when such a request is received, then the local media device driver automatically
       
    31 precedes the request with an instruction to the controller to power up the
       
    32 card. This results in <xref href="GUID-45B97680-1756-3559-8A2D-2F2E851AD6A7.dita#GUID-45B97680-1756-3559-8A2D-2F2E851AD6A7/GUID-C0E6CF87-8E8B-3B14-9B7E-302E3688CFA5"><apiname>DMMCSocket::InitiatePowerUpSequence()</apiname></xref> being
       
    33 called, which in turn invokes the <xref href="GUID-B5193656-9819-3E00-A335-EEF1726115A5.dita#GUID-B5193656-9819-3E00-A335-EEF1726115A5/GUID-D8D3CFDC-5292-3853-8618-5D3A21F5C4D7"><apiname>DMMCStack::CIMInitStackSM()</apiname></xref> state
       
    34 machine function. </p> <p>Once the MultiMediaCard stack has been initialised,
       
    35 the MultiMediaCard controller calls <xref href="GUID-C988CAE6-9073-3851-A0B0-5479D1A34CFB.dita#GUID-C988CAE6-9073-3851-A0B0-5479D1A34CFB/GUID-0FEFB701-D37A-320F-A49B-6126EF608BF7"><apiname>DPBusSocket::PowerUpSequenceComplete()</apiname></xref> to
       
    36 signal the completion of initialisation back to the local media driver, and
       
    37 this can then continue to open a media driver and continue with the original
       
    38 request. </p> <p>This automatic re-powering of the card applies in all situations
       
    39 which can lead to the card not being powered: media change, machine power
       
    40 down, card inactivity timeout, VDD power problem etc. In most cases, the process
       
    41 of restoring power results in the closure of any existing media driver and
       
    42 a new one opened. As the kernel thread used to perform controller requests
       
    43 is able to block, this means that no special mechanism is necessary to allow
       
    44 for this potential long-running power up sequence prior to a request on the
       
    45 device. </p> </li>
       
    46 <li id="GUID-D8AA1127-B8B2-52BB-A242-A487A875B908"><p>Requests not originating
       
    47 via a local media device driver, for example device drivers for I/O cards
       
    48 - if the MultiMediaCard stack is not initialised when the client submits a
       
    49 session, then the MultiMediaCard controller automatically precedes the request
       
    50 with a call to the <xref href="GUID-B5193656-9819-3E00-A335-EEF1726115A5.dita#GUID-B5193656-9819-3E00-A335-EEF1726115A5/GUID-D8D3CFDC-5292-3853-8618-5D3A21F5C4D7"><apiname>DMMCStack::CIMInitStackSM()</apiname></xref> state machine
       
    51 function. </p> </li>
       
    52 </ul> <p>The MultiMediaCard controller will normally be configured with an
       
    53 inactivity timer. If a given period elapses where there is no bus activity,
       
    54 then the controller automatically turns off the card clock, removes any power
       
    55 requirements on the power model, and then removes power from the cards. This
       
    56 is the bus power down sequence. The length of this inactivity timeout period
       
    57 is set in the platform specific layer as part of porting the controller, and
       
    58 can be disabled completely if required; see the reference to porting the <xref href="GUID-E55B4FE5-517C-5A23-8ACA-E28EE202330B.dita#GUID-E55B4FE5-517C-5A23-8ACA-E28EE202330B/GUID-99529E84-17E1-5F23-9A1B-EBE3976D9B14">PsuInfo()</xref> function
       
    59 as part of implementing the <xref href="GUID-E55B4FE5-517C-5A23-8ACA-E28EE202330B.dita#GUID-E55B4FE5-517C-5A23-8ACA-E28EE202330B/GUID-3A1E907E-A74D-59CB-A1D6-FEF4849EF2D5">DMMCPsu
       
    60 derived class</xref>. </p> <p>Clients of the controller do not need to worry
       
    61 about re-initialising the stack following such a power down as the controller
       
    62 does this automatically. </p> <p>In the event of a PSU voltage check failure,
       
    63 the controller performs the bus power down sequence. It will not re-power
       
    64 the problem card and will expect it to be removed. </p> <p>The power model
       
    65 calls <xref href="GUID-C988CAE6-9073-3851-A0B0-5479D1A34CFB.dita#GUID-C988CAE6-9073-3851-A0B0-5479D1A34CFB/GUID-F037A26D-0C72-364F-B3CD-87B9FF22AAB1"><apiname>DPBusSocket::DoPowerDown()</apiname></xref> when the machine is about
       
    66 to be normally turned off (due to the off key being pressed or keyboard/touch
       
    67 screen inactivity). This leads to the function <xref href="GUID-B5193656-9819-3E00-A335-EEF1726115A5.dita#GUID-B5193656-9819-3E00-A335-EEF1726115A5/GUID-CF271B2B-A515-3DB7-AD52-8138BAFF901C"><apiname>DMMCStack::PowerDownStack()</apiname></xref> being
       
    68 called resulting in the bus power down sequence. </p> <p>When the machine
       
    69 is powered back up after a normal power off, the power model calls <xref href="GUID-C988CAE6-9073-3851-A0B0-5479D1A34CFB.dita#GUID-C988CAE6-9073-3851-A0B0-5479D1A34CFB/GUID-C4EC4C74-24CE-3A55-B63F-30E32DB0259A"><apiname>DPBusSocket::DoPowerUp()</apiname></xref>.
       
    70 However, the controller normally does not power up the bus, but waits for
       
    71 the next request from one of its clients before doing so. The only exception
       
    72 is where a card power up sequence was interrupted by the machine being turned
       
    73 off. </p> </section>
       
    74 <section id="GUID-BBD2119B-99D6-56A1-B42F-EE2953D88898"><title> Emergency
       
    75 power down</title> <p>In an emergency power down situation, for example, where
       
    76 a battery is in a critically low power state, the MultiMediaCard controller
       
    77 performs the normal bus power down sequence as this is not a lengthy operation.
       
    78 The power model calls <xref href="GUID-C988CAE6-9073-3851-A0B0-5479D1A34CFB.dita#GUID-C988CAE6-9073-3851-A0B0-5479D1A34CFB/GUID-A893EB7B-289E-36DB-B249-CA8DB81EEAE2"><apiname>DPBusSocket::DoEmergencyPowerDown()</apiname></xref>,
       
    79 which results in a call to <xref href="GUID-B5193656-9819-3E00-A335-EEF1726115A5.dita#GUID-B5193656-9819-3E00-A335-EEF1726115A5/GUID-CF271B2B-A515-3DB7-AD52-8138BAFF901C"><apiname>DMMCStack::PowerDownStack()</apiname></xref>. </p> <p>However,
       
    80 there is always a risk that a block being written to a card may become corrupt.
       
    81 The solution to this problem lies in the hardware architecture. Two possible
       
    82 solutions are: </p> <ul>
       
    83 <li id="GUID-02EF5215-2740-5DE9-9418-0BC44ED6051A"><p>to provide enough early
       
    84 warning of power being removed before the battery level becomes too low for
       
    85 card operation. For example, a catch mechanism on a battery door, making it
       
    86 slow to remove. This would provide sufficient time for any write operation
       
    87 in progress to be terminated at the next block boundary before the power supply
       
    88 is lost. </p> <p>Note, however, that the media driver fails any operations
       
    89 involving write operations to a card when the battery level is becoming dangerously
       
    90 low, so in general, we are only talking about unexpected battery removal. </p> </li>
       
    91 <li id="GUID-FFC11D23-7187-5095-9D18-CF01D85F7A1A"><p>to provide a backup
       
    92 battery so that the failing write operation can be re-retried once a good
       
    93 battery level has been restored. </p> </li>
       
    94 </ul> <p>Even with such mechanisms in place, if power is removed in the middle
       
    95 of a multi-block write operation, then some blocks will contain new data while
       
    96 others will still contain old data. </p> </section>
       
    97 <section id="GUID-8681487C-DD00-58A3-9BFB-8F62A74268C9"><title>Media change</title> <p>When
       
    98 a door open event is detected by the MultiMediaCard controller, it attempts
       
    99 to remove power from a card as soon as possible. Power is not removed immediately
       
   100 if a bus operation is in progress as powering down a card in the middle of
       
   101 writing a block could leave the block corrupted. </p> <p>Power is only removed
       
   102 from a card immediately a door open event occurs if there are no sessions
       
   103 queued by clients on the controller. If one or more sessions are queued then
       
   104 these are allowed to complete, with power being removed once the last session
       
   105 has completed. Any attempt to engage a new session while the door is open
       
   106 fails with <xref href="GUID-51298FCE-7857-39F8-BFAB-49AF5556D0CC.dita"><apiname>KErrNotReady</apiname></xref>. </p> <p>To prevent a card becoming
       
   107 corrupt because of attempted removal during a write operation, then it is
       
   108 important that the door mechanism and circuitry gives enough early warning
       
   109 of a potential card removal before the card is actually removed. This is to
       
   110 provide sufficient time for any write operation in progress to proceed to
       
   111 the next block boundary before the card is removed. </p> <p>Once the door
       
   112 is closed again, then new sessions can be engaged and power can be re-applied
       
   113 to the card by the controller. However, power is only restored by the controller
       
   114 in response to a client request. The Controller does not automatically re-power
       
   115 a card to resume an operation interrupted by a door open event, no matter
       
   116 what operation was in progress when the door opened. </p> </section>
       
   117 </conbody></concept>