--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Adaptation/GUID-73F220EA-F41F-56A5-BAEB-4A37174CFD1F.dita	Fri Oct 15 14:32:18 2010 +0100
@@ -0,0 +1,117 @@
+<?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-73F220EA-F41F-56A5-BAEB-4A37174CFD1F" xml:lang="en"><title>Power
+Management</title><shortdesc>Describes the power management policies. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>The MMC Controller manages the power to the MultiMediaCard hardware.</p>
+<section id="GUID-C54927A1-8631-5DA0-9DDF-C399577B44C0"><title>Normal power
+up and power down handling</title> <p>Before card commands can be issued to
+a card, three operations are required: </p> <ul>
+<li id="GUID-6E4702E7-FAC7-5AFE-BB83-73EAE2774E71"><p>power must be applied
+to the card, i.e. VDD must be turned on </p> </li>
+<li id="GUID-694FED8E-108D-564F-BDDD-078C1F91627D"><p>any requirement from
+the power model must be set, e.g. requesting a necessary system clock </p> </li>
+<li id="GUID-43728A53-CD2B-565A-B436-E3C59B61710E"><p>the clock to the card
+interface must be switched on. </p> </li>
+</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
+machine function which then issues the sequence of commands involved in performing
+the <codeph>CIM_UPDATE_ACQ</codeph> macro to initialize a card stack. </p> <p>There
+are two cases: </p> <ul>
+<li id="GUID-EB3AC768-EF05-5BED-867F-E0C65E2AB43E"><p>Local drive requests,
+i.e. those originating from a media driver - if the card is not fully powered
+up when such a request is received, then the local media device driver automatically
+precedes the request with an instruction to the controller to power up the
+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
+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
+machine function. </p> <p>Once the MultiMediaCard stack has been initialized,
+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
+signal the completion of initialization back to the local media driver, and
+this can then continue to open a media driver and continue with the original
+request. </p> <p>This automatic re-powering of the card applies in all situations
+which can lead to the card not being powered: media change, machine power
+down, card inactivity timeout, VDD power problem etc. In most cases, the process
+of restoring power results in the closure of any existing media driver and
+a new one opened. As the kernel thread used to perform controller requests
+is able to block, this means that no special mechanism is necessary to allow
+for this potential long-running power up sequence prior to a request on the
+device. </p> </li>
+<li id="GUID-D8AA1127-B8B2-52BB-A242-A487A875B908"><p>Requests not originating
+via a local media device driver, for example device drivers for I/O cards
+- if the MultiMediaCard stack is not initialized when the client submits a
+session, then the MultiMediaCard controller automatically precedes the request
+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
+function. </p> </li>
+</ul> <p>The MultiMediaCard controller will normally be configured with an
+inactivity timer. If a given period elapses where there is no bus activity,
+then the controller automatically turns off the card clock, removes any power
+requirements on the power model, and then removes power from the cards. This
+is the bus power down sequence. The length of this inactivity timeout period
+is set in the platform specific layer as part of porting the controller, and
+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
+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
+derived class</xref>. </p> <p>Clients of the controller do not need to worry
+about re-initializing the stack following such a power down as the controller
+does this automatically. </p> <p>In the event of a PSU voltage check failure,
+the controller performs the bus power down sequence. It will not re-power
+the problem card and will expect it to be removed. </p> <p>The power model
+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
+to be normally turned off (due to the off key being pressed or keyboard/touch
+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
+called resulting in the bus power down sequence. </p> <p>When the machine
+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>.
+However, the controller normally does not power up the bus, but waits for
+the next request from one of its clients before doing so. The only exception
+is where a card power up sequence was interrupted by the machine being turned
+off. </p> </section>
+<section id="GUID-BBD2119B-99D6-56A1-B42F-EE2953D88898"><title> Emergency
+power down</title> <p>In an emergency power down situation, for example, where
+a battery is in a critically low power state, the MultiMediaCard controller
+performs the normal bus power down sequence as this is not a lengthy operation.
+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>,
+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,
+there is always a risk that a block being written to a card may become corrupt.
+The solution to this problem lies in the hardware architecture. Two possible
+solutions are: </p> <ul>
+<li id="GUID-02EF5215-2740-5DE9-9418-0BC44ED6051A"><p>to provide enough early
+warning of power being removed before the battery level becomes too low for
+card operation. For example, a catch mechanism on a battery door, making it
+slow to remove. This would provide sufficient time for any write operation
+in progress to be terminated at the next block boundary before the power supply
+is lost. </p> <p>Note, however, that the media driver fails any operations
+involving write operations to a card when the battery level is becoming dangerously
+low, so in general, we are only talking about unexpected battery removal. </p> </li>
+<li id="GUID-FFC11D23-7187-5095-9D18-CF01D85F7A1A"><p>to provide a backup
+battery so that the failing write operation can be re-retried once a good
+battery level has been restored. </p> </li>
+</ul> <p>Even with such mechanisms in place, if power is removed in the middle
+of a multi-block write operation, then some blocks will contain new data while
+others will still contain old data. </p> </section>
+<section id="GUID-8681487C-DD00-58A3-9BFB-8F62A74268C9"><title>Media change</title> <p>When
+a door open event is detected by the MultiMediaCard controller, it attempts
+to remove power from a card as soon as possible. Power is not removed immediately
+if a bus operation is in progress as powering down a card in the middle of
+writing a block could leave the block corrupted. </p> <p>Power is only removed
+from a card immediately a door open event occurs if there are no sessions
+queued by clients on the controller. If one or more sessions are queued then
+these are allowed to complete, with power being removed once the last session
+has completed. Any attempt to engage a new session while the door is open
+fails with <xref href="GUID-51298FCE-7857-39F8-BFAB-49AF5556D0CC.dita"><apiname>KErrNotReady</apiname></xref>. </p> <p>To prevent a card becoming
+corrupt because of attempted removal during a write operation, then it is
+important that the door mechanism and circuitry gives enough early warning
+of a potential card removal before the card is actually removed. This is to
+provide sufficient time for any write operation in progress to proceed to
+the next block boundary before the card is removed. </p> <p>Once the door
+is closed again, then new sessions can be engaged and power can be re-applied
+to the card by the controller. However, power is only restored by the controller
+in response to a client request. The Controller does not automatically re-power
+a card to resume an operation interrupted by a door open event, no matter
+what operation was in progress when the door opened. </p> </section>
+</conbody></concept>
\ No newline at end of file