[U-Boot] [RFC] mpc83xx: add config options to spd_sdram

[Kim Phillips <kim.phillips@freescale.com>]

On Tue, 5 Apr 2011 11:49:49 +0200
Andre Schwarz <andre.schwarz@matrix-vision.de> wrote:

Cc'ing York Sun, who knows a little more about this stuff than I do.

> I have made some mods to spd_sdram.c for various reason:
> 
> 1.
> use SPD setup also for soldered RAM.
> This allows DDR mounting options without U-Boot change because SPD data
> is written during in-circuit/boundary-scan testing.

not sure I understand this - board with soldered RAM can't physically
get the SPD data from RAM, yet SPD data were somehow acquired and
written into some ROM, so spd_sdram() is still needed to parse &
program the controller without requiring a new u-boot binary?

this isn't included in the below diff, right?

> 2.
> read SPD data also from extended adressing EEPROMS used for e.g. HRCW 
> storage.
> Due to HRCW being being located at offset 0 we need an SPD data offset.

and this is the SPD_EEPROM_OFFSET stuff below?  hmm..

so both 1 & 2 are coagulated in my mind - ideally, this would be
implemented with the new ddr code in
arch/powerpc/cpu/mpc8xxx/ddr/main.c - see fsl_ddr_compute(), which has
a GET_SPD step that would need to be either skipped (i.e, start_step =
COMPUTE_DIMM_PARMS), or changed to be able to be overridden, or,
ideally, all DIMM computations would be precomputed and stored in ROM
and a direct start_step to e.g., STEP_ASSIGN_ADDRESSES were made.

> 3.
> for optimized signal integrity and power consumption we need more 
> influence on
> the on-die termination. Although the assumed default values are working they
> are far from ideal.

board specific things like this are perfectly acceptable, of course.  

however, it should not be being done by glittering old-83xx/spd_sdram
with an extra #ifdef for every new parameter that is needed, especially
when this is all fixed in the new ddr code.  So, in preparation for
83xx to eventually migrate to the new ddr code, I'd like this to be
done in such a way so as to start to conform to the new code by at least
defining ODT, etc. parameters in a board-specific
ddr.c:fsl_ddr_board_options().  See board/freescale/{p1022ds,*}/ddr.c
for example.

> 4.
> CPO values depend on internal bond wire length which has significantly
> high variance on MPC837x, i.e. this value also should be board specific.

again, to be defined as popts->cpo_override in the board-specific
ddr.c:fsl_ddr_board_options().

> I have taken care not to increase code size and not to break existing 
> boards.
> 
> Any comments from your side ?
> Is this something you might ACK ?

not as-is - see above, and let me know what you think.

Kim