Re: [RFC] lp_events: an lternitive to suspend blocker user modeand kernel API

[mark gross]

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@xxxxxxx> wrote:
> 
> > 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.
> 
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/