<?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>