Thread (74 messages) 74 messages, 5 authors, 2016-02-05

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

From: Ulf Hansson <hidden>
Date: 2016-02-04 10:20:03
Also in: linux-omap, linux-pm

On 3 February 2016 at 18:18, Rafael J. Wysocki [off-list ref] wrote:
On Wed, Feb 3, 2016 at 12:46 AM, Tony Lindgren [off-list ref] wrote:
quoted
* Alan Stern [off-list ref] [160202 13:46]:
quoted
On Tue, 2 Feb 2016, Tony Lindgren wrote:
quoted
quoted
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 [off-list ref]
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help