On Fri, Jan 27, 2012 at 7:39 PM, Steve Sakoman <sakoman@xxxxxxxxx> wrote: > On Tue, Jan 24, 2012 at 6:33 AM, Michael Hunold <hunold@xxxxxxxxxxx> wrote: >> 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. > > Your summary below is a pretty accurate description of the current state. > >> 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: >> >> http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/recipes-kernel/linux/linux-omap-2.6.39/sakoman/0013-Enable-the-use-of-SDIO-card-interrupts.patch?id=1735237550d85da337ea57cb5d6be9ccc8c0355c >> >> 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. > >> 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? > > 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. > 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 ? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
