Suspended mode

matt_hsu matt_hsu at
Sat Feb 2 10:07:17 CET 2008

> Some comments:
>  - Some submodules have an internal state that determines their power
> consumption while "on", ie, while we give them power.  It is true for
> WLAN and I guess it is true for GSM and Bluetooth.  So "ON" doesn't
> capture the situation in there because they can choose to run their
> radios or not for example and that will be dozens of mA difference.
>  - Particularly Sameo was asking what he should do with Suspend on WLAN.
>  I said that 99% of the time users do not want wake from WLAN, they want
> long suspend battery life.  But sometimes, if users want to wake on an
> incoming VoIP call for example, they do need it and that should be an
> application or user setting.
>  - "Normal Mode" has everything "ON".  But in truth usually the user
> does not want to use every IO method at the same time.  
	Hi Andy,
	Yes. But I think people would like to know if every IO is ON, how long
does the battery could long last? So I suggest we should have a
experiment on measuring _MAX_ current consumption of GTA02. Therefore we
can obtain a rough continous running time. 

	In addition, I would like to have a SLOW mode at uboot which CPU simply
runs on 200MHz. GTA02 could check the battery and charging status in
advance with less power, even to indicate the battery life on LCM.
Consequently, the system will run with full speed when gets into NORMAL

	How does this sound to you?


> Maybe he didn't
> have any Bluetooth peripheral or he does not like to run a GPS device.
> So we should ultimately allow the user to select to not start support
> for the devices we have power control for (it should be done as whether
> the usermode /etc/init.d script is started or stopped).  If he suddenly
> wants GPS because he is lost, well he can enable it.  The rest of the
> time he gets better battery life.
> - -Andy
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> iD8DBQFHoyxEOjLpvpq7dMoRAmEWAKCVAx64oC7ZBUlLPkM6wG66H7UwVgCeIma1
> De/3dKj67rBlmfca6X151Mk=
> =uj3M

More information about the openmoko-kernel mailing list