On Wed, 2007-03-07 at 16:20 -0600, ext Mike Baker wrote: > 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. I'd like to see some numbers, if you have any. Our primary goal was and is to provide seamless powersaving. Even while browsing; that's why the suspend-based solution wasn't very interesting.
The major penalty ini terms of latency that the current soultion incurs into (on both 770 and n800) is the dpll relock time after coming out from DeepSleep(1710) or Retention(2420). > 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. Wlan and BT. And also OMAP itself is not receiving anymore all the wakeups that applications and even the kernel (especially the networking stack) are generating. Another drawback that makes suspend not so likeable is that it means giving up the always connected feature, which was part of the specs for n800, wether we like it or not. But certainly suspend is a good alternative if you are not interested into the always connected feature. IFF it can generate significant extra saving. -- Cheers, Igor Igor Stoppa <[EMAIL PROTECTED]> (Nokia M - OSSO / Helsinki Finland) _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
