Re: [linux-pm] suspend blockers & Android integration

[Alan Stern]

On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:

> > In fact it's possible to do this with only minimal changes to the
> > userspace, providing you can specify all your possible hardware wakeup
> > sources.  (On the Android this list probably isn't very large -- I
> > imagine it includes the keypad, the radio link(s), the RTC, and maybe
> > a few switches, buttons, or other things.)
> >
> > Here's how you can do it.  Extend the userspace suspend-blocker API, so
> > that each suspend blocker can optionally have an associated wakeup
> > source.
> >
> > The power-manager process should keep a list of "active" wakeup
> > sources.  A source gets removed from the list when an associated
> > suspend blocker is activated.
> >
> 
> How do you do this safely? If you remove the active wakeup only when

"remove the active wakeup" isn't a good way of expressing this.  You 
remove the wakeup source from the power manager's list of active 
sources.  This is just manipulation of a data structure internal to the 
power manager; it doesn't affect the actual source.

> activating the suspend blocker, you will never unblock suspend if
> another wakeup event happens after user-space blocked suspend but
> before user-space read the events.

I'm not sure what you mean.  In this scheme userspace doesn't ever 
block suspends.  Instead the power manager freezes and unfreezes all 
the other processes.  And the system never suspends, it simply goes 
idle for prolonged periods of time... with all processes frozen except 
the power manager, and it sitting inside a poll() system call.

It's true that under some exceptional circumstances the system would 
never remove a wakeup source from the "active" list and then would 
never go idle.  But exactly the same problem exists with wakelocks, if 
the kernel activates a wakelock and there's no user process reading the 
corresponding event queue.

> Also, I'm not sure we can easily associate a wakeup event with a user
> space suspend blocker. For instance when an alarm triggers it is
> sometimes because of a user-space alarm and sometimes because an
> in-kernel alarm.

That's okay.  The association is optional, and not all suspend blockers
will have an associated wakeup source.  (However, each wakeup source
that needs to percolate up into userspace -- i.e., that isn't handled
internally by the kernel -- should have at least one associated suspend
blocker.)  The purpose of these associations is to make explicit the
"handoff" in your original scheme, whereby a source would cause the
kernel to activate a wakelock until some user process activated its own
and then cleared the kernel's wakelock.  In your scheme, the connection
between the userspace wakelock and the wakeup source is implicit; in
my scheme it is explicit.

For example, a process that uses a suspend blocker in order to read
keystrokes would obviously associate its suspend blocker with the
keypad-matrix wakeup source.

Or take your example of an alarm.  To make it work in my scheme, each
user alarm would have to be implemented as a poll-able file descriptor.  
Processes reading the descriptor would block until the alarm expires.  
(I don't know of any driver that provides this sort of timer interface,
but it would be easy to write one.  You could think of it as applying
Unix's "Everything is a file" philosophy to alarms.)  Each of these
descriptors would then be a wakeup source, included among the sources
that the power manager polls for, and a suspend blocker could be
associated with it.

Alan Stern

--
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/