On Fri, Jul 18, 2014 at 04:16:50PM -0700, Dmitry Torokhov wrote:

[...]
Anyway, even though it is very tempting to declare inhibit a "deeper" state of 
runtime suspend maybe you are right and inhibit should really be separate from 
PM and drivers would have to sort out all the possible state permutations.

Considering input devices:

input_open(): check if device is inhibited, if so do nothing. Otherwise try 
waking up itself and parent (via pm_runtime_get_sync() on itself), this will 
power up the device. Do additional configuration if needed.

input_close(): check if device is inhibited, if not do pm_runtime_put (_sync? 
to make sure we power off properly and not leave device up and running? or 
should we power down manually not waiting for runtime PM)?

inhibit(): check if device is opened, if opened do pm_runtime_put_sync().

uninhibit(): if device is opened do pm_runtime_get_sync(), let runtime PM 
bring up the device. Do additional config if needed -> very similar to 
input_open(), different condition.

runtime_suspend(): power down the device. If not inhibited enable as wakeup 
source.

runtime_resume(): power up the device if device is opened and not inhibited.

system_suspend(): check if device is opened, not inhibited and not in 
runtimesuspend  already; power down.

system_resume(): power up the device if it is opened and not inhibited. I 
guess it's OK to wake up device that shoudl be runtime-PM-idle since it will 
go to back sleep shortly.

Ugh.. This is complicated...

There might be more elegant ways to implement this. It might make sense
to factor out power transitions. One could have a function that derives
the appropriate power state given the circumstances (i.e.
suspend/inhibit/runtime suspend) and then performs the needed
transition. This is something one would have to see when actually
implementing this, I might experiment with this approach a bit.

Regards,
Patrik