Andy Green andy at openmoko.com
Tue Jun 24 15:29:18 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| Am Dienstag 24 Juni 2008 14:53:56 schrieb Werner Almesberger:
|> Andy Green wrote:
|>> We could crank up the clock later I suppose, keeping the backlight, LCM
|>> and Glamo all down if they're up at this time.  The Glamo has 80MHz PLL
|>> and its own DRAM so I don't think it's that cheap to run.
|> Just leaving the CPU at 200MHz (instead of cranking it up to 400MHz in
|> board_init) saves 30mA, turning off the LDOs another 40mA. Almost there,
|> without even trying hard :-)
| Cool. This brings me back to asking why we did abandon or ignore
cesars work
| towards cpufreq. Andy you said something about UARTS being endangered
| clock switch?

It's pretty invasive and looked like it would increase instability for
us when we were already unstable.  Nor was it critical for us compared
to the other problems we have been working on.  It doesn't help if we
are fighting stuff like GSM crash in resume or serial resume wake or
flaky resume ordering if we have to keep wondering "was that cpufreq

s3c2442 is actively hostile to dynamic clock changes so it's not the
patchset's fault, it's try to do the best job that can be done.

It's still in my stgit and if you want to give it a go I will make a new
branch off andy that has it on, and you can let us know what happened.

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


More information about the openmoko-kernel mailing list