PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1

[Rafael J. Wysocki]

On Wed, Feb 3, 2016 at 11:25 AM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>>
>> I don't see the problem, but of course you know omap for better than I do.
>>
>> So if you are concerned about this, perhaps adding a dev_dbg print
>> when the omap hwmod's ->runtime_suspend() callback returns zero could
>
> /s/runtime_suspend/runtime_resume

OK

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.

The introduction of pm_runtime_reinit() changed the situation and now
effectively the hardware is required to be reset to the initial state
if -EPROBE_DEFER is to be returned too.

Is that correct?

Thanks,
Rafael