Re: MMC_CAP_SDIO_IRQ for omap 3430

John Rigby
2009-10-20T18:53:14Z

It is still a work in progress because I have hacked the sdio_irq
thread to poll all the time. I won't get a chance to do a proper fix
for a couple of days at least.

The main part of the fix was just turning on the cptl in the same
place you turn on the cirq bit.

Send me a reminder If you get no offers of testing help from anyone
else and I'll try to use my beagle board and wifi card with a modern
kernel.

John

On Mon, Oct 19, 2009 at 10:47 PM, Dirk Behme <dirk.behme@googlemail.com> wrote:
> John Rigby wrote:
>>
>> All,
>>
>> Sorry for the delay, I have been without internet access until just now.
>>
>> I added the cptl bit and I don't get continuous cirqs anymore.
>>
>> Right now I have a hacked driver that still does timed polling in
>> sdio_irq.c
>> and also wakes up on cirq.  With this config the libertas works well.  A
>> flood ping of 1000 packets loses 2.  Previously it was dropping about 30%
>> of
>> the packets from a flood ping.
>
> Great!! :)
>
>> Without the polling in sdio_irq.c I get timeouts in libertas driver so I
>> suspect that we may need to add checks of the DAT1 line in other places
>> like
>> the davinci driver does.  As I said before, my kernel is a few months old
>> so
>> my issues may not be the same as current head of tree.
>
> Do you like to send your changes anyway? Just for reference...
>
>> Thanks to all who helped on this.
>
> Now, the job will be to do this with recent kernel, make it stable and in
> the mid term get it applied.
>
> Anybody likes to help with this?
>
> Many thanks and best regards
>
> Dirk
>
>> On Mon, Oct 19, 2009 at 11:24 AM, Madhusudhan <madhu.cr@ti.com> wrote:
>>
>>>  Hi John,
>>>
>>>
>>>
>>> So does the SDIO card interrupt mode work fine now?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Madhu
>>>
>>>
>>>  ------------------------------
>>>
>>> *From:* John Rigby [mailto:jcrigby@gmail.com]
>>> *Sent:* Sunday, October 18, 2009 7:24 PM
>>> *To:* Woodruff, Richard
>>> *Cc:* Dirk Behme; Chikkature Rajashekar, Madhusudhan;
>>> linux-mmc@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman
>>> *Subject:* Re: MMC_CAP_SDIO_IRQ for omap 3430
>>>
>>>
>>>
>>> Ok I was going to ask where you found that but I just rechecked the TRM
>>> and
>>> there it is in plain site:
>>>
>>>  When this bit is set to 1, the host controller automatically disables
>>> all
>>> the input buffers except the buffer of mmci_dat[1] outside of a
>>> transaction
>>> in order to detect asynchronous card interrupt on mmci_dat[1] line and
>>> minimize the leakage current of the buffers.
>>>
>>>
>>> In my defence, I did search the TRM for every occurance of dat1 but not
>>> dat[1].  Oh well live and learn and forget and repeat.
>>>
>>> John
>>>
>>> On Sun, Oct 18, 2009 at 6:17 PM, John Rigby <jcrigby@gmail.com> wrote:
>>>>
>>>> Richard,
>>>>
>>>> MMCHS_CON.CPTL = 1  < Don't disable input buffer on DAT1 after
>>>> completion to allow seeing SDIO interrupt>
>>>>
>>>> Sounds exactly like what we need.
>>>>
>>>> Thanks
>>>> John
>>>>
>>>> On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard <r-woodruff2@ti.com>
>>>
>>> wrote:
>>>>>>
>>>>>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>>>>>> owner@vger.kernel.org] On Behalf Of Dirk Behme
>>>>>> Sent: Sunday, October 18, 2009 11:45 AM
>>>>>>>
>>>>>>> It would be funny if the TRM was wrong and the CIRQ bit is really
>>>>>>> cleared by writing 1 to it.  I'll try that.
>>>>>
>>>>> A while back I hunted down a few of the bits for this.  Maybe this will
>>>
>>> help some.
>>>>>
>>>>> SYSCONFIG.ENAWAKEUP = 1 < allow ocp wrapper to generate an interrupt to
>>>
>>> prcm>
>>>>>
>>>>> MMCHS_HCTL.IWE = 1 < route wake up to module ocp wrapper>
>>>>> MMCHS_CON.CPTL = 1  < Don't disable input buffer on DAT1 after
>>>
>>> completion to allow seeing SDIO interrupt>
>>>>>
>>>>> MMCHS_HCTL.IWE
>>>>> MMCHS_ISE.CIRQ_ENABLE <bit to write to enable interrupt at pin>
>>>>> MMCHS_STAT<bit to write for clear of SDIO interrupt>
>>>>> CCCCR - IRQ_ENABLE (think host stack will do this)
>>>>>
>>>>> Regards,
>>>>> Richard W.
>>>>>
>>
>
>