Messages in this thread | | | Subject | Re: [RFC] New MMC driver model | From | Marcel Holtmann <> | Date | Tue, 20 Jun 2006 11:35:22 +0200 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |