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

[Cesar Eduardo Barros]

Andy Green escreveu:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
> | Andy Green wrote:
> |> Get GTA03 into 533MHz / 133MHz memory bus goodness
> |
> | How big a difference does it actually make in terms of boot speed ?
> |
> | It would be good if qi could stay within the 100mA envelope, so
> | that we can avoid worrying about all the "how do I not kill myself
> | while powering up" issues we had to address in u-boot, and leave
> | all that mess to the kernel (who has to deal with it anyway).
> 
> 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:

- Trying not to disrupt the rest of the SoC peripherals during the 
transition (and restricting transitions which would cause problems to 
the peripherals given their current state).
- Telling all the drivers about the change, in enough detail.

If the frequency increase is done at a very early init, you know the 
system is quiescent already; you are on the only thread, and very few 
subsystems are up. These can be dealt with directly (should be mostly 
clock, timers, memory, I2C, and perhaps a couple of others), even the 
usually complex serial case (you know you aren't printing anything to 
the console, and nothing should be trying to talk to you on the console, 
and the other serial ports should not be doing anything at this point).

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

The earlier this happens in the boot sequence, the least it has to do. 
Ideally only the early serial console, one of the timers (for the kernel 
timekeeping), memory (obviously), and I2C (for the PMU) should be 
running at this point; these should be enough for the "wait for enough 
power" routine.

This would duplicate a small part of the cpufreq code (in a much 
simplified way, without even a full table of frequencies), but such 
duplication is not unheard of in the Linux kernel; IIRC, we already have 
an early-boot memory manager and an early-boot serial console.

-- 
Cesar Eduardo Barros
cesarb at cesarb.net
cesar.barros at gmail.com