On Tue, 2012-06-26 at 10:34 -0400, Alan Stern wrote:
On Tue, 26 Jun 2012, Grazvydas Ignotas wrote:
quoted
CCing some PM people, maybe they can comment?
On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak [off-list ref] wrote:
quoted
On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
quoted
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