lp_events: an lternitive to suspend blocker user mode and kernel API
in [Kernel]
|
Prev: resource piix4_smbus conflicts with ACPI region SMRG
Next: [Regression] [2.6.35-rc1][suspend to ram] BUG: using smp_processor_id() in preemptible [00000000] code: cat/3634
From: mark gross on 31 May 2010 18:20 On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote: > On Sun, 30 May 2010 13:04:10 -0700 > mark gross <640e9920(a)gmail.com> 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. You are not missing much. Those numbers where an attempt at generalization for the level of suspend that could be requested by user mode. The semantics of what I'm talking about are different form /sys/power/state even though they both enter low power states. > > 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. yeah, I think it needs some prototyping too. > 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. You suggest below adding a input class for wakeups. I think using that would make sense. > So: I like the idea of leaving the intermediate layers unchanged, but I'm > not convinced it would work. > I'm not fully convinced yet either, but I still think it could 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. really good idea! > 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. /me likes. > 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. Lets find out. --mgross > > Thanks, > NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: mark gross on 31 May 2010 18:30 On Mon, May 31, 2010 at 08:43:56AM +0200, Florian Mickler wrote: > On Mon, 31 May 2010 09:57:53 +1000 > Neil Brown <neilb(a)suse.de> wrote: > > > On Sun, 30 May 2010 13:04:10 -0700 > > mark gross <640e9920(a)gmail.com> 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. > > I can only think for lpe to provide the levels and have userspace and > platform code hook into there. Else you would have a dependency from > userspace to platform code. > > > > > 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. > > To add to this: Is it a correct assumption > that all wake-up events that leave a driver trickle eventually up to > userspace? > > I think splitting the actual driver product (i.e. keypress or whatever) > of a wake-up-event and it's corresponding wake-lock is not possible. > Because you would have to _somehow_ map the block back to the product > when you consume the product. its only possible if you require a user mode transition after a wake up before re-entry into the suspend / low power state. I think kernel mode initiated suspends are problematic. > If you want to abstract the blocking from the kernel-code you probably > have to introduce an abstract "driver-product" entity where you can do > all your blocking associated with the product but hidden from the code > that uses the product. (Which I don't think is feasible, because it > increases overhead) > > Or am I on the wrong track here? maybe a little. blocking low power entry and the handling of the unblocking as an event is orthogonal to wake event notification and handling and the coupling of the next entry into the low power state.. Much of these discussions are conflating these two notions. first blocking from the kernel mode *is* needed. My poster child for this is the moorestown OTG hardware. If we attempt a suspend while attached to a host the device hangs. there is a real need for blocking suspend attempts from kernel mode. How to handle the event of unblocking is one of the two main issues. (the other being wake event handling.) > cheers, > Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: mark gross on 31 May 2010 18:50 On Mon, May 31, 2010 at 10:05:45AM +0200, Florian Mickler wrote: > On Mon, 31 May 2010 08:43:56 +0200 > Florian Mickler <florian(a)mickler.org> wrote: > > > On Mon, 31 May 2010 09:57:53 +1000 > > Neil Brown <neilb(a)suse.de> wrote: > > > > > 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. > > > > To add to this: Is it a correct assumption > > that all wake-up events that leave a driver trickle eventually up to > > userspace? > > > > I think splitting the actual driver product (i.e. keypress or whatever) > > of a wake-up-event and it's corresponding wake-lock is not possible. > > Because you would have to _somehow_ map the block back to the product > > when you consume the product. > > > > If you want to abstract the blocking from the kernel-code you probably > > have to introduce an abstract "driver-product" entity where you can do > > all your blocking associated with the product but hidden from the code > > that uses the product. (Which I don't think is feasible, because it > > increases overhead) > > > > Or am I on the wrong track here? > > I just realized, that you can cancel lpe_blocks via delete_lpe_block(), > so this is not an issue at all. > They can be used just like suspend blockers. > > Also the mapping of lpe_block to "wake event" is the same problem as > with the suspend_blockers... > > So I don't think this is a bad idea after all. It decouples the > suspend_blockers from "suspend" quite nicely. > Although it still is only "block" or "no block" and not, as was > suggested some sort of more fine grained requirement definition. I attempted to add level's of blocking but I honestly don't see a use for the levels at the moment. I'm sure there is some better genralization possible. --mgross > Cheers, > Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: mark gross on 31 May 2010 19:10
On Mon, May 31, 2010 at 02:55:16AM -0700, Arve Hj�nnev�g wrote: > On Sun, May 30, 2010 at 1:04 PM, mark gross <640e9920(a)gmail.com> wrote: > > Low Power Events is a possible alternative to suspend blocker / wake > > lock API used by Android. > > > > It provides comparable power state notification and kernel mode critical > > section definition. �It differs from suspend blocker in that: > > 1) it is a platform and device independent implementation. �Device > > specific code is register as lp_ops, similar to pm_ops. �Drivers use > > the platform independent functions. > > > How is this more platform independent than suspend blockers? You don't have to do "suspend to ram" for the low power mode and one could could entertain something different form S2R. > > 2) it forces a user mode transition coming out of a LP state. > > Notification of wake up sources go to the user mode process managing the > > lp states. �Notification of blocked LP state entry is through an > > error return, and notification of un-blocking is through a file node as > > well. > > > If you want a user mode transition for every resume, you can easily > get this with the opportunistic suspend patchset by sending an input > event (or other a custom event with that blocks suspend) from a > driver's resume hook. the input event thing looks like a way to go. > > I think the change need to the Google Android user mode power handling > > code can be limited to changes to _only_ > > "hardware/libhardware_legacy/power/power.c" > > > > This code is still just a prototype of the platform independent code, > > and I'm implementing it on Eclair for the Intel Moorestown platform this > > weekend. �I'll have patches to eclair and updated kernel patches that > > enable this sometime Monday, after I bring it up on my target device. > > Hopefully by the end of next week I think I'll have it working well with > > Android. > > > > At this time the following patch is only known to compile. �I send it to > > help with the discussion. > > > > FWTW I do work on Android at Intel and I think I can make this work. > > (well, today I do.) > > > > --mgross > > > > Draft kernel patch : > > > ... > > + > > +/dev/lpe_wake_event: > > +reads from this returns a list of wake events that happened between entry > > +into the LP state and the return from the read of the low_power_enter device > > +node. �User mode is expected to do something with these events before > > +re-trying to enter low power mode. > > + > > I don't think this will work very well. Multiple input events can be > pending at the same time. If you register a single wake-event for an > input device, you don't know if all the events have been read when you > try to clear this wake-event. > whats important, to me at least, is that uppon wakeup some entity in user mode makes a choice on when to re-enter suspend. --mgross -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |