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 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
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
Pierre Ossman 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.
<snip>
>> 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.
Ian Stirling wrote:
>>
>> 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
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 <[email protected]> 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
>
>
madhu chikkature wrote:
> 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
Hi Pierre,
What is the kernel version this patch is taken againest?
Regards,
Madhu
On 9/6/06, Pierre Ossman <[email protected]> wrote:
> madhu chikkature wrote:
> > 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 wrote:
> Hi Pierre,
>
> What is the kernel version this patch is taken againest?
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)
Rgds
Pierre
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