Message-ID: <20100531095753.4c174f2d@notabene.brown>
Date:	Mon, 31 May 2010 09:57:53 +1000
From:	Neil Brown <neilb@...e.de>
To:	markgross@...gnar.org
Cc:	640e9920@...il.com, Thomas Gleixner <tglx@...utronix.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Brian Swetland <swetland@...gle.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>, mark.gross@...el.com
Subject: Re: [RFC] lp_events: an lternitive to suspend blocker user mode and
 kernel API

On Sun, 30 May 2010 13:04:10 -0700
mark gross <640e9920@...il.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.

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

Powered by blists - more mailing lists