It appears to never get cleared in the status register. I added some printks to sdio_irq.c to print the pending interrupts in the SDIO_CCCR_INTx register for the card and there are no pending interrupts so I don't think it is a card driver or card issue.
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. John On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan <madhu...@ti.com> wrote: > > >> -----Original Message----- >> From: Dirk Behme [mailto:dirk.be...@googlemail.com] >> Sent: Friday, October 16, 2009 2:28 PM >> To: Madhusudhan Chikkature >> Cc: linux-...@vger.kernel.org; John Rigby; linux-omap@vger.kernel.org; >> Steve Sakoman >> Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 >> >> Madhusudhan Chikkature wrote: >> > Hi Dirk, >> > >> > I am inlining the patch so that it helps review. >> ... >> > @@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm >> > break; >> > case MMC_BUS_WIDTH_4: >> > OMAP_HSMMC_WRITE(host->base, CON, con & ~DW8); >> > - OMAP_HSMMC_WRITE(host->base, HCTL, >> > - OMAP_HSMMC_READ(host->base, HCTL) | FOUR_BIT); >> > + if (mmc_card_sdio(host->mmc->card)) { >> > >> > I wish it could be moved to "enable_sdio_irq" so that we can avoid >> inclusion of >> > card.h and checking the type of card in the host controller driver. >> >> Yes, this would be the real clean way. But ... >> >> > But the >> > dependancy on 4-bit seems to be a problem here. >> >> ... most probably we have to find a workaround until (if ever?) above >> clean implementation is available. >> >> What we need is after SDIO mode and bus width is known, and before the >> first interrupt comes, to set IBG. >> >> > On the problems being discussed on testing is the interrupt source >> geting >> > cleared at the SDIO card level upon genaration of the CIRQ? If not it >> remains >> > asserted. >> >> Yes, this seems to be exactly the problem John reports in his follow >> up mail. >> >> Any hint how to clear SDIO interrupt? >> > On the controller side I guess it is cleared when you pass "disable" in the > enable_sdio_irq" fn. This happens when you call mmc_signal_sdio_irq. > > I am not too sure about how it gets disabled from the card side. I see that > SDIO core has a function "sdio_release_irq" which is used by the sdio uart > driver. The usage of this could give a clue. > > Regards, > Madhu > >> Many thanks >> >> Dirk >> >> > + OMAP_HSMMC_WRITE(host->base, HCTL, >> > + OMAP_HSMMC_READ(host->base, HCTL) >> > + | IBG | FOUR_BIT); >> > + } else { >> > + OMAP_HSMMC_WRITE(host->base, HCTL, >> > + OMAP_HSMMC_READ(host->base, HCTL) >> > + | FOUR_BIT); >> > + } >> > break; >> > case MMC_BUS_WIDTH_1: >> > OMAP_HSMMC_WRITE(host->base, CON, con & ~DW8); >> > @@ -1512,6 +1532,24 @@ static int omap_hsmmc_disable_fclk(struc >> > return 0; >> > } >> > >> > +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int >> enable) >> > +{ >> > + struct omap_hsmmc_host *host = mmc_priv(mmc); >> > + u32 ie, ise; >> > + >> > + ise = OMAP_HSMMC_READ(host->base, ISE); >> > + ie = OMAP_HSMMC_READ(host->base, IE); >> > + >> > + if (enable) { >> > + OMAP_HSMMC_WRITE(host->base, ISE, ise | CIRQ_ENABLE); >> > + OMAP_HSMMC_WRITE(host->base, IE, ie | CIRQ_ENABLE); >> > + } else { >> > + OMAP_HSMMC_WRITE(host->base, ISE, ise & ~CIRQ_ENABLE); >> > + OMAP_HSMMC_WRITE(host->base, IE, ie & ~CIRQ_ENABLE); >> > + } >> > + >> > +} >> > + >> > static const struct mmc_host_ops omap_hsmmc_ops = { >> > .enable = omap_hsmmc_enable_fclk, >> > .disable = omap_hsmmc_disable_fclk, >> > @@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hs >> > .set_ios = omap_hsmmc_set_ios, >> > .get_cd = omap_hsmmc_get_cd, >> > .get_ro = omap_hsmmc_get_ro, >> > - /* NYET -- enable_sdio_irq */ >> > + .enable_sdio_irq = omap_hsmmc_enable_sdio_irq, >> > }; >> > >> > static const struct mmc_host_ops omap_hsmmc_ps_ops = { >> > @@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hs >> > .set_ios = omap_hsmmc_set_ios, >> > .get_cd = omap_hsmmc_get_cd, >> > .get_ro = omap_hsmmc_get_ro, >> > - /* NYET -- enable_sdio_irq */ >> > + .enable_sdio_irq = omap_hsmmc_enable_sdio_irq, >> > }; >> > >> > #ifdef CONFIG_DEBUG_FS >> > @@ -1734,7 +1772,7 @@ static int __init omap_hsmmc_probe(struc >> > mmc->max_seg_size = mmc->max_req_size; >> > >> > mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED | >> > - MMC_CAP_WAIT_WHILE_BUSY; >> > + MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_SDIO_IRQ; >> > >> > if (mmc_slot(host).wires >= 8) >> > mmc->caps |= MMC_CAP_8_BIT_DATA; >> > >> > >> > >> > >> > >> >> John Rigby wrote: >> >>> I have seen several discussions about lack of sdio irq support in the >> >>> hsmmc driver but no patches. Has anyone on this list implemented this >> >>> and/or can anyone point me to patches? >> >> What a coincidence ;) >> >> >> >> I'm currently working on this. See attachment what I currently have. >> >> It is compile tested only against recent omap linux head. I don't have >> >> a board using SDIO at the moment, so no real testing possible :( >> >> >> >> Some background, maybe it helps people to step in: >> >> >> >> Gumstix OMAP3 based Overo air board connects Marvell 88W8686 wifi by >> >> MMC port 2 in 4 bit configuration [1]. The wifi performance is quite >> >> bad (~100kB/s). There is some rumor that this might be SDIO irq >> >> related [2]. There was an attempt to fix this [3] already, but this >> >> doesn't work [4]. Having this, I started to look into it. >> >> >> >> I used [3], the TI Davinci driver [5] (supporting SDIO irq), the SDIO >> >> Simplified Specification [6] and the OMAP35x TRM [7] as starting >> points. >> >> >> >> Unfortunately, the Davinci MMC registers and irqs are different >> >> (Davinci has a dedicated SDIO irq). But combining [3] and [5] helps to >> >> get an idea what has to be done. >> >> >> >> I think the main issues of [3] were that it doesn't enable IBG for 4 >> >> bit mode ([6] chapter 8.1.2) and that mmc_omap_irq() doesn't reset the >> >> irq bits. >> >> >> >> Topics I still open: >> >> >> >> - Is it always necessary to deal with IE _and_ ISE register? I'm not >> >> totally clear what the difference between these two registers are ;) >> >> And in which order they have to be set. >> >> >> >> - Davinci driver [5] in line 1115 checks for data line to call >> >> mmc_signal_sdio_irq() for irq enable. >> >> >> >> - Davinci driver deals with SDIO in xfer_done() (line 873) >> >> >> >> - Davinci driver sets block size to 64 if SDIO in line 701 >> >> >> >> It would be quite nice if anybody likes to comment on attachment and >> >> help testing. >> >> >> >> Many thanks and best regards >> >> >> >> Dirk >> >> >> >> [1] http://gumstix.net/wiki/index.php?title=Overo_Wifi >> >> >> >> [2] http://groups.google.com/group/beagleboard/msg/14e822778c5eeb56 >> >> >> >> [3] http://groups.google.com/group/beagleboard/msg/d0eb69f4c20673be >> >> >> >> [4] http://groups.google.com/group/beagleboard/msg/5cdfe2a319531937 >> >> >> >> [5] >> >> http://arago-project.org/git/projects/?p=linux- >> davinci.git;a=blob;f=drivers/mmc/host/davinci_mmc.c;h=1bf0587250614c6d8abf >> e02028b96e0e47148ac8;hb=HEAD >> >> >> >> [6] http://www.sdcard.org/developers/tech/sdio/sd_bluetooth_spec/ >> >> >> >> [7] http://focus.ti.com/lit/ug/spruf98c/spruf98c.pdf >> >> >> >> >> > >> > >> > >> > > > -- 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
