RFC: n800 suspend to ram
Hi; I've been doing some experiments with powersave on the n800. It seems you can't just put the n800 into suspend mode simply by doing a echo mem /sys/power/state, the retu watchdog kicks in if you leave it in that state too long. There is a flasher command to disable the retu watchdog, although through some horrible mistranslation it only stops the system from refreshing the watchdog -- it still goes off and brings down the system. Luckily there's an alternative, messy as it is - 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. Attached is a script to suspend the n800, the script is designed to run in the background and take advantage of the softoff state. (If you haven't done so already, I'd suggest editing /etc/mce/mce.ini and setting the power button to softoff). Once the softoff state is detected, the script will attempt to force the device into suspend. The script will spit out debug messages as it's run - wait the script is waiting for a softoff (backlight off, touch disabled) it will poll the system in 10 second intervals refresh updating the retu watchdog sleep XX suspending until rtc alarm in XX seconds awake (asleep X:XX:XX) device came back from sleep state before the alarm; likely the result of user interaction. X:XX:XX represents the total amount of time the script -attempted- to sleep for. Caveats - - the script must be run as root and should be run locally (not via ssh) - the device doesn't always suspend; particularly when the charger is attached - loadavg after exiting suspend is extremely high; probably miscalculated - the dsp REALLY hates it when you suspend with dsp activity There doesn't seem to be a good way of suspending dsp activity; I've read through the dsp documentation (http://dspgateway.sf.net) which seems to suggest the 'dspctl suspend' and 'dspctl resume' commands, which don't work. Once the dsp has crashed I can't find a reliable way to even restart it without rebooting. Requested - - completely disabling the watchdogs - help with dspctl/dsp_dld system The latest version of the script can always be found at http://mbm.openwrt.org/n800/suspend.sh suspend.sh Description: Bourne shell script ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: RFC: n800 suspend to ram
Hello Mike, nice work, did you notice any differences in power consumption? I think main idea behind not having proper suspend on Nokia tablets is that power management is so good there is no need for something like this. All hardware should go to low power state when not used so there should be no difference between idle device and suspend to ram state you try to achieve. If there is a difference it should be probably reported as bug in maemo bugzilla :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: RFC: n800 suspend to ram
Hi! On Wed, 2007-03-07 at 05:01 -0600, ext Mike Baker wrote: Hi; I've been doing some experiments with powersave on the n800. Good, that's really good news. It seems you can't just put the n800 into suspend mode simply by doing a echo mem /sys/power/state, the retu watchdog kicks in if you leave it in that state too long. There is a flasher command to disable the retu watchdog, although through some horrible mistranslation it only stops the system from refreshing the watchdog -- it still goes off and brings down the system. Luckily there's an alternative, messy as it is - 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. Attached is a script to suspend the n800, the script is designed to run in the background and take advantage of the softoff state. (If you haven't done so already, I'd suggest editing /etc/mce/mce.ini and setting the power button to softoff). Once the softoff state is detected, the script will attempt to force the device into suspend. The script will spit out debug messages as it's run - wait the script is waiting for a softoff (backlight off, touch disabled) it will poll the system in 10 second intervals refresh updating the retu watchdog sleep XX suspending until rtc alarm in XX seconds awake (asleep X:XX:XX) device came back from sleep state before the alarm; likely the result of user interaction. X:XX:XX represents the total amount of time the script -attempted- to sleep for. Caveats - - the script must be run as root and should be run locally (not via ssh) - the device doesn't always suspend; particularly when the charger is attached - loadavg after exiting suspend is extremely high; probably miscalculated - the dsp REALLY hates it when you suspend with dsp activity yeah, that too There doesn't seem to be a good way of suspending dsp activity; I've read through the dsp documentation (http://dspgateway.sf.net) which seems to suggest the 'dspctl suspend' and 'dspctl resume' commands, which don't work. Once the dsp has crashed I can't find a reliable way to even restart it without rebooting. Requested - - completely disabling the watchdogs I'm not sure that will ever be an option, with the device having radios. - help with dspctl/dsp_dld system The latest version of the script can always be found at http://mbm.openwrt.org/n800/suspend.sh Never the less, congratulations for the effort. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers -- 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
Re: RFC: n800 suspend to ram
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. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
