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