Power +Management

The MMC Controller manages the power to the MultiMediaCard hardware.

Normal power +up and power down handling

Before card commands can be issued to +a card, three operations are required:

power must be applied +to the card, i.e. VDD must be turned on
any requirement from +the power model must be set, e.g. requesting a necessary system clock
the clock to the card +interface must be switched on.

All three operations are performed as part of the DMMCStack::CIMInitStackSM() state +machine function which then issues the sequence of commands involved in performing +the CIM_UPDATE_ACQ macro to initialize a card stack.

There +are two cases:

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 DMMCSocket::InitiatePowerUpSequence() being +called, which in turn invokes the DMMCStack::CIMInitStackSM() state +machine function.

Once the MultiMediaCard stack has been initialized, +the MultiMediaCard controller calls DPBusSocket::PowerUpSequenceComplete() 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.

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.
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 DMMCStack::CIMInitStackSM() state machine +function.

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 PsuInfo() function +as part of implementing the DMMCPsu +derived class.

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.

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.

The power model +calls DPBusSocket::DoPowerDown() 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 DMMCStack::PowerDownStack() being +called resulting in the bus power down sequence.

When the machine +is powered back up after a normal power off, the power model calls DPBusSocket::DoPowerUp(). +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.

Emergency +power down

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 DPBusSocket::DoEmergencyPowerDown(), +which results in a call to DMMCStack::PowerDownStack().

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:

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.

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.
to provide a backup +battery so that the failing write operation can be re-retried once a good +battery level has been restored.

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.

Media change

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.

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 KErrNotReady.

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.

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.