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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
