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. > > > Nicolas > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
