[PATCH 0/9] Experimental S3C2410A cpufreq driver

[Andy Green]

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

Somebody in the thread at some point said:

> For some weeks I have been working on a cpufreq driver for the GTA01 (to
> try to make its battery last a bit longer). It's far from complete (it
> will end up touching almost every device driver for the SoC), but the
> core code (which does the frequency switching) is mostly ready.

Wah!  Huge job, impressive!

> Along the way, I added GTA02 support; however, that not only is
> completely untested, it also will interact badly with the FIQ-using
> drivers (it disables FIQ during the frequency transition), at least
> until mutual locking is added so the frequency changes wait for the use
> of the FIQ to end.

Hum, well, locking will solve it.

> Some characteristics of the S3C2410 are not well supported by the core
> cpufreq architecture, meaning it had to be bent a bit to fit:
> 
> - The cpufreq core thinks only about the CPU clock, however the drivers
> are interested mostly on the bus clocks; this information is passed
> out-of-band.
> - The cpufreq core believes the drivers will want to set a minimum
> frequency (or a maximum frequency) below (or above) which they won't
> operate correctly; however, some drivers want to exclude specific
> frequencies in the middle of the range (like the serial driver, where
> some frequencies don't have a divider where it doesn't get out of spec,
> or the framebuffer driver, which wants to exclude frequencies which will
> cause flicker). Also, some drivers want the frequency not to change, but
> don't care which frequency should be used.
> - There are several ways to set a particular frequency (varying the
> divider settings).

CPU making asspain everywhere!  It seems one way or another we make
trouble when we switch clock -- I was planning to look closer at seeing
if we can use the slow clock mode with fixed 48MHz peripheral clock in
some technique along the lines of Intel "clock throttling", but you seem
to be very far along.

> The following drivers have already been adapted to work with the cpufreq
> driver:

Impressed!

> Comments and suggestions are welcome. More information on the correct
> formula for the PLL lock time would also be good.

I had cpufreq support on my list, someone mentioned your wiki page the
other day so I found out about your work then.

The CPU really makes things very difficult because in the divider ratios
that are possible the CPU clock is always the base clock.  I guess it
makes sense since it can always be the fastest, but there is no way to
degrade the CPU clock while maintaining unbroken peripheral and memory
clock for example.  AIUI it means you have to run around fixing up all
peripheral dividers from peripheral clock on changing the PLL, and that
will take a crap on any UART traffic in progress or whatever... in short
a freaking nightmare.

I have some stuff to take care of today and then I will try to bring
your patchset into the git tree and study it more closely.

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

iD8DBQFHspykOjLpvpq7dMoRArwnAJ9SbpyAlrQYxTT1G02lFBfAMrWzqwCgg9mC
NJt7Q00c8Zr6s8EYaaX9P8o=
=wQ5p
-----END PGP SIGNATURE-----