[PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit

[Tony Lindgren]

* Ulf Hansson <ulf.hansson at linaro.org> [160211 07:14]:
> On 11 February 2016 at 16:02, Tony Lindgren <tony at atomide.com> wrote:
> > * Ulf Hansson <ulf.hansson at linaro.org> [160211 02:19]:
> >> On 11 February 2016 at 00:02, Tony Lindgren <tony at atomide.com> wrote:
> >> >
> >> > Ulf, I'd like to merge this along with other related fixes via the
> >> > ARM SoC tree if no objections, please review and ack if this look OK
> >> > to you.
> >>
> >> I have some other omap_hsmmc patches queued for 4.6, so I prefer to
> >> send this via my mmc tree.
> >>
> >> I guess that's okay as well!?
> >
> > Naturally yes, please go ahead thanks!
> 
> Okay!
> 
> BTW, did you notice my other comments to the patch?
> 
> I can fix them before applying, unless you want to send a v2?

Oh sorry, no I missed the rest of your comments again, I really
need to recalibrate my reading habits obviously if I keep
missing comments on regular basis..

You comments make sense to me. Below is the patch with only
minimal changes. Seems to work just fine and hit off mode for
suspend too.

Regards,

Tony

8< -------------------
>From eb3c93421f01fb6198f76127262a92b527dd214c Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony at atomide.com>
Date: Tue, 9 Feb 2016 09:31:10 -0800
Subject: [PATCH] mmc: omap_hsmmc: Fix PM regression with deferred probe for
 pm_runtime_reinit

Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-mmc at vger.kernel.org
Cc: Alan Stern <stern at rowland.harvard.edu>
Cc: Kevin Hilman <khilman at baylibre.com>
Cc: Nishanth Menon <nm at ti.com>
Cc: Rafael J. Wysocki <rafael at kernel.org>
Cc: Ulf Hansson <ulf.hansson at linaro.org>
Cc: Tero Kristo <t-kristo at ti.com>
Signed-off-by: Tony Lindgren <tony at atomide.com>

--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2232,6 +2232,7 @@ err_irq:
 		dma_release_channel(host->tx_chan);
 	if (host->rx_chan)
 		dma_release_channel(host->rx_chan);
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	if (host->dbclk)
@@ -2253,6 +2254,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
 	dma_release_channel(host->tx_chan);
 	dma_release_channel(host->rx_chan);
 
+	pm_runtime_dont_use_autosuspend(host->dev);
 	pm_runtime_put_sync(host->dev);
 	pm_runtime_disable(host->dev);
 	device_init_wakeup(&pdev->dev, false);