cpufreq

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
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
during
| 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
stuff?".

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhg9qgACgkQOjLpvpq7dMqp2QCfdwEbDPR+MCLXUJV5fUNfDwiq
UScAoJUhn6EPkOjzL9xl9jAf5Hhx7IPT
=V5L0
-----END PGP SIGNATURE-----