MMC Controller Architecture

Introduction

The MultiMediaCard media driver defines and implements the standard media driver interface derived from DMediaDriver. This is the client of the MultiMediaCard controller.

Requests to the controller can also come from other device drivers. This means that the architectural picture can be extended as shown below:

The controller currently supports a single stack capable of holding up to 4 cards. In a future development, it may become capable of supporting more than 1 stack. Note however, that Symbian platform allows more than one peripheral bus controller.

The controller can handle multiple requests outstanding simultaneously, i.e. multiple drivers each with a session engaged (a session is a unit of work for the MMC stack). Internally, it schedules these requests onto the bus, automatically putting the appropriate card into the transfer state etc.

A platform containing a card socket is expected to provide a means of detecting when a card is inserted or removed from the stack (e.g. a media door interrupt). The controller does not attempt to initialize and identify newly inserted cards immediately. Instead, cards remain unidentified until they are interrogated by a client.

For hardware interfaces that allow multiple cards in a single stack, the MultiMediaCard system supplies no means of identifying a particular socket position within the stack. As cards are inserted and removed, the potential exists for those cards which remain to be allocated different card numbers (and ultimately a different drive letter than that allocated previously) once the stack is re-initialized. To avoid this, the controller maintains a fixed card number for a given card for as long as it remains in the Symbian platform device (by storing the CID of each card present). This means that a card will have a constant drive letter for as long it remains in the Symbian platform device. However, if a card is removed, and then subsequently re-inserted into exactly the same slot in the stack, then there is no guarantee that it will be allocated the same card number, and therefore, no guarantee that it will have the same drive letter as before.

Class architecture

The following diagram gives a more detailed view of the MultiMediaCard controller in terms of the socket, stack, session, power supply and media change objects.

The socket

The Symbian platform implementation of MultiMediaCard uses the idea of a socket. A socket corresponds to a physical device on a given peripheral bus.

In general, a socket is associated with its own thread. However, although each card in a MultiMediaCard stack has its own individual slot, the bus architecture prevents more than one card from being accessed at any one time. Further, all cards in a stack must be powered up at the same time. All this suggests that having a separate thread for each card in a multi-card slot would not offer much benefit, and indeed would probably lead to conflicting hardware accesses between the threads. This means that a single socket object is allocated to represent for all cards in MultiMediaCard stack.

The socket is the highest level object in the MultiMediaCard controller, and is an instance of a DMMCSocket class. It oversees the power supply functionality, the media change functionality, and the object that controls access to the card stack.

You can define and implement a derived class in the variant DLL, epbusmv.dll, although it may rarely be necessary.

The stack

Access to the card stack is handled by an instance of a DMMCStack class, and is owned by the socket. The DMMCStack class is designed to implement the set of "macros" defined by the MultiMediaCard Association. These "macros" are a predefined set of command sequences that perform complex bus operations.

You will normally define and implement a derived class in the variant DLL, epbusmv.dll.

The session

A session is an instance of a DMMCSession class, and represents a unit of work for the MMC stack. It is, in effect, the main client interface to the MultiMediaCard Controller. Each client (i.e. the MultiMediaCard media driver or any other device driver) creates its own instance of this class. The client can then make MultiMediaCard requests on the stack by putting the appropriate information into the session object (configuring the session), and then submitting this session object to the stack; this is also referred to as engaging the session, and is invoked by calling DMMCSession::Engage(). Once submitted, the session is then scheduled - see Sessions and Request Management for more background information on this.

The DMMCSession class contains functions for initiating macro functions as laid down by the MultiMediaCard Association as well as lower level functions that allow a client to control the stack in a more explicit manner.

Power supply unit

The behavior of the power supply unit (PSU) is represented by the DMMCPsu class.

You will normally define and implement a derived class in the variant DLL, epbusmv.dll.

Media change

The behavior that deals with media change events is represented by the DMMCMediaChange class.

You will normally define and implement a derived class in the variant DLL, epbusmv.dll.

The controller factory

The controller factory, also known as the controller interface, is a TMMCardControllerInterface derived class that creates instances of your platform specific: stack class, power supply unit class, socket class, and media change class. It also allows you to perform platform specific initialization.

You create an instance of your factory class in the kernel extension entry point code in your DLL. This normally calls TMMCardControllerInterface::Create() on the object, a Symbian platform supplied function, which calls your implementations of the TMMCardControllerInterface pure virtual functions, to create the instances of your classes.

Note that these functions are only called for sockets that are associated with MultiMediaCard devices. TMMCardControllerInterface::Create() iterates through all possible socket numbers, from 0 to KMaxPBusSockets, calling TMMCardControllerInterface::IsMMCSocket() for each socket number to determine whether the socket number is a MultiMediaCard socket.