[RFC] New MMC driver model

I've been looking at how we can support SDIO cards and how we need to
adapt our driver model for it.

Functions
=========

First of all, we need to have multiple drivers for one physical card.
This is needed to handle both "combo cards" (mem and I/O) and because
SDIO cards can have seven distinct functions in one card.

For this I propose we add the concept of "function" and that each "card"
has 1 to 8 of these. The drivers then bind to these functions, not to
the card.

Identification
==============

SDIO uses the PCMCIA CIS structure for its generic fields. This includes
the CISTPL_MANFID tuple, which has one 16-bit value for manufacturer and
one 16-bit value for card id. The standard also has a special field for
"standard" interfaces, which are similar to PCI classes.

This scheme would allow us to handle storage cards quite nicely:

#define SDIO_ID_ANY 0xFFFFFFFF

#define SDIO_VENDOR_STORAGE 0xFFFFFFFE
#define SDIO_DEVICE_ID_STORAGE_MMC 0x00000000
#define SDIO_DEVICE_ID_STORAGE_SD 0x00000001

(If the prefix makes the MMC layer a bit SDIO centric, feel free to come
with other suggestions)

Interrupts
==========

SDIO has generic interrupts that cards can use how they damn well
please. The interrupts are also level triggered and have the nice
"feature" of being active when there is no card in the slot.

So I propose the following:

* We add a "interrupt enable" field to the ios structure so that hosts
know when a SDIO card has been inserted and card interrupts should be
caught.

* When a interrupt is caught, the host driver masks it and tells the
MMC layer that a interrupt is pending. The MMC layer then calls a card
interrupt handler in some deferred manner (suggestions welcome).

* When the card driver feels that it has handled the interrupt, it
calls a special acknowledge command that removes the mask the host has set.

Since SDIO cards can have seven distinct functions, there is a generic
register that tells which of the seven that currently has a pending
interrupt. This allows us to call only the relevant handlers.

The "interrupt pending" register also allows us to do a polled solution
for non-SDIO capable hosts. I'm unsure how to get a good balance between
latency and resource usage though.

Register functions
==================

I also intend to write a couple of register functions (sdio_read[bwl])
so that card drivers doesn't have to deal with MMC requests more than
necessary. Endianness can also be handled there (SDIO are always LE).


Comment away!

Rgds
Pierre
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi Pierre,

> I've been looking at how we can support SDIO cards and how we need to
> adapt our driver model for it.
>
> Functions
> =========
>
> First of all, we need to have multiple drivers for one physical card.
> This is needed to handle both "combo cards" (mem and I/O) and because
> SDIO cards can have seven distinct functions in one card.
>
> For this I propose we add the concept of "function" and that each "card"
> has 1 to 8 of these. The drivers then bind to these functions, not to
> the card.

sounds reasonable to me and a storage only card has only one function.

> Identification
> ==============
>
> SDIO uses the PCMCIA CIS structure for its generic fields. This includes
> the CISTPL_MANFID tuple, which has one 16-bit value for manufacturer and
> one 16-bit value for card id. The standard also has a special field for
> "standard" interfaces, which are similar to PCI classes.
>
> This scheme would allow us to handle storage cards quite nicely:
>
> #define SDIO_ID_ANY 0xFFFFFFFF
>
> #define SDIO_VENDOR_STORAGE 0xFFFFFFFE
> #define SDIO_DEVICE_ID_STORAGE_MMC 0x00000000
> #define SDIO_DEVICE_ID_STORAGE_SD 0x00000001
>
> (If the prefix makes the MMC layer a bit SDIO centric, feel free to come
> with other suggestions)

So we can have SDIO_DEVICE and SDIO_DEVICE_CLASS macros for the matching
drivers to functions.

> Interrupts
> ==========
>
> SDIO has generic interrupts that cards can use how they damn well
> please. The interrupts are also level triggered and have the nice
> "feature" of being active when there is no card in the slot.
>
> So I propose the following:
>
> * We add a "interrupt enable" field to the ios structure so that hosts
> know when a SDIO card has been inserted and card interrupts should be
> caught.
>
> * When a interrupt is caught, the host driver masks it and tells the
> MMC layer that a interrupt is pending. The MMC layer then calls a card
> interrupt handler in some deferred manner (suggestions welcome).
>
> * When the card driver feels that it has handled the interrupt, it
> calls a special acknowledge command that removes the mask the host has set.

It looks very straight forward to me.

> Since SDIO cards can have seven distinct functions, there is a generic
> register that tells which of the seven that currently has a pending
> interrupt. This allows us to call only the relevant handlers.
>
> The "interrupt pending" register also allows us to do a polled solution
> for non-SDIO capable hosts. I'm unsure how to get a good balance between
> latency and resource usage though.

I think that polled solution is not really working out. Especially if
you need some high speed transfers.

> Register functions
> ==================
>
> I also intend to write a couple of register functions (sdio_read[bwl])
> so that card drivers doesn't have to deal with MMC requests more than
> necessary. Endianness can also be handled there (SDIO are always LE).

Good idea.

> Comment away!

My understanding of the current MMC core is rather limited and I think
that I am not of any good help to get this started. However I have a
couple of SDIO cards (various types) for testing and I am happy to test
any patch you send around.

Regards

Marcel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/