|
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 <codeph>CIM_UPDATE_ACQ</codeph> macro to initialize a card stack. </p> <p>There |
|
27 are two 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 initialized, |
|
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 initialization 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 initialized 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-initializing 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> |