Message-ID: <f71aedf40609051651k5d36d4fdkb6020685fc366983@mail.gmail.com>
Date:	Tue, 5 Sep 2006 18:51:00 -0500
From:	"madhu chikkature" <crmadhu210@...il.com>
To:	"Pierre Ossman" <drzeus-list@...eus.cx>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: SDIO card support in Linux

Hi Pierre,

Here is some piece of code that i wrote for SDIO. I use 2.6.10 kernel
and hence i can not really take a diff between the latest kernel
version. But this is not really a patch. So, You can just comment on
my code. I might later on work on the latest kernel versions based on
your comment.I see that there are more discussions happening. Please
pont to me if you have some code already written.

After your previous mail, i see that i can remove the support for CMD3
seperately for SDIO and do it the SD way. But i am not sure how to
maintain the list of SDIO cards seperately.Also some hardware as our
omap does, can support multiple MMC slots, in such cases one slot can
have SDIO and the other MMC. The core needs to cliam the cards from
different lists. So you may see some not so correct parts in my code.

I am on the Texas Instruments MMC/SD/SDIO controller on the omap2 platform.

Regards,
Madhu


On 8/31/06, Pierre Ossman <drzeus-list@...eus.cx> wrote:
> madhu chikkature wrote:
> > Hi,
> >
> > This is regarding the discussion going on in the list about the
> > support of SDIO cards in Linux. I read some discussion happening to
> > support SDIO cards using the existing Linux MMC core but I could not
> > figure out what would be the direction the community to support the
> > SDIO cards.
> >
>
> I've been casually working on adding SDIO support to the MMC layer. The
> driver model needs quite a bit of changes, so it's a bit of work before
> we have something working. So far I've only got the basic init up and
> running.
>
> The current version of the patch included (ignore the failed chunks for
> mmc_block.c). Feel free to test away. :)
>
> > I have done some work using our own hardware platform runing ARM
> > Linux. My hardware platform can support MMC/SD/SDIO cards.
> >
>
> Out of curiosity, what controller are you using?
>
> >
> > CMD3 of MMC can be reused during the discover cards phase, except that
> > the card will respond back with the RCA.
> >
>
> This is a SD "feature" and not specific to SDIO, so we have code for
> this already.
>
> >
> > With this, is it a fissible solution to have the MMC core do the
> > initialization part of the card by having the CMD sequence for SDIO
> > card (CMD5 and CMD3) in the mmc_setup sequence and maintain the SDIO
> > card list along with MMC/SD?
> >
>
> SD mandates a star topology (just a single card per bus), so we'll just
> force a single card into the list. SD memory cards can actually work on
> a shared bus, SDIO can not. It's not a big problem in practice though.
>
> > The CMD52 and CMD53 can be implemented with a simple pointer to
> > mmc_data structure(An instance of it for SDIO) to send and receive
> > data. Exporting the functions that implement CMD52 and CMD53 need to
> > be done, so that any card specific driver sitting on the top of the
> > MMC core can call these functions to read/write data from the card and
> > configure the card.
>
> I've started implementing some SDIO equivalents of readX/writeX.
>
> >
> > Couple of issues i faced are, how do we maintain the list of SDIO
> > cards? Right now, i am not adding it to the list of MMC cards. SDIO
> > combo cards need more work.
> >
>
> The driver model isn't designed for SDIO cards, so it needs to be
> changed. The design I'm working on couples "functions" to each card,
> where drivers will bind to these functions instead of the card. Search
> the archives for "MMC driver model" and you should find my LKML post
> about it.
>
> > Second issue is related to how well the data transfer commands can be
> > supported in such a way that the middleware, which does not exist as
> > of today to hook the SDIO cards to specific Linux subsystems based on
> > the type of the SDIO cards detected, for exaple WLAN SDIO card may
> > need to talk to the networking subsystem etc.
>
> It shouldn't be different from PCI, USB or any other bus.
>
> >
> > I am leaving the SDIO generic interrupts to the card specific driver.
> > With this setup and few additions to the MMC controller driver, i
> > could get the SDIO cards to be detected and i am able to read and
> > write data from the SDIO card CCCR registers.In fact the MMC/SD and
> > SDIO cards can co-exist.
> >
>
> We need controller help to do interrupts. It's on my todo-list as it
> requires a bit more indirection than "normal" interrupts.
>
> > Does this provide a basic support on which SDIO support can be worked
> > on? or does community have any other idea?
>
> The basic model changes should come first as they will dictate on how
> the rest of the code must be organised. I'd love to see your code though.
>
> >
> > SD support came in at 2.6.14 times and many people still does not have
> > access to SD specification easily. Is there any such issues related to
> > SDIO as well which might prevent the community from supporting SDIO
> > cards?
> >
>
> SDIO is actually easier as there is a spec for at least the protocol and
> Bluetooth cards.
>
> Rgds
> Pierre
>
>

Download attachment "mmc-core.patch" of type "application/octet-stream" (9137 bytes)

Download attachment "mmc-include.patch" of type "application/octet-stream" (3806 bytes)

Powered by blists - more mailing lists