Sessions and Request Management

Session queues

To handle sessions, the MultiMediaCard controller implements a scheduler. The MultiMediaCard stack has three internal queues:

• an entry queue - this is the queue onto which a session is initially added when a client submits the session object by calling DMMCSession::Engage() on it. This is anchored in the DMMCStack::iEntryQueue private member.

• a ready queue - this is the queue into which a session is moved when it is ready to be handled; the scheduler moves all the sessions from the entry queue into the ready queue when it can. This is anchored in the DMMCStack::iReadyQueue private member.

• a working set queue - this is the queue of sessions to be processed as chosen by the scheduler. This queue is limited to eight sessions. The scheduler moves a session from the ready queue to the working set queue if all current sessions in the working set queue are blocked and there are less than eight sessions in it. This is anchored in the DMMCStack::iWorkSet private member.

All three queues are circular queues as implemented using the internal Symbian platform class TMMCSessionRing.

The scheduler

Every time one of the following events occurs, the MultiMediaCard stack invokes its scheduler to deal with that event:

• a client submitting a session to the MultiMediaCard controller

• a client aborting a session

• a card interrupt occurring.

The stack invokes the scheduler by calling the internal function DMMCStack::Scheduler().

Blocking a session

Sometimes, the MultiMediaCard controller has to perform its processing in a DFC context. In those cases the Controller postpones operation by queuing a DFC; the DFC call-back function then resumes the operation by invoking the scheduler again. This means that the scheduler may be running as part of a kernel executive call, a DFC or an interrupt service routine.

In general, the MultiMediaCard controller processes a session in stages, issuing commands, checking responses, reading or writing data etc. Each stage is usually done asynchronously, first setting up the activity and then setting up a means of being notified when that activity is complete, for whatever reason (e.g. issuing a command and setting up an interrupt when a response has been received).

If a session is waiting on an asynchronous operation, it is blocked. When one session is blocked, the stack tries to process another session which isn’t blocked.

The blocking of sessions is set up and implemented internally to Symbian platform. However, the platform specific layer can block a session by calling the DMMCStack::BlockCurrentSession() function with the KMMCBlockOnASSPFunction bit set in the parameter passed to that function.

Internally, the DMMCSession::iBlockOn private data member is set when a session is blocked. This is a bit-mask variable containing the reason that the session is blocked.

Scheduler algorithm

The following flow-diagram shows the algorithm used by the scheduler.

The DMMCStack private members referenced in this diagram have the following meaning: