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.

+ +