[PATCH 8/9] add-gta03-pmu-533MHz-init.patch

[Andy Green]

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

Somebody in the thread at some point said:

|> At the moment there isn't any stuff in the kernel to take care of
|> changing the cpu speed a la cpufreq except Cesar's implementation on the
|> debug branch.
|
| Actually, there's no need for all the complexity if you change the
| frequency only on very early boot. Most of the complexity of the cpufreq
| code is to deal with:
...
| It would be just:
| - Disable IRQ/FIQ
| - Set the clock registers, in the correct order
| - Adjust the kernel's clock subsystem
| - Adjust the timer subsystem, without caring for precise values (as long
| as it doesn't go back; at this point the clock probably hasn't been set
| yet)
| - Directly adjust the rest of the affected hardware (should be done by
| the drivers which manage each of the peripherals, but since they all
| should be known and built-in they can even be called directly, with no
| need to setup a notifier chain)
| - Restore IRQ/FIQ

This is good to hear.  Another way we can come at it though for the
one-shot case is to re-order device init so pretty much everything else
comes up only after i2c + pcf50633, and usb device.  This is already in
place largely on 2.6.26+ stuff that is not in git yet, but we do init
serial early there right now for example and we can defer that.

That way we just need to maybe adjust i2c prescaler and then complete
the kernel init at the final, faster clock rate after PC USB enumeration.

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

iEYEARECAAYFAki3nh8ACgkQOjLpvpq7dMpw1gCfXp4z3XY9++DHaCj3N4gDyPKu
OrIAn2AYSbDcDEomHf+4yCor1y4YI47K
=43pF
-----END PGP SIGNATURE-----