[PATCH 0/4] Camera clock fixes

[Andy Green]

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

Somebody in the thread at some point said:

|> I seemed to see an fair increase in background current on 3D7K with the
|> last lot in, it'd be ideal if it didn't do that until someone had a
|> handle open on the device.
|
| Sure. Proper use of regulators, clock gating, suspend/resume, etc.,
| are on my to do list, but there are still a number of items relevant
| for the function test that have priority. (Such as an undistorted
| viewfinder.)

Well I don't mean plumbing it all in properly, just maybe temporarily
moving what you're doing on probe into some kind of open() thing if
there's one that fits semantically.  It'd help if the camera power and
clocks weren't up by default even if that's ugly for a while.  If it
saves time implementing it for default power then a kernel param to
enable camera even.

| By the way, fixing the clock should make the system a little less
| power-hungry. Before, it was all chaos and somewhere burned quite a
| bit of energy.

Good I don't know where the power is all going even without the camera.

I'm running Mark Brown's cpufreq stuff now I figured out why it
destroyed GTA02 function and it's only a matter of a few mA between 533
and 133MHz... even though he doesn't change the PLL for ARM yet that's
not what I was expecting given 2442 experience.  Maybe it's the memory
clock or something totally out of this.

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

iEYEARECAAYFAkm1cccACgkQOjLpvpq7dMpVrACeLWRGreuKjP0kUxHlK82wlequ
a9gAn1mqsKPGmn5qtmPsUxrATaQ4SRpR
=UIT7
-----END PGP SIGNATURE-----