SDIO card support in Linux
madhu chikkature
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 have done some work using our own hardware platform runing ARM
Linux. My hardware platform can support MMC/SD/SDIO cards.
From the SDIO specification, i understand that we need to add support
for the following commonds in the MMC core to support SDIO cards.
IO_SEND_OP_COND -- CMD5 --- This command is very much simillar to CMD1 of MMC.
CMD3 of MMC can be reused during the discover cards phase, except that
the card will respond back with the RCA.
IO_RW_DIRECT -- CMD52
IO_RW_EXTENDED -- CMD53
The above two are data transfer commands. CMD52 does not use data
lines. This command can be used to read/write 1 byte of data on the
CMD line.
CMD53 is equavalent to CMD17/CMD18/CMD24/CMD25 of MMC to read/write
data on data lines.
The SDIO spec only exposes a few set of registers called CARD COMMON
CONTROL REGISTERS which are common to all types of SDIO cards.
Functionality specific SDIO card registers are left to the vendor to describe.
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?
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.
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.
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.
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.
Does this provide a basic support on which SDIO support can be worked
on? or does community have any other idea?
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?
Please let me know views on this.
Regards,
Madhu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pierre Ossman
> 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
Varun
I am currently working on SDIO Wi-fI driver. When I send CMD53 to the
card I always get a Write CRC error. What might be the issue? There
are a lot of CMD52 before this CMD53 which run successfully but once
CMD53 is sent to the card I get an error.
One more thing, when I send CMD53 how will the data be written to the
SDIO card? How does the Bus Driver send us the data to be written in
this case?
Regards,
Varun
Ian Stirling
> 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.
>> 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.
Is this true in SD-1 bit mode, or SPI?
I see nothing on a quick read-through of the abbreviated SDIO spec
precluding this.
Of course, it'd mean wire-or'd interrupt lines.
Pierre Ossman
>>
>> 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.
>
> Is this true in SD-1 bit mode, or SPI?
Yes, no. :)
> I see nothing on a quick read-through of the abbreviated SDIO spec
> precluding this.
> Of course, it'd mean wire-or'd interrupt lines.
>
The problem is that there is no "king-of-the-hill" mechanism in the SDIO
init sequence (like there is in SD mem). The protocol assumes that the
desired card always receives the command.
Rgds
Pierre
Pierre Ossman
> 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.
>
Your design is a bit lacking yes as it doesn't properly reuse the
structures in place. Have a look at the version I'm working on instead.
Rgds
Pierre
madhu chikkature
What is the kernel version this patch is taken againest?
Regards,
Madhu
Pierre Ossman
> Hi Pierre,
>
It's against the git version (plus some of my pending patches, which is
why I said you should ignore the chunk problems in mmc_block.c)
Bhavani
madhu chikkature <crmadhu210 <at> gmail.com> writes:
>
> 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
Hi Madhu,
I hve omap2420,Tsunami board n i'm trying to bring up stack for sdio card.
Once i give IO_RW_EXTENDED the system gets hanged. I find it bit difficult to
fix it. Is there anything i'hve to change in host driver code. Please help me.
Thanks,
Bhavani