From: "Madhusudhan" <madhu.cr@ti.com>
To: 'Dirk Behme' <dirk.behme@googlemail.com>, linux-omap@vger.kernel.org
Cc: 'John Rigby' <jcrigby@gmail.com>,
"'Woodruff, Richard'" <r-woodruff2@ti.com>,
linux-mmc@vger.kernel.org, 'Steve Sakoman' <sakoman@gmail.com>
Subject: RE: MMC_CAP_SDIO_IRQ for omap 3430
Date: Tue, 20 Oct 2009 17:47:05 -0500 [thread overview]
Message-ID: <00cb01ca51d7$3fafe130$544ff780@am.dhcp.ti.com> (raw)
In-Reply-To: <4ADCAD0F.9010107@googlemail.com>
> -----Original Message-----
> From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
> owner@vger.kernel.org] On Behalf Of Dirk Behme
> Sent: Monday, October 19, 2009 1:17 PM
> To: linux-omap@vger.kernel.org
> Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux-
> mmc@vger.kernel.org; 'Steve Sakoman'
> Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430
>
> Madhusudhan wrote:
> > Hi John,
> >
> > So does the SDIO card interrupt mode work fine now?
>
> (wrong attachment in previous mail :( sorry)
>
> If somebody likes to test, my updated patch v2 in attachment. Compile
> tested only, testing and comments are welcome.
>
Can you inline the v2 patch please? It helps review. I wonder in the version
that John tested was the CTPL bit set in "set_ios" or "enable_sdio_irq"?
Regards,
Madhu
> Cheers
>
> Dirk
>
> > _____
> >
> > 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.
> >>>
> >
> >
>
next prev parent reply other threads:[~2009-10-20 22: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 [this message]
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
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='00cb01ca51d7$3fafe130$544ff780@am.dhcp.ti.com' \
--to=madhu.cr@ti.com \
--cc=dirk.behme@googlemail.com \
--cc=jcrigby@gmail.com \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--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