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.be...@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...@ti.com> wrote: >> >>> Hi John, >>> >>> >>> >>> So does the SDIO card interrupt mode work fine now? >>> >>> >>> >>> Regards, >>> >>> Madhu >>> >>> >>> ------------------------------ >>> >>> *From:* John Rigby [mailto:jcri...@gmail.com] >>> *Sent:* Sunday, October 18, 2009 7:24 PM >>> *To:* Woodruff, Richard >>> *Cc:* Dirk Behme; Chikkature Rajashekar, Madhusudhan; >>> linux-...@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 <jcri...@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-woodru...@ti.com> >>> >>> wrote: >>>>>> >>>>>> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- >>>>>> ow...@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. >>>>> >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
