PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1
From: tony@atomide.com (Tony Lindgren)
Date: 2016-02-02 18:05:56
Also in:
linux-omap, linux-pm
From: tony@atomide.com (Tony Lindgren)
Date: 2016-02-02 18:05:56
Also in:
linux-omap, linux-pm
* Tony Lindgren [off-list ref] [160202 08:50]:
* Alan Stern [off-list ref] [160202 08:17]:quoted
? 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);