* omap_hsmmc.c and MMC_CAP_SDIO_IRQ @ 2012-01-24 14:33 Michael Hunold 2012-01-27 14:09 ` Steve Sakoman 0 siblings, 1 reply; 5+ messages in thread From: Michael Hunold @ 2012-01-24 14:33 UTC (permalink / raw) To: linux-omap; +Cc: linux-mmc 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: 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. 3. There is one discussion from October 2009: http://www.mail-archive.com/linux-omap@vger.kernel.org/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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: omap_hsmmc.c and MMC_CAP_SDIO_IRQ 2012-01-24 14:33 omap_hsmmc.c and MMC_CAP_SDIO_IRQ Michael Hunold @ 2012-01-27 14:09 ` Steve Sakoman 2012-01-29 17:37 ` S, Venkatraman 2012-01-30 11:16 ` Michael Hunold 0 siblings, 2 replies; 5+ messages in thread From: Steve Sakoman @ 2012-01-27 14:09 UTC (permalink / raw) To: Michael Hunold; +Cc: linux-omap, linux-mmc On Tue, Jan 24, 2012 at 6:33 AM, Michael Hunold <hunold@linuxtv.org> 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. Regards, Steve ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: omap_hsmmc.c and MMC_CAP_SDIO_IRQ 2012-01-27 14:09 ` Steve Sakoman @ 2012-01-29 17:37 ` S, Venkatraman 2012-02-08 16:51 ` Steve Sakoman 2012-01-30 11:16 ` Michael Hunold 1 sibling, 1 reply; 5+ messages in thread From: S, Venkatraman @ 2012-01-29 17:37 UTC (permalink / raw) To: Steve Sakoman Cc: Michael Hunold, linux-omap, linux-mmc, Sourav Poddar, Balaji T Krishnamoorthy On Fri, Jan 27, 2012 at 7:39 PM, Steve Sakoman <sakoman@gmail.com> wrote: > On Tue, Jan 24, 2012 at 6:33 AM, Michael Hunold <hunold@linuxtv.org> 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 ? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: omap_hsmmc.c and MMC_CAP_SDIO_IRQ 2012-01-29 17:37 ` S, Venkatraman @ 2012-02-08 16:51 ` Steve Sakoman 0 siblings, 0 replies; 5+ messages in thread From: Steve Sakoman @ 2012-02-08 16:51 UTC (permalink / raw) To: S, Venkatraman Cc: Michael Hunold, linux-omap, linux-mmc, Sourav Poddar, Balaji T Krishnamoorthy On Sun, Jan 29, 2012 at 9:37 AM, S, Venkatraman <svenkatr@ti.com> wrote: > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: omap_hsmmc.c and MMC_CAP_SDIO_IRQ 2012-01-27 14:09 ` Steve Sakoman 2012-01-29 17:37 ` S, Venkatraman @ 2012-01-30 11:16 ` Michael Hunold 1 sibling, 0 replies; 5+ messages in thread From: Michael Hunold @ 2012-01-30 11:16 UTC (permalink / raw) To: Steve Sakoman; +Cc: linux-omap, linux-mmc Hello Steve, on 01/27/2012 03:09 PM Steve Sakoman said the following: > On Tue, Jan 24, 2012 at 6:33 AM, Michael Hunold <hunold@linuxtv.org> wrote: > Your summary below is a pretty accurate description of the current state. Ok. > 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. > 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: > 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. > Regards, > Steve CU Michael. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-02-08 16:51 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-01-24 14:33 omap_hsmmc.c and MMC_CAP_SDIO_IRQ Michael Hunold 2012-01-27 14:09 ` Steve Sakoman 2012-01-29 17:37 ` S, Venkatraman 2012-02-08 16:51 ` Steve Sakoman 2012-01-30 11:16 ` Michael Hunold
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).