On Sun, 30 May 2010 13:04:10 -0700 mark gross <640e9920@xxxxxxxxx> wrote: > Low Power Events is a possible alternative to suspend blocker / wake > lock API used by Android. Here is how I see your proposal. It is of course possible that I misunderstood bits, so please correct me where I'm wrong. 1/ You have introduced a new mechanism for requesting a transition to a low power state. This involves writing a number to /dev/lpe_enter. It is not clear to me from your text what the magic number really means. I think this parallels writing to /sys/power/state, but achieves the same result though a different mechanism and adds some extra checking. So: I don't understand the numbers, and I don't see why we need a second way to request a low power state. Probably I missed something important. 2/ Rather than tracking wake-events from the hardware up through possibly several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly. When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure. So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work. 3/ You have created a new mechanism for passing events to user-space. That seems unnecessary. We already have the input subsystem which is pretty good at communication arbitrary events, and the events you are dealing with a very much like input events. So I would suggest modifying your proposal to simply create a new 'input' device. Any driver that supports wake-from-suspend queues an event to that device when a wakeup event occurs. If the device is open and has any queued events, then a suspend request such as 'echo mem > /sys/power/state' completes without going into full suspend. Then you just need to convince us that this mechanism can be used without any race problems. If it can, then it would certainly be a simple and unobtrusive approach. Thanks, NeilBrown _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
