diff options
author | Kyle Moffett <Kyle.D.Moffett@boeing.com> | 2011-03-15 11:23:47 -0400 |
---|---|---|
committer | Kumar Gala <galak@kernel.crashing.org> | 2011-04-04 09:24:43 -0500 |
commit | e820a131f4084397a212c6ffe3ed8ea0ce43631f (patch) | |
tree | ab52d3678b858aa374cad00b2199915bff0211a2 /common | |
parent | 33e683541eb12e898524f85803abae659af7be54 (diff) | |
download | u-boot-imx-e820a131f4084397a212c6ffe3ed8ea0ce43631f.zip u-boot-imx-e820a131f4084397a212c6ffe3ed8ea0ce43631f.tar.gz u-boot-imx-e820a131f4084397a212c6ffe3ed8ea0ce43631f.tar.bz2 |
fsl_ddr: Don't use full 64-bit divides on 32-bit PowerPC
The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
integer divide operations to convert between nanoseconds and DDR clock
cycles given arbitrary DDR clock frequencies.
Since all of the inputs to this are 32-bit (nanoseconds, clock cycles,
and DDR frequencies), we can easily restructure the computation to use
the "do_div()" function to perform 64-bit/32-bit divide operations.
On 64-bit this change is basically a no-op, because do_div is
implemented as a literal 64-bit divide operation and the instruction
scheduling works out almost the same.
On 32-bit PowerPC a fully accurate 64/64 divide (__udivdi3 in libgcc) is
over 1.1kB of code and thousands of heavily dependent cycles to compute,
all of which is linked from libgcc. Another 1.2kB of code comes in for
the function __umoddi3.
It should be noted that nothing else in U-Boot or the Linux kernel seems
to require a full 64-bit divide on my 32-bit PowerPC.
Build-and-boot-tested on the HWW-1U-1A board using DDR2 SPD detection.
Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
Acked-by: York Sun <yorksun@freescale.com>
Cc: Andy Fleming <afleming@gmail.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Diffstat (limited to 'common')
0 files changed, 0 insertions, 0 deletions