* Ulf Hansson [off-list ref] [160202 12:48]:

On 2 February 2016 at 17:35, Tony Lindgren [off-list ref] wrote:

quoted

That's a valid error though, let's not remove it. The reason why we
call runtime_resume() twice is because runtime_suspend callback never
gets called like I explain above.

This isn't an error, it's just a hickup in the synchronization of the
runtime PM status.

I'd rather not get the hardware state out of sync with PM runtime..

Very similar what happens at the first probe, when the driver core has
initialized the runtime PM status to RPM_SUSPENDED at the device
registration.

Well we actually pretty much have devices in that state to start
with.

To me, it's the responsible of the PM domain to *help* with the
synchronization, not prevent it as it currently does.

The problem is that the hardware state gets out of sync with
PM runtime. And that's going to be a pain to debug later on.

quoted

--- 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);

It's good know this works, although do you intend to fix this sequence
for all omap drivers/devices that's part of the hwmod PM domain?

I haven't checked the number of drivers this would affect, but I
imagine there could be quite many with similar behaviour and thus may
suffer from the same issue.

Yeah not sure what the right fix is. But I'd rather patch the
few drivers using autosuspend if we come to the conclusion
that there is no bug in PM runtime.

Could you please test my version 2 of the patch I attached earlier. I
still believe it's the best way to solve the regression, if it works
of course. :-)

And I don't like it because of the reasons above :) But yeah
gave it a quick try and that too works as expected.

Regards,

Tony