On Mon, 30 Nov 2009, Ferenc Wagner wrote:

quoted

quoted

Also, it is not really runtime PM but rather user-initiated action of
putting device into lower power state we are talking about here.

This is in fact the definition of runtime PM -- except for the
"user-initiated" restriction (runtime PM can be initiated by anything
or anybody).  So it really _is_ runtime PM.

But runtime-pm.txt says for example:

    Generally, remote wake-up should be enabled for all input devices
    put into a low power state at run time.

But in this case the requirement is to suppress input events from a
given device, effectively muting and putting it into low power state,
even though it's still open by some other parties.  Runtime PM, on the
other hand tries not to interfere with the normal usage of the device.

That's why the text says "Generally".  You're free to do it a different 
way if you want.

Later:

(3) ->runtime_idle() and ->runtime_suspend() can only be executed for a
    device the usage counter of which is equal to zero _and_ [...]

which underlines the difference again: the usage counter (defined by
common sense) won't be zero in our case, because the device is
constantly kept open, while we want to mute it, putting it into a low
power state.  Probably, the rules could be bent so that the platform bus
could suspend these devices and achieve our aim, but I'd consider that
an abuse of the runtime PM infrastructure.  Don't you?

The usage counter can be set whenever you want; it doesn't have to be 
incremented during open and decremented during close.  You could leave 
it equal to 0 permanently.  Or you could make it nonzero precisely 
during the times when you don't want the input to be muted.

Actually, this could be implemented by the various users cooperating in
closing the device, letting it go to sleep automatically.  But this
requires strictly cooperating parties and is more complicated that
flipping some master switch of the device.  We're looking for this
master switch, before needlessly building our own.

Just out of curiosity, how do you decide when the input should be 
muted and unmuted?

quoted

But if you prefer to implement it without using the runtime PM 
framework, that's fine.

We're also looking for a framework to implement it in.  Now I feel like
the runtime PM framework is not a good fit for what we want, but it's
the first time I'm reading its documentation, so please correct my
misunderstandings.  That's why I cross posted linux-pm, after all. :)

The framework was intended to be pretty flexible.  You should think it 
over a little more before deciding against it.

Alan Stern