On Tue, 2012-06-26 at 10:34 -0400, Alan Stern wrote: > On Tue, 26 Jun 2012, Grazvydas Ignotas wrote: > > > CCing some PM people, maybe they can comment? > > > > On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak <rna...@ti.com> wrote: > > > On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote: > > >> > > >> Do you know how the drivers should handle CONFIG_PM_RUNTIME=n? > > >> Are they supposed to handle the error values returned by runtime PM > > >> functions somehow, or should they use #ifdef CONFIG_PM_RUNTIME? > > > > > > hmm, I always though with CONFIG_RUNTIME_PM=n, the functions would > > > be stubbed to return success and not failure. > > Not exactly. They are stubbed to indicate that the device cannot be > suspended, that it is always active. > > Failure to suspend a device should not be regarded as particularly bad, > because it doesn't affect the device's functionality. That's true even > when CONFIG_RUNTIME_PM is enabled.
This makes sense. So if CONFIG_RUNTIME_PM=n, using pm_runtime_get_sync() will return 1, meaning the HW is already enabled, and using pm_runtime_put_sync() will return -ENOSYS, meaning the hardware cannot be suspended. With CONFIG_RUNTIME_PM=y, it's a bit more complex. If I read the code correctly, when I call pm_runtime_get_sync(), the usage counter is always increased, even if the pm_runtime_resume() fails. So a get() needs to be always matched with a put(), even if get() has returned an error. But if pm_runtime_get_sync() returns an error, it means the HW has not been resumed successfully, and is not operational, so the code should bail out somehow. So basically I'd use this kind of pattern everywhere I use pm_runtime_get_sync(): --- r = pm_runtime_get_sync(dev); if (r < 0) { pm_runtime_put_sync(dev); /* handle error */ return -ESOMETHING; } /* do the work */ pm_runtime_put_sync(dev); --- Is this correct? Tomi
signature.asc
Description: This is a digitally signed message part