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

[Ulf Hansson]

On 3 February 2016 at 18:18, Rafael J. Wysocki <rafael at kernel.org> wrote:
> On Wed, Feb 3, 2016 at 12:46 AM, Tony Lindgren <tony at atomide.com> wrote:
>> * Alan Stern <stern at rowland.harvard.edu> [160202 13:46]:
>>> On Tue, 2 Feb 2016, Tony Lindgren wrote:
>>>
>>> > > Also, what is autosuspend_delay set to for your device?  And is
>>> > > runtime_auto set?
>>> >
>>> > It's 100 at that point, see the commented snippet below from
>>> > omap_hsmmc_probe():
>>> >
>>> >     pm_runtime_enable(host->dev);
>>> >     pm_runtime_get_sync(host->dev);
>>> >     pm_runtime_set_autosuspend_delay(host->dev, MMC_AUTOSUSPEND_DELAY);
>>> >     /* NOTE: pm_runtime_dont_use_autosuspend(host->dev) needed here? */
>>> >     pm_runtime_use_autosuspend(host->dev);
>>> >     ...
>>> >     /* gets -EPROBE_DEFER */
>>> > err_irq:
>>> >     ...
>>> >     pm_runtime_put_sync(host->dev);
>>>
>>> You could try changing this to pm_runtime_put_sync_suspend().  But
>>> putting pm_runtime_dont_use_autosuspend() before the put_sync seems
>>> like a perfectly reasonable thing to do, especially if you feel you
>>> should reverse all the changes you made at the start.
>
> FWIW, I'd call pm_runtime_dont_use_autosuspend() before put_sync().
>
> After all, the driver doesn't want to use autosuspend going forward,
> so stating that explicitly looks like the right thing to do.

Just wanted to add yet some new findings while I was looking into this
regression.

So, the reason why pm_runtime_put_sync() doesn't idle the device in
these cases, is because autosuspend is respected and for some reason
the autosuspend timer hasn't expired.
I was wondering *why* the timer isn't considered as expired, because
the driver don't call pm_runtime_mark_last_busy() in the failing probe
case...

Then I realized the following commit was merged a few releases ago,
which makes the runtime PM core to invoke pm_runtime_mark_last_busy()
for us.

commit 56f487c78015936097474fd89b2ccb229d500d0f
Author: Tony Lindgren <tony at atomide.com>
Date:   Wed May 13 16:36:32 2015 -0700
PM / Runtime: Update last_busy in rpm_resume

So, this commit actually causes the devices to stay active after a
failed probe attempt.

I think it's a good idea to revert this change, but what to you think?

Kind regards
Uffe