Re: [iPAQ] Cpu scaling ??

On Mon, Jan 07, 2002 at 10:21:40PM +0000, bob lees wrote:
> So, if the old cpu-scale method worked OK, without dram timing problems, then
> either the ipaq is less sensitive to such issues or cpu-scale related code
> has the timings required. (I guess there are other conclusions, but these
> spring to mind first) I can't check the old 2.4.7 code as I don't have it
> any more, needed the disk space:( Can anyone who has the code for the
> cpu-scale related clock changes comment?

As one of the principal authors of the code in question I can certainly
comment.

Why did whe rewrite the CPU scaling code?
- The old code only reprogrammed the memory controller, while lots of
  other devices also need to be reprogrammed. The new code has a nice
  callback mechanism.
- It only worked on SA11x0 CPUs, while there were other CPUs out there
  that could change their clock speed. The new code also supports AMD
  PowerNow, Cyrix/VIA Longhaul, Intel SpeedStep, and ARM Integrator.
- The old code used an ad-hoc /proc interface, while the new code has a
  nice sysctl interface.

The Ipaq is by no means a magical device, it uses normal SDRAM just
like any other SA1110 design and as such is as sensitive to changes in
core clock speed as any other SA1110 design. Why? Because the SDRAM
waveforms are directly derived from the core clock speed, so if you
change the core clock speed you have to reprogram the SDRAM controller
or otherwise the system will hang.

The old code was just a hacked up version of the SA1100 code (which has
a much simpler EDODRAM controller), and it didn't take the subtleties
of SDRAM into account. For example: you couldn't make large jumps in
CPU speed (206 --> 59MHz) because that would hang the system (the
SA1100 has no problems with that).

The new SA1110 clock change code doesn't hang the system, but only when
it has an _exact_ knowledge of the SDRAM memory timing parameters.
Because we don't have that kind of knowledge about the Ipaq (you can't
even read the SDRAM type numbers because the chips are nicely
shielded), we can't guarantee stability for the Ipaq. The best thing to
avoid lots of crash reports is to remove the support at all and put it
back when somebody is kind enough to supply the seven SDRAM parameters.
Sorry: no pain, no gain.

(any subsequent questions about the SA11x0 CPU scaling code should be
asked on the linux-arm-kernel mailing list)

Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/