On Wed, Feb 3, 2016 at 5:24 PM, Ulf Hansson [off-list ref] wrote:

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

quoted

* Alan Stern [off-list ref] [160203 07:46]:

quoted

On Wed, 3 Feb 2016, Ulf Hansson wrote:

quoted

quoted

Let me summarize my understanding of this thread so far.

It looks like the omap3 code initializes hardware in ->probe() and
then it may return -EPROBE_DEFER due to some unmet dependencies.  In
that case the hardware is not reset to the previous state and the
runtime PM framework is left in the state that corresponds to the
current hardware state.  Before we had pm_runtime_reinit(), everything
worked as expected on the second ->probe() call, because things were
in sync then.

Correct!

Well not quite correct. After failed probe PM runtime is set to reset
state while hardware is still enabled.

Yes, but that's *after* pm_runtime_reinit() was added.

I think Rafael was thinking about how it worked *before*.

Right.

Thanks,
Rafael