Suspended mode

Andy Green andy at openmoko.com
Sat Feb 2 11:06:39 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
	
> 	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. 

Wah it will be a bad number if we really talk about "MAX" :-)  CPU
cranking away 100%, packets transmitted all the time on WLAN, Bluetooth,
GSM module at max TX... MP3 at max loudness, GPS on, Vibrator on full,
LEDs on full :-)  Good test to see if the PMU blows up.

If we just talk about everything being on but idle again it will
probably make a (less) bad number.  I guess once we hear this bad number
people will get more interested in keeping the subsystems OFF until they
are actually needed by the user, so it is a good thing :-)

> 	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
> mode. 
> 
> 	How does this sound to you?

How do you plan to make sure it doesn't impact boot time?  Is this
200MHz mode down a different path than normal U-Boot usage?  For example
it will impact the time to show the splash screen if we always start at
200MHz, it'd be great if we could have your 200MHz mode where you want
it but it doesn't change the normal path.

For the kernel side eventually we should have cpufreq to change it
dynamically (although evidently that won't be simple either).

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHpECvOjLpvpq7dMoRAq8kAKCCtV2U73I0GLfsJoVimfnRxl3WcgCgjhlg
8/K8iu3WeOZpBFnItMsoNaY=
=aYju
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list