[maemo-developers] RFC: n800 suspend to ram

From: Mike Baker mbm at openwrt.org
Date: Thu Mar 8 00:20:32 EET 2007
On Wed, Mar 07, 2007 at 01:56:18PM +0200, Igor Stoppa wrote:
> On Wed, 2007-03-07 at 05:01 -0600, ext Mike Baker wrote:
> The wd in retu is a deadman's button. It comes from phones legacy, where a
> rebooting device can disrupt communications for others as well. In the tablet
> it still makes sense to have it for avoiding that if the devices becomes stuck,
> it also drains your battery.
> > Refresh the retu watchdog, this will give you 64 seconds until it needs to
> > be refreshed again. Next, set the retu rtc alarm; you only get one minute
> > resolution, but that's jsut enough. Once the alarm is set, suspend; the
> > alarm will wake the device out of suspend mode and the cycle repeats.
> Theoretically it's good; practically, i'm not so sure.
> The reason being that with runtime power management we get away quite
> cleanly with drivers not having to save/restore their state (we only ask
> them to use the clock fw).
> You probably would use suspend as an alternative to long idle periods,
> such as overnight, maybe using an idle timer to detect it.
> However, because of the 64s constraint, the energy price is not little
> when doing the wd kicking from userspace. A more power efficient
> solution (at the expense of stability) would be to do it from
> kernelspace, _whitout_ triggering the whole system thaw and re-enabling
> only those drivers required to talk with retu (since it contains both
> the rtc and the wd).
> But that's a very custom hack.

I suppose the real issue here is "what does suspend mode do that isn't done
otherwise" since even in userspace it seems to give better performance than
just letting the system idle.

A preliminary glance shows suspend disabling power to the MMC slots (VMMC
and VDCDC3) which otherwise only happens when an MMC rescan event fails to
find a card in the slot.

More information about the maemo-developers mailing list