Re: [PATCH 2/2] mmc: omap_hsmmc: Enable SDIO interrupt

[Tony Lindgren <tony@atomide.com>]

* Andreas Fenkart <afenkart@gmail.com> [130926 23:46]:
> 
> It's what Balaji already pointed out.
> 
> +   /* no transfer running, need to signal cirq if */
> +   if (host->sdio_irq_en)
> +       irq_mask |= CIRQ_EN;
> 
> 
> omap_hsmmc_request_done calls omap_hsmmc_disable_irq
> 
> imagine this case:
> 1. host issues transfer from host->card (e.g. get RSSI)
> 2. at end of this transfer, SDIO IRQ are being masked
> 3. card wants to reply, raises an SDIO IRQ
> 4. nothing happens, since in 2. SDIO IRQ are masked
> 
> I verified this with my 88W8787 card. It is a problem

OK thanks makes sense. 

> Something like this but shorter as a comment:
> 
> /*
>  * Must not touch registers while fclk if off, otherwise SIGBUS.
>  * Card will still wake up upon SDIO IRQ, and we'll complete
>  * the request in pm_runtime_resume
>  */
> 
> Another interpretation of your code could be:
> 
> /* Sorry I'm having Siesta right now, try later */

Well the clocking issue should be already handled by the
runtime PM, otherwise we have a bug somewhere. I'm almost
certain that no special handling is needed for register
access beyond runtime PM, but it would probably be best
if you could test it.

> Compatible section you mean, that sounds to good to me.
> But do we know platform have the deficiency?
> 
> There used to be an if statement like this in one of your previous
> patches.
> 
> +   if (match) {
> +       mmc->caps |= MMC_CAP_SDIO_IRQ;
> +       if (of_find_property(host->dev->of_node,
> +                    "ti,quirk-swakeup-missing", NULL)) {
> +           /* no wakeup from deeper power states, use polling */
> +           mmc->caps &= ~MMC_CAP_SDIO_IRQ;
> +       }
> +   }
> 
> Either or is needed, otherwise existing platforms will break, and will have
> to apply patches on top of yours to reenable polling (e.g. beaglebone)

Yes, let's merge the necessary tweaks to this patch before
applying. The SDIO interrupt should work during runtime
for all omaps, so maybe we should just ensure that runtime
PM keeps those omaps from going to deeper idle modes for
now.

Regards,

Tony