From: mark gross <640e9920@gmail.com>
To: "Arve Hjønnevåg" <arve@android.com>
Cc: markgross@thegnar.org, Thomas Gleixner <tglx@linutronix.de>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Brian Swetland <swetland@google.com>,
linux-pm@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>,
mark.gross@intel.com
Subject: Re: [RFC] lp_events: an lternitive to suspend blocker user mode and kernel API
Date: Mon, 31 May 2010 16:03:44 -0700 [thread overview]
Message-ID: <20100531230343.GE31155@gvim.org> (raw)
In-Reply-To: <AANLkTilPCxcVhcxEyLSixAoOs-ujXzzkSq8cAOE-5Nsz@mail.gmail.com>
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@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
prev parent reply other threads:[~2010-05-31 23:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-30 20:04 [RFC] lp_events: an lternitive to suspend blocker user mode and kernel API mark gross
2010-05-30 23:57 ` Neil Brown
2010-05-31 6:43 ` Florian Mickler
2010-05-31 8:05 ` Florian Mickler
2010-05-31 22:43 ` mark gross
2010-05-31 22:26 ` mark gross
2010-05-31 22:10 ` mark gross
2010-05-31 22:45 ` Rafael J. Wysocki
2010-06-01 5:09 ` [linux-pm] " mark gross
2010-06-01 5:24 ` Arve Hjønnevåg
2010-06-01 14:01 ` mark gross
2010-06-02 3:10 ` Arve Hjønnevåg
2010-06-02 3:24 ` Gross, Mark
2010-06-02 4:26 ` Arve Hjønnevåg
2010-05-31 9:55 ` Arve Hjønnevåg
2010-05-31 23:03 ` mark gross [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100531230343.GE31155@gvim.org \
--to=640e9920@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arve@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mark.gross@intel.com \
--cc=markgross@thegnar.org \
--cc=rjw@sisk.pl \
--cc=swetland@google.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox