PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1
Tony Lindgren
tony at atomide.com
Tue Feb 2 10:05:56 PST 2016
* Tony Lindgren <tony at atomide.com> [160202 08:50]:
> * Alan Stern <stern at rowland.harvard.edu> [160202 08:17]:
>
> > ? pm_runtime_put_sync() _already_ does not respect the autosuspend
> > mode. If you want to respect it, you have to call
> > pm_runtime_put_sync_autosuspend() instead.
>
> I think you found the real bug there. So the right fix is to
> call pm_runtime_put_sync_autosuspend() at the end of failed
> probe in omap_hsmmc. Let me give that a try here.
Nope that's not it but getting closer.
The following seems to make things behave for me. Now the
question is.. Does it have some undesired side effects?
> Can we add some warning to pm_runtime_put_sync() about that?
Probably no need for that, I misunderstood the meaning of
pm_runtime_put_sync_autosuspend().
Regards,
Tony
8< --------------
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -435,7 +435,7 @@ static int rpm_suspend(struct device *dev, int rpmflags)
goto out;
/* If the autosuspend_delay time hasn't expired yet, reschedule. */
- if ((rpmflags & RPM_AUTO)
+ if (((rpmflags & (RPM_ASYNC | RPM_AUTO)) == ((RPM_ASYNC | RPM_AUTO)))
&& dev->power.runtime_status != RPM_SUSPENDING) {
unsigned long expires = pm_runtime_autosuspend_expiration(dev);
More information about the linux-arm-kernel
mailing list