Re: Attempted summary of suspend-blockers LKML thread

[Olivier Galibert <galibert@pobox.com>]

On Tue, Aug 03, 2010 at 11:03:15PM -0700, Arve Hjønnevåg wrote:
> 2010/8/3 Olivier Galibert <galibert@pobox.com>:
> > On Tue, Aug 03, 2010 at 08:39:22PM -0700, Arve Hjønnevåg wrote:
> >> If you just program the alarm you will wake up see that the monotonic
> >> clock has not advanced and set the alarm another n seconds into the
> >> future. Or are proposing that suspend should be changed to keep the
> >> monotonic clock running?
> >
> > You're supposed to fix the clock after you wake up.  That's part of
> > the cost of going suspend.
> 
> I'm not sure what you are referring to. The generic Linux timekeeping
> code makes sure the monotonic clock stops while the system is
> suspended regardless of what values the (hardware specific)
> clocksource returns.

That just means the android-like suspend should not act in that
specific area the same as the generic suspend to ram.  Which is not
entirely surprising.  In any case, it's not "keep the monotonic clock
running", which would cost power.  It's fix it up afterwards, using
the same means you already do but perhaps at a higher level currently.
People don't want to see the wrong time of the day just because the
phone went to suspend.  Laptop STR is different in perception because
it shuts down things people don't want to see shutdown just by being
idle, namely wifi connectivity.

If your next polling timer is in half an hour and the screen/touchpad
are off, you want to go as low in power as possible until then, and
that's the deepest level of idle you can find that responds to alarms
which may happen to be called suspend.  But from a user point of view,
it's just another idle level.  And from a power management code/policy
decisions point of view, it should be the same.

  OG.