omap_hsmmc.c and MMC_CAP_SDIO_IRQ
Hi,
I am experimenting with an SDIO card on the Beagleboard. I have started my experiments with Linux-3.1.4 some time ago and basically everything is working.
Except the fact that currently no native SDIO interrupts are used, but the status register is polled to recognise the interrupts. Ugh.
So I tried to find out the current state of MMC_CAP_SDIO_IRQ support.
0. No support for MMC_CAP_SDIO_IRQ in omap_hsmmc.c is present in mainline.
1. The "beagleboard-validation" kernel seems to have support for MMC_CAP_SDIO_IRQ in omap_hsmmc.c:
http://gitorious.org/beagleboard-validation/linux/blobs/beagleboardXM/drivers/mmc/host/omap_hsmmc.c
But this is an ancient 2.6.32 kernel. I tried to use it anyway, but compilation failed for me. I did not try to find the route cause of the problem.
2. Another indication of MMC_CAP_SDIO_IRQ support in omap_hsmmc.c can be found here:
I don't use Angstrom, so I just got a 2.6.39.4 kernel and tried to apply that patch (and the 0012-Don-t-turn-SDIO-cards-off-to-save-power.-Doing-so-wi.patch) patch as well, but they did not apply cleanly.
I tried to apply these patches to my 3.1.4 kernel, but of course they did not apply cleanly either.
3. There is one discussion from October 2009:
http://www.mail-archive.com/[email protected]/msg17802.html
4. There is patchset from David Vrabel from Februrary 2010:
http://www.spinics.net/lists/linux-mmc/msg01184.html
This seems to be the same as in 2.
So what is the current state of MMC_CAP_SDIO_IRQ support in omap_hsmmc.c?
Any hints how to proceed or which road to take?
I noticed that the Pandaboard uses a wifi SDIO adapter. AFAIK the OMAP4 uses omap_hsmmc.c as well. Is it true that interrupt polling is used there, too?
CU
Michael.
Quoted 10 lines · Michael Hunold
Hi,
I am experimenting with an SDIO card on the Beagleboard. I have started my experiments with Linux-3.1.4 some time ago and basically everything is working.
Except the fact that currently no native SDIO interrupts are used, but the status register is polled to recognise the interrupts. Ugh.
So I tried to find out the current state of
MMC_CAP_SDIO_IRQsupport.
Your summary below is a pretty accurate description of the current state.
Quoted 16 lines
0. No support for
MMC_CAP_SDIO_IRQinomap_hsmmc.cis present in mainline.1. The "beagleboard-validation" kernel seems to have support for
MMC_CAP_SDIO_IRQinomap_hsmmc.c:http://gitorious.org/beagleboard-validation/linux/blobs/beagleboardXM/drivers/mmc/host/omap_hsmmc.c
But this is an ancient 2.6.32 kernel. I tried to use it anyway, but compilation failed for me. I did not try to find the route cause of the problem.
2. Another indication of
MMC_CAP_SDIO_IRQsupport inomap_hsmmc.ccan be found here:
Quoted 7 lines
I don't use Angstrom, so I just got a 2.6.39.4 kernel and tried to apply that patch (and the 0012-Don-t-turn-SDIO-cards-off-to-save-power.-Doing-so-wi.patch) patch as well, but they did not apply cleanly.
I tried to apply these patches to my 3.1.4 kernel, but of course they did not apply cleanly either.
Indeed, the structure of omap_hsmmc.c has changed significantly and applying those patches is not a trivial exercise.
I've made an attempt at creating a patch for 3.2 that follows David Vrabel's original patch series as closely as possible with the new structure.
Unfortunately it doesn't quite work. I've only been doing this as a background task so progress is pretty slow.
The patch doesn't seem to break support for memory devices (which is good since my rootfs is on an mmc device!) and I do see SDIO interrupts occurring and being handled in the debug log, so it is a good start:
omap_hsmmc omap_hsmmc.1: enabled
mmc1: starting CMD52 arg 10004000 flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10004000 omap_hsmmc omap_hsmmc.1: IRQ Status is 100 Disabling SDIO interrupts
omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 0000100a 00000000 00000000 00000000 mmc1: starting CMD53 arg 92000094 flags 000001b5 mmc1: blksz 148 blocks 1 flags 00000100 tsac 1000 ms nsac 0 omap_hsmmc omap_hsmmc.1: mmc1: CMD53, argument 0x92000094 omap_hsmmc omap_hsmmc.1: IRQ Status is 3 mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000 mmc1: 148 bytes transferred: 0 mmc1: starting CMD52 arg 10000a00 flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10000a00 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 00001003 00000000 00000000 00000000 mmc1: starting CMD52 arg 90000afc flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x90000afc omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 000010fc 00000000 00000000 00000000 mmc1: starting CMD52 arg 10006800 flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10006800 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 00001012 00000000 00000000 00000000 mmc1: starting CMD52 arg 10006a00 flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10006a00 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 00001000 00000000 00000000 00000000 mmc1: starting CMD52 arg 10004000 flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10004000 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 00001009 00000000 00000000 00000000 mmc1: starting CMD53 arg 12000014 flags 000001b5 mmc1: blksz 20 blocks 1 flags 00000200 tsac 1000 ms nsac 0 omap_hsmmc omap_hsmmc.1: mmc1: CMD53, argument 0x12000014 omap_hsmmc omap_hsmmc.1: IRQ Status is 3 mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000 mmc1: 20 bytes transferred: 0 Enabling SDIO interrupts omap_hsmmc omap_hsmmc.1: IRQ Status is 100 Disabling SDIO interrupts mmc1: starting CMD52 arg 10000a00 flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10000a00 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 00001001 00000000 00000000 00000000 mmc1: starting CMD52 arg 90000afe flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x90000afe omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 000010fe 00000000 00000000 00000000 mmc1: starting CMD52 arg 10006800 flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10006800 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 00001092 00000000 00000000 00000000 mmc1: starting CMD52 arg 10006a00 flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10006a00 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 00001000 00000000 00000000 00000000 mmc1: starting CMD52 arg 10004000 flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10004000 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 0000100a 00000000 00000000 00000000 mmc1: starting CMD53 arg 12000094 flags 000001b5 mmc1: blksz 148 blocks 1 flags 00000200 tsac 1000 ms nsac 0 omap_hsmmc omap_hsmmc.1: mmc1: CMD53, argument 0x12000094 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 omap_hsmmc omap_hsmmc.1: IRQ Status is 2 mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000 mmc1: 148 bytes transferred: 0 Enabling SDIO interrupts mmc1: starting CMD52 arg 10004000 flags 00000195 omap_hsmmc omap_hsmmc.1: mmc1: CMD52, argument 0x10004000 omap_hsmmc omap_hsmmc.1: IRQ Status is 1 mmc1: req done (CMD52): 0: 00001008 00000000 00000000 00000000 mmc1: starting CMD53 arg 92000010 flags 000001b5 mmc1: blksz 16 blocks 1 flags 00000100 tsac 1000 ms nsac 0 omap_hsmmc omap_hsmmc.1: mmc1: CMD53, argument 0x92000010 omap_hsmmc omap_hsmmc.1: IRQ Status is 3 mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000 mmc1: 16 bytes transferred: 0 omap_hsmmc omap_hsmmc.1: disabled
However the SDIO device does not function properly due to multiple timeout errors, so something is still not quite right.
Quoted 3 lines
I noticed that the Pandaboard uses a wifi SDIO adapter. AFAIK the OMAP4 uses
omap_hsmmc.cas well. Is it true that interrupt polling is used there, too?
In that case interrupts are used, but sadly they are implemented via a separate GPIO and not the SDIO interrupt mechanism!
I suspect they did this as a hw workaround to the lack of support for SDIO interrupts in mainline :-(
Let me know if you would like to help with further development of the patch and I will send you a copy. It is rough enough and broken enough that it probably isn't yet ready for even an RFC to these lists.
Regards,
Steve
Quoted 145 lines · Steve Sakoman
Quoted 10 lines · Michael Hunold
Hi,
I am experimenting with an SDIO card on the Beagleboard. I have started my experiments with Linux-3.1.4 some time ago and basically everything is working.
Except the fact that currently no native SDIO interrupts are used, but the status register is polled to recognise the interrupts. Ugh.
So I tried to find out the current state of
MMC_CAP_SDIO_IRQsupport.Your summary below is a pretty accurate description of the current state.
Quoted 16 lines
0. No support for
MMC_CAP_SDIO_IRQinomap_hsmmc.cis present in mainline.1. The "beagleboard-validation" kernel seems to have support for
MMC_CAP_SDIO_IRQinomap_hsmmc.c:http://gitorious.org/beagleboard-validation/linux/blobs/beagleboardXM/drivers/mmc/host/omap_hsmmc.c
But this is an ancient 2.6.32 kernel. I tried to use it anyway, but compilation failed for me. I did not try to find the route cause of the problem.
2. Another indication of
MMC_CAP_SDIO_IRQsupport inomap_hsmmc.ccan be found here:Quoted 7 lines
I don't use Angstrom, so I just got a 2.6.39.4 kernel and tried to apply that patch (and the 0012-Don-t-turn-SDIO-cards-off-to-save-power.-Doing-so-wi.patch) patch as well, but they did not apply cleanly.
I tried to apply these patches to my 3.1.4 kernel, but of course they did not apply cleanly either.
Indeed, the structure of
omap_hsmmc.chas changed significantly and applying those patches is not a trivial exercise.I've made an attempt at creating a patch for 3.2 that follows David Vrabel's original patch series as closely as possible with the new structure.
Unfortunately it doesn't quite work. I've only been doing this as a background task so progress is pretty slow.
The patch doesn't seem to break support for memory devices (which is good since my rootfs is on an mmc device!) and I do see SDIO interrupts occurring and being handled in the debug log, so it is a good start:
omap_hsmmcomap_hsmmc.1: enabled
mmc1: starting CMD52 arg 10004000 flags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x10004000omap_hsmmcomap_hsmmc.1: IRQ Status is 100
Disabling SDIO interruptsomap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0:0000100a00000000 00000000 00000000
mmc1: starting CMD53 arg 92000094 flags000001b5
mmc1: blksz 148 blocks 1 flags 00000100 tsac 1000 ms nsac 0omap_hsmmcomap_hsmmc.1: mmc1: CMD53, argument0x92000094omap_hsmmcomap_hsmmc.1: IRQ Status is 3
mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc1: 148 bytes transferred: 0
mmc1: starting CMD52 arg10000a00flags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x10000a00omap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0: 00001003 00000000 00000000 00000000
mmc1: starting CMD52 arg90000afcflags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x90000afcomap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0:000010fc00000000 00000000 00000000
mmc1: starting CMD52 arg 10006800 flags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x10006800omap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0: 00001012 00000000 00000000 00000000
mmc1: starting CMD52 arg10006a00flags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x10006a00omap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0: 00001000 00000000 00000000 00000000
mmc1: starting CMD52 arg 10004000 flags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x10004000omap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0: 00001009 00000000 00000000 00000000
mmc1: starting CMD53 arg 12000014 flags000001b5
mmc1: blksz 20 blocks 1 flags 00000200 tsac 1000 ms nsac 0omap_hsmmcomap_hsmmc.1: mmc1: CMD53, argument0x12000014omap_hsmmcomap_hsmmc.1: IRQ Status is 3
mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc1: 20 bytes transferred: 0
Enabling SDIO interruptsomap_hsmmcomap_hsmmc.1: IRQ Status is 100
Disabling SDIO interrupts
mmc1: starting CMD52 arg10000a00flags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x10000a00omap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0: 00001001 00000000 00000000 00000000
mmc1: starting CMD52 arg90000afeflags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x90000afeomap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0:000010fe00000000 00000000 00000000
mmc1: starting CMD52 arg 10006800 flags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x10006800omap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0: 00001092 00000000 00000000 00000000
mmc1: starting CMD52 arg10006a00flags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x10006a00omap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0: 00001000 00000000 00000000 00000000
mmc1: starting CMD52 arg 10004000 flags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x10004000omap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0:0000100a00000000 00000000 00000000
mmc1: starting CMD53 arg 12000094 flags000001b5
mmc1: blksz 148 blocks 1 flags 00000200 tsac 1000 ms nsac 0omap_hsmmcomap_hsmmc.1: mmc1: CMD53, argument0x12000094omap_hsmmcomap_hsmmc.1: IRQ Status is 1omap_hsmmcomap_hsmmc.1: IRQ Status is 2
mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc1: 148 bytes transferred: 0
Enabling SDIO interrupts
mmc1: starting CMD52 arg 10004000 flags 00000195omap_hsmmcomap_hsmmc.1: mmc1: CMD52, argument0x10004000omap_hsmmcomap_hsmmc.1: IRQ Status is 1
mmc1: req done (CMD52): 0: 00001008 00000000 00000000 00000000
mmc1: starting CMD53 arg 92000010 flags000001b5
mmc1: blksz 16 blocks 1 flags 00000100 tsac 1000 ms nsac 0omap_hsmmcomap_hsmmc.1: mmc1: CMD53, argument0x92000010omap_hsmmcomap_hsmmc.1: IRQ Status is 3
mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000
mmc1: 16 bytes transferred: 0omap_hsmmcomap_hsmmc.1: disabledHowever the SDIO device does not function properly due to multiple timeout errors, so something is still not quite right.
Quoted 3 lines
I noticed that the Pandaboard uses a wifi SDIO adapter. AFAIK the OMAP4 uses
omap_hsmmc.cas well. Is it true that interrupt polling is used there, too?In that case interrupts are used, but sadly they are implemented via a separate GPIO and not the SDIO interrupt mechanism!
Quoted 8 lines
I suspect they did this as a hw workaround to the lack of support for SDIO interrupts in mainline :-(
Let me know if you would like to help with further development of the patch and I will send you a copy. It is rough enough and broken enough that it probably isn't yet ready for even an RFC to these lists.
A few folks in my group are working on this (CC'ed). I'd hazard a guess to say that the patches can be validated and sent out in another 1-2 weeks - Sourav ?
Quoted 2 lines · Venkatraman
A few folks in my group are working on this (CC'ed). I'd hazard a guess to say that the patches can be validated and sent out in another 1-2 weeks - Sourav ?
Any update on the status of the above-mentioned patch for SDIO interrupt support?
Steve
Hello Steve,
on 01/27/2012 03:09 PM Steve Sakoman said the following:
Quoted 3 lines · Michael Hunold
Your summary below is a pretty accurate description of the current state.
Ok.
Quoted 6 lines
I've made an attempt at creating a patch for 3.2 that follows David Vrabel's original patch series as closely as possible with the new structure.
Unfortunately it doesn't quite work. I've only been doing this as a background task so progress is pretty slow.
I understand, no problem.
Quoted 5 lines
The patch doesn't seem to break support for memory devices (which is good since my rootfs is on an mmc device!) and I do see SDIO interrupts occurring and being handled in the debug log, so it is a good start:
Quoted 7 lines
However the SDIO device does not function properly due to multiple timeout errors, so something is still not quite right.
Let me know if you would like to help with further development of the patch and I will send you a copy. It is rough enough and broken enough that it probably isn't yet ready for even an RFC to these lists.
Yes, please send them to me. I will give them a try and let you know the results.
As a side node: actually I'm working double tracked. I plan to use it on some OMAP-based board like Beagleboard or Pandaboard for a stationary system, running any kernel that is needed.
But I'd like to use some spare N900s as well, because I can carry them around easily. But these are running ancient 2.6.28.1 kernels. David Vrabel mentioned that he originally developed his patches on the N900. I sent him a mail using his mail address from csr.com, but I have not received a reply yet.
If you or anybody else has every seen his original patches for the N900 (he did not sent them to any list as far as I know) please let me know as well.
Quoted 2 lines
Regards,
Steve
CU
Michael.