From: "S, Venkatraman" <svenkatr@ti.com>
To: Steve Sakoman <sakoman@gmail.com>
Cc: Michael Hunold <hunold@linuxtv.org>,
linux-omap@vger.kernel.org, linux-mmc@vger.kernel.org,
Sourav Poddar <sourav.poddar@ti.com>,
Balaji T Krishnamoorthy <balajitk@ti.com>
Subject: Re: omap_hsmmc.c and MMC_CAP_SDIO_IRQ
Date: Sun, 29 Jan 2012 23:07:25 +0530 [thread overview]
Message-ID: <CANfBPZ-6KptF=RG7fUX5+hB9DZDn9TvadU5acOm5yTAM7XOVgA@mail.gmail.com> (raw)
In-Reply-To: <CAGDS+nnVosHsv4SUcGXCieVQG2cjW=mL7DZ7_W2p+uNhUYfPyw@mail.gmail.com>
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 ?
next prev parent reply other threads:[~2012-01-29 17:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2012-02-08 16:51 ` Steve Sakoman
2012-01-30 11:16 ` Michael Hunold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANfBPZ-6KptF=RG7fUX5+hB9DZDn9TvadU5acOm5yTAM7XOVgA@mail.gmail.com' \
--to=svenkatr@ti.com \
--cc=balajitk@ti.com \
--cc=hunold@linuxtv.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=sakoman@gmail.com \
--cc=sourav.poddar@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).