[RFC] New MMC driver model

[RFC] New MMC driver model

[Pierre Ossman]

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

Re: [RFC] New MMC driver model

[Marcel Holtmann]

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

Re: [RFC] New MMC driver model

[Pierre Ossman]

Marcel Holtmann wrote:
>> 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.
>
>   

It probably won't give you any fantastic performance, but if the choice
is between crappy performance or none at all...

Also it would allow me to do some testing on my controller. Which brings
me to...

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

If you have any SDIO cards to spare, I'd really appreciate if I could
borrow one or two for testing.

Rgds
Pierre

Re: [RFC] New MMC driver model

[Marcel Holtmann]

Hi Pierre,

> > 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.
> 
> If you have any SDIO cards to spare, I'd really appreciate if I could
> borrow one or two for testing.

let me send you one of my SDIO WiFi cards. Please send me your address
via private email an I try to get it to you as soon as possible.

Regards

Marcel

Re: [RFC] New MMC driver model

[pierre Tardy]

Pierre Ossman <drzeus-list <at> drzeus.cx> writes:

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

Good idea. Another need may be a sdio_read[bwl]_sync, which will poll for the
end of the cmd52s, instead of waiting for the irq. This polling is faster than
wait_for_completion/irq/tasklet/complete mechanism, which involve several
context switches. 

>  Endianness can also be handled there (SDIO are always LE).
I dont remember sdio spec forcing HW registers to be LE. Function 0 registers
are (BLKSZ for ex), but Function 1-7 register may be BE if the designers found
an advantage to it..

Re: [RFC] New MMC driver model

[Pierre Ossman]

(Please keep me as cc as I will almost always overlook you replies
otherwise)

pierre Tardy wrote:
> Pierre Ossman <drzeus-list <at> drzeus.cx> writes:
> 
>> 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.
> 
> Good idea. Another need may be a sdio_read[bwl]_sync, which will poll for the
> end of the cmd52s, instead of waiting for the irq. This polling is faster than
> wait_for_completion/irq/tasklet/complete mechanism, which involve several
> context switches. 
> 

Hadn't thought of that. I will have to do some tests once I have
something functional.

>>  Endianness can also be handled there (SDIO are always LE).
> I dont remember sdio spec forcing HW registers to be LE. Function 0 registers
> are (BLKSZ for ex), but Function 1-7 register may be BE if the designers found
> an advantage to it..
> 

Hmm... It's been a while since I read the spec, but perhaps the LE
requirement was only for the base registers.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org