Re: [RFC][PATCH 00/11] Android PM extensions

Rafael J. Wysocki
2009-02-01T12:30:03Z

On Sunday 01 February 2009, Arve Hjønnevåg wrote:
> On Sat, Jan 31, 2009 at 5:32 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> > If incoming calls are supposed to wake up the system, then there are two
> >> > possibilities:
> >> > - the already started suspend sequence may be aborted and the system may be put
> >> > into the low power state,
> >>
> >> I assume you mean high power state not low power state, or does low
> >> power state mean early-suspend state. If so, locking a wakelock will
> >> accomplish this.
> >
> > Actually, I meant the working state. Aborting suspend sequence always means
> > go back to the working state.
> >
> > Also, I think the device that detected the incoming call should abort the
> > suspend sequence by refusing to suspend.
> >
> >> > - the system may be suspended and then immediately woken up.
> >>
> >> If you mean this as a general strategy, and not a specific outcome,
> >> then it does not always work (for the reasons I have already stated).
> >
> > I meant a specific outcome.
> >
> > It may be impossible to abort suspend if the call comes in sufficiently
> > late.
>
> In that case, why are you against using wakelocks to abort the suspend
> sequence? It covers the case where the driver knows that a call is
> coming in, without any confusion about when the abort condition
> clears. And, it avoids the overhead of freezing every process for an
> operation that is doomed to fail.

I'm not really against (yet), I'm only trying to clearly understand the
benefit.

The problem pointed out by Alan is real, the user expects the system to suspend
as soon as the button is pressed and wakelocks may get in the way.

Your example is also good, but I think the problem in your example (phone
call coming in while suspending) may be resolved without wakelocks. Moreover,
it is a general problem of a wake-up event coming in while suspending and
it requires a general solution independent of wakelocks.

Thanks,
Rafael