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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
