Re: MMC_CAP_SDIO_IRQ for omap 3430

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



All,

I have sdio working mostly.  With a flood ping of 1000 packets I have
2 dropped.  Before I was seeing 300+ packets dropped.

It is not perfect yet,  I am still polling in sdio_irq.c because
sometimes the card irq does get dropped.  I suspect that is why the
davinci driver had extra checks and calls in various places.

Also apologies for this redundant reply, the last one was rejected by
the vger because of embedded html.

John

On Mon, Oct 19, 2009 at 11:24 AM, Madhusudhan <madhu.cr@xxxxxx> wrote:
>
> Hi John,
>
>
>
> So does the SDIO card interrupt mode work fine now?
>
>
>
> Regards,
>
> Madhu
>
>
>
> ________________________________
>
> From: John Rigby [mailto:jcrigby@xxxxxxxxx]
> Sent: Sunday, October 18, 2009 7:24 PM
> To: Woodruff, Richard
> Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-mmc@xxxxxxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx; 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@xxxxxxxxx> 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@xxxxxx> wrote:
> >>
> >>> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
> >>> owner@xxxxxxxxxxxxxxx] 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.
> >>
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux