On Fri, Jun 10, 2011 at 09:52:09AM +0300, Tomi Valkeinen wrote:

On Fri, 2011-06-10 at 05:03 +0900, Paul Mundt wrote:

quoted

the use in the error paths and so on you will definitely need to be using
pm_runtime_put_sync() at least some of the time.

Hmm, why is that? When the user of, say, dispc, has finished with it and
calls dispc_runtime_put(), the caller shouldn't care if the HW is
actually turned off now or later.

Ah, I forgot that pm_runtime_disable() already does the synchronous bits
for you, so you get lucky that way. I was concerned about the race
between the work queue and the device pointer going away, but this is
already handled by the subsystem via __pm_runtime_barrier() in the
disable path.

pm_runtime_put() can return an error value, but my wrappers discard it,
as I don't know in which situations it could happen, and what could the
driver do about it. If the HW cannot be turned off now, why could it be
turned off later, and when would that be?

The return value is primarily aimed at informing you whether it was able
to idle the device, whether there were already pending requests, etc. If
you're in an exit path you're probably not too concerned with this.

If you have some alternate means of cutting power to the block unrelated
to runtime pm based clock control you can use the return value as a
sanity measure to error out before inadvertently cutting power out
underneath another user.