public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Dirk Behme <dirk.behme@googlemail.com>
To: John Rigby <jcrigby@gmail.com>,
	linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org
Cc: Madhusudhan <madhu.cr@ti.com>,
	"Woodruff, Richard" <r-woodruff2@ti.com>,
	Steve Sakoman <sakoman@gmail.com>
Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430
Date: Tue, 20 Oct 2009 06:47:38 +0200	[thread overview]
Message-ID: <4ADD40EA.9020200@googlemail.com> (raw)
In-Reply-To: <4b73d43f0910191439o30fd1de6odab8ccd5e5430760@mail.gmail.com>

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.
>>>>
> 


  parent reply	other threads:[~2009-10-20  4:47 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-15 20:30 MMC_CAP_SDIO_IRQ for omap 3430 John Rigby
2009-10-16  7:16 ` Dirk Behme
2009-10-16 13:43   ` John Rigby
2009-10-16 15:02     ` Dirk Behme
2009-10-16 15:59       ` John Rigby
2009-10-16 16:06         ` Dirk Behme
2009-10-16 18:51           ` John Rigby
2009-10-16 19:55             ` Dirk Behme
     [not found]               ` <4b73d43f0910161337k24908c7bjf5d84a90efb27bef@mail.gmail.com>
2009-10-16 20:39                 ` John Rigby
2009-10-16 17:43   ` Madhusudhan Chikkature
2009-10-16 19:28     ` Dirk Behme
2009-10-16 21:14       ` Madhusudhan
2009-10-16 21:26         ` John Rigby
2009-10-17  6:30           ` Dirk Behme
2009-10-17 15:12             ` John Rigby
2009-10-17 17:36               ` Dirk Behme
2009-10-17 18:08               ` Dirk Behme
2009-10-18 16:44           ` Dirk Behme
2009-10-18 23:12             ` Woodruff, Richard
2009-10-19  0:17               ` John Rigby
     [not found]                 ` <4b73d43f0910181724q11d40851wb2aed801d7ae85f6@mail.gmail.com>
2009-10-19 17:27                   ` Madhusudhan
     [not found]                   ` <005101ca50e1$11ef2770$544ff780@am.dhcp.ti.com>
2009-10-19 18:10                     ` Dirk Behme
2009-10-19 18:16                     ` Dirk Behme
2009-10-20 22:47                       ` Madhusudhan
2009-10-20 22:59                         ` John Rigby
2009-10-21 17:46                           ` Dirk Behme
2009-10-21 17:44                         ` Dirk Behme
2009-10-20  1:13                     ` John Rigby
2009-10-20  2:53                       ` Woodruff, Richard
     [not found]                     ` <4b73d43f0910191439o30fd1de6odab8ccd5e5430760@mail.gmail.com>
2009-10-20  4:47                       ` Dirk Behme [this message]
2009-10-20 18:45                         ` John Rigby
2009-10-20 18:55                           ` Steve Sakoman
2009-10-19 14:52               ` Dirk Behme
2009-10-19 15:29                 ` Woodruff, Richard

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=4ADD40EA.9020200@googlemail.com \
    --to=dirk.behme@googlemail.com \
    --cc=jcrigby@gmail.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=madhu.cr@ti.com \
    --cc=r-woodruff2@ti.com \
    --cc=sakoman@gmail.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