[U-Boot] [PATCH, REGRESSION] mpc83xx: provide option to set LCRR early

[Peter Korsgaard <jacmet@sunsite.dk>]

>>>>> "Kim" == Kim Phillips <kim.phillips@freescale.com> writes:

 Kim> On Fri, 20 Nov 2009 12:42:43 +0100
 Kim> Peter Korsgaard <jacmet@sunsite.dk> wrote:

 >> E.G. on a 8347 board a bootup time increase of ~600ms has been observed:

 Kim> heh, even more on an 8313!  Thanks for this - I hadn't realized the
 Kim> difference was so large (or neglected it since the move to init_r was
 Kim> done at the last moment).

OK, why exactly was it moved? What do you want to protect against? I
don't remember seing anyone complaining about the old location.

 >> Fix it by introducing CONFIG_SYS_LCRR_EARLY, and set LCRR in cpu_init_f
 >> instead of in cpu_init_r if set.

 Kim> instead of introducing the new CONFIG_SYS_LCRR_EARLY, shouldn't we
 Kim> check for something like:

 Kim> !defined(CONFIG_NAND_SPL) && !defined(CONFIG_SYS_RAMBOOT)

As in do the reconfig early if we're running from RAM right away?
It's not that simple - I have a board which boots from NOR flash. As
that is an async device there isn't any problem in changing the LBC
settings while you're running from flash (as long as you respect the
min access time). I have another design where the flash sits behind a
FPGA (for signal integrity reasons), and there I have to wait until
we're running in RAM before changing the LBC clock.

On the 2nd design I even have to tell the FPGA to resync (through a GPIO
pin) and wait a bit before I can continue, so I'm doing the LCRR config
in board code (in board_early_init_r). The move to cpu_init_r broke that
as well as the LCRR value is overwritten there.
 
 Kim> btw, this generates:

 Kim> cpu_init.c: In function 'cpu_init_r':
 Kim> cpu_init.c:367: warning: unused variable 'im'

Ups, I'll fix that and send a new patch once we agree on the form.

-- 
Bye, Peter Korsgaard