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

[Ulf Hansson]

On 3 February 2016 at 13:18, Rafael J. Wysocki <rafael at kernel.org> wrote:
> 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.

Correct!

Before pm_runtime_reinit(), the failing probe case (-EPROBE_DEFER)
worked fine because the HW state and the runtime PM status was in
sync. The device was powered and the runtime PM status was RPM_ACTIVE.

>
> 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.

Not correct. The hardware doesn't need a reset as it stays powered
after a failed probe.

Instead, only the runtime PM status needs to be synchronized with the
HW state the next probe attempt.

In other words, when the PM domain's ->runtime_resume() callbacks gets
called due to a pm_runtime_get_sync() in the second probe attempt, it
may find that the HW is already powered and can return zero instead of
resetting it.

Kind regards
Uffe