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

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

* 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);
 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help