On Mon, 31 Oct 2011, Jun Nie wrote: > 2011/10/31 Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>: > > On Mon, 31 Oct 2011, Jun Nie wrote: > > > >> Hi Nico, > >> We are debugging fake SDIO irq when 8787 SDIO card resume and > >> found below patch. The issue is that 8787 driver can not handle card > >> irq if neither 8787 nor host trigger resume event in some cases. Do > >> you remember what SDIO card need below patch? What's your idea on this > >> issue? How about add a SDIO function flag to decide the irq thread > >> kick off in resume? > > > > This is needed because in some cases the card interrupt is already > > consumed for the wake-up event. Kicking this thread shouldn't cause any > > issue though, as the card is just polled for the actual presence of an > > IRQ ... > > > > ... or maybe not. In this case commit 06e8935feb "optimized SDIO IRQ > > handling for single irq" may certainly cause problems. > > > > The fix here would be to clear card->sdio_single_irq before calling > > mmc_signal_sdio_irq() in mmc_sdio_resume() and restore its original > > value eventually, or better yet ignore that flag when the IRQ thread is > > ran for the first time after a resume. > 8787 case(bug) is similar with sdio_signel_irq case, but not same. > 8787 can not response to reading sdio card interrupt status correctly > if 8787 is still in suspend mode. The read operation will get value of > previous CMD52 read, no matter previous CMD52 is for what purpose. So > host should avoid read from 8787 before call sdio function resume in > normal resume process. Otherwise, 8787 may lead lead host to handle > fake interrupt and result further error. > > > > In any case you may disable that optimization in the IRQ demux handler > > to see if this fixes your problem. > So the fix to 8787 is either adding a flag, such as NO_LOST_WAKEUP_IRQ > for func/card, or moving kick off to after sdio function resume. I do > not know which one you prefer. Moving the kick-off after the resume will be a good thing, and it should also be conditional on the presence of CCCR_INTx being non zero. Nicolas
