lkml.org 
[lkml]   [2010]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/8] PM: Opportunistic suspend support.
On Tue, 25 May 2010, Dmitry Torokhov wrote:

> > > What you describe can be done in userspace though, via a "suspend manager"
> > > process. Tasks reading input events will post "busy" events to stop the
> > > manager process from sending system into suspend. But this can be confined to
> > > Android userspace, leaving the kernel as is (well, kernel needs to be modified
> > > to not go into suspend with full queues, but that is using existing kernel
> > > APIs).
> >
> > I think that could be made to work. And it might remove the need for
> > the userspace suspend-blocker API, which would be an advantage. It
> > could even remove the need for the opportunistic-suspend workqueue --
> > opportunistic suspends would be initiated by the "suspend manager"
> > process instead of by the kernel.
> >
> > However you still have the issue of modifying the kernel drivers to
> > disallow opportunistic suspend if their queues are non-empty. Doing
> > that is more or less equivalent to implementing kernel-level suspend
> > blockers. (The suspend blocker approach is slightly more efficient,
> > because it will prevent a suspend from starting if a queue is
> > non-empty, instead of allowing the suspend to start and then aborting
> > it partway through.)
> >
> > Maybe I'm missing something here... No doubt someone will point it out
> > if I am.
> >
>
> Well, from my perspective that would limit changes to the evdev driver
> (well, limited input core plumbing will be needed) but that is using the
> current PM infrastructure. The HW driver changes will be limited to what
> you described "type 2" in your other e-mail.
>
> Also, not suspending while events are in progress) is probably
> beneficial for platforms other than Android as well. So unless I am
> missing something this sounds like a win.

I agree that simplifying the user API would be an advantage. Instead
of the full-blown suspend-blocker interface, we would need only a way
to initiate an opportunistic suspend. For example:

echo opportunistic >/sys/power/state

Alan Stern



\
 
 \ /
  Last update: 2010-05-25 21:07    [W:0.732 / U:0.248 seconds]
©2003-2014 Jasper Spaans. Advertise on this site