Re: Power-managing devices that are not of interest at some point in time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2014-07-19 01:16, Dmitry Torokhov wrote:
<snip>
I'd say no.

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...

Seriously complicated. The compositor and/or X.org can handle most of that for input devices already. For the camera, you want the application to know that the device is present, but not usable, instead of making it vanish or rendering it unusable. And if you wanted to implement this in the kernel, even with the aid of a user-space daemon, you're still missing the most important part, the device
tagging.

Once you've tagged the devices which would need to be left alone when the lid is closed, or the laptop is in tablet mode, see if the problem can be solved within user-space alone. I'm fairly certain it wouldn't take too long to fix Xorg
or a state-of-the-art compositor to behave properly.

All I see right now is making it harder to write devices drivers with no real benefits.

Cheers
--
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




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux