| Message ID | 1346764109-21174-1-git-send-email-gururaja.hebbar@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja <gururaja.hebbar@ti.com> wrote: > From: Vaibhav Bedia <vaibhav.bedia@ti.com> > > In some cases mmc_suspend_host() is not able to claim the > host and proceed with the suspend process. The core returns > -EBUSY to the host controller driver. Unfortunately, the > host controller driver does not pass on this information > to the PM core and hence the system suspend process continues. > > In these cases the MMC core gets to an unexpected state > during resume and multiple issues related to MMC crop up. > 1. Host controller driver starts accessing the device registers > before the clocks are enabled which leads to a prefetch abort. > 2. A file copy thread which was launched before suspend gets > stuck due to the host not being reclaimed during resume. > > To avoid such problems pass on the -EBUSY status to the PM core > from the host controller driver. With this change, MMC core > suspend might still fail but it does not end up making the > system unusable. Suspend gets aborted and the user can try > suspending the system again. > The last time we discussed this, didn't we plan to fix this differently ? Holding the return code of mmc_suspend_host in a separate variable and passing it to the caller of omap_hsmmc_suspend looks more sane to me. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote: > On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja <gururaja.hebbar@ti.com> wrote: > > From: Vaibhav Bedia <vaibhav.bedia@ti.com> > > > > In some cases mmc_suspend_host() is not able to claim the > > host and proceed with the suspend process. The core returns > > -EBUSY to the host controller driver. Unfortunately, the > > host controller driver does not pass on this information > > to the PM core and hence the system suspend process continues. > > > > In these cases the MMC core gets to an unexpected state > > during resume and multiple issues related to MMC crop up. > > 1. Host controller driver starts accessing the device registers > > before the clocks are enabled which leads to a prefetch abort. > > 2. A file copy thread which was launched before suspend gets > > stuck due to the host not being reclaimed during resume. > > > > To avoid such problems pass on the -EBUSY status to the PM core > > from the host controller driver. With this change, MMC core > > suspend might still fail but it does not end up making the > > system unusable. Suspend gets aborted and the user can try > > suspending the system again. > > > > The last time we discussed this, didn't we plan to fix this differently ? > Holding the return code of mmc_suspend_host in a separate variable and > passing it to the caller > of omap_hsmmc_suspend looks more sane to me. Correct. I missed it. I will reformat the patch and resend it. > Regards, Gururaja -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote: > On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja <gururaja.hebbar@ti.com> wrote: > > From: Vaibhav Bedia <vaibhav.bedia@ti.com> > > > > In some cases mmc_suspend_host() is not able to claim the > > host and proceed with the suspend process. The core returns > > -EBUSY to the host controller driver. Unfortunately, the > > host controller driver does not pass on this information > > to the PM core and hence the system suspend process continues. > > > > In these cases the MMC core gets to an unexpected state > > during resume and multiple issues related to MMC crop up. > > 1. Host controller driver starts accessing the device registers > > before the clocks are enabled which leads to a prefetch abort. > > 2. A file copy thread which was launched before suspend gets > > stuck due to the host not being reclaimed during resume. > > > > To avoid such problems pass on the -EBUSY status to the PM core > > from the host controller driver. With this change, MMC core > > suspend might still fail but it does not end up making the > > system unusable. Suspend gets aborted and the user can try > > suspending the system again. > > > > The last time we discussed this, didn't we plan to fix this differently ? > Holding the return code of mmc_suspend_host in a separate variable and > passing it to the caller > of omap_hsmmc_suspend looks more sane to me. I just pushed a new revision (V2) with above changes. I also added extra information (explanation with code snippet). Kindly let me know your review for the same. > Regards, Gururaja -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 9afdd20..c3e96a2 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2054,6 +2054,7 @@ static int omap_hsmmc_suspend(struct device *dev) if (ret) dev_dbg(dev, "Unmask interrupt failed\n"); } + ret = -EBUSY; goto err; }