PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1
From: stern@rowland.harvard.edu (Alan Stern)
Date: 2016-02-01 23:49:47
Also in:
linux-omap, linux-pm
On Mon, 1 Feb 2016, Tony Lindgren wrote:
quoted hunk ↗ jump to hunk
Does the patch below make more sense to you where we call rpm_idle? That seems to make things behave here also.quoted
quoted
What else does __pm_runtime_use_autosuspend() set initially that changes things here?The usage counter, if the delay is negative.Yeah I don't see any difference with those.quoted
I'll look at this in detail, but not right now, sorry. I'm working on something else ATM and I was hoping that Ulf would be able to figure out what's going on here.Yeah we need to understand what's going on here. Having the PM runtime framework out of sync with the hardare is not good.. If we can't figure this out we should probably revert the patch until we understand it. Regards, Tony 8< --------------- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c@@ -1419,17 +1419,28 @@ void pm_runtime_init(struct device *dev) */ void pm_runtime_reinit(struct device *dev) { - if (!pm_runtime_enabled(dev)) { - if (dev->power.runtime_status == RPM_ACTIVE) + int (*callback)(struct device *); + int err; + + if (pm_runtime_enabled(dev)) + return; + + if (dev->power.runtime_status == RPM_ACTIVE) { + if (dev->power.use_autosuspend) { + __pm_runtime_use_autosuspend(dev, false); + rpm_idle(dev, RPM_AUTO);
You get here only if runtime PM is disabled, right? So the rpm_idle call won't do anything -- "disabled" means don't make any callbacks. Tony, exactly what are you trying to do here? Do you want this to invoke a runtime-PM callback in the subsystem, power domain, or driver? (Is there even a driver bound to the device when this function runs?) The function's name suggests that it merely resets the data stored in dev->power without actually touching the hardware. Is that what you really want? Alan Stern