PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1
Tony Lindgren
tony at atomide.com
Thu Feb 4 09:20:25 PST 2016
* Alan Stern <stern at rowland.harvard.edu> [160204 08:05]:
> On Thu, 4 Feb 2016, Ulf Hansson wrote:
>
> > 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.
>
> No doubt the autosuspend delay is longer than the time it takes for a
> probe to fail.
>
> > 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?
>
> I disagree. The whole idea of autosuspend is to prevent the device's
> power state from bouncing up and down too rapidly. This implies that
> whenever the device gets resumed, we should wait at least the minimum
> autosuspend delay before allowing the next autosuspend.
Yeah let's not revert 56f487c78015. Without that we have devices
falling right back to sleep.
Regards,
Tony
More information about the linux-arm-kernel
mailing list