[U-Boot] [PATCH] arm: socfpga: move gen5 SDR driver to DM

[Simon Goldschmidt]

On Sat, Feb 9, 2019 at 11:25 AM Marek Vasut <marex at denx.de> wrote:
>
> On 2/7/19 10:23 PM, Simon Goldschmidt wrote:
> > To clean up reset handling for socfpga gen5, let's move the code snippet
> > taking the DDR controller out of reset from SPL to the DDR driver.
> >
> > While at it, port the ddr driver to UCLASS_RAM and use dts.
> >
> > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
> > ---
> >
> > This is an RFC to show what the SDRAM driver moved to DM (UCLASS_RAM) would
> > look like. It's RFC both because Dinh did not seem too fond of changing the
> > register address of the SDR in devicetree to include what the undocumented
> > registers 'sequencer.c' uses as well as because of my observed code growth.
>
> Dinh, if the SDRAM controller spans some addresses, it should be
> described like so in the DT. Whether those registers are documented or
> not does not matter, DT is a hardware description and should describe
> hardware accurately.
>
> > Basically, I want to move this to UCLASS_RAM and I want to read the reset
> > property for SDR from devicetree. What remains RFC is: do we want/need to
> > read the base address from devicetree, or can we live with it being hard-
> > coded (and maybe sanity-checked during probe)?
> >
> > Note that converting sequencer.c from hard-coded address to pointers read
> > from devicetree and passed around to every function increased code size by
> > ~700 bytes. Not too much, but enough to stop my socrates board working
> > (yes, the SPL size check does not work :-( - I'll work on that).
> >
> > Also note that this is an integrated patch for SoCrates to show what it
> > would look like. In the series I prepared, it's better separated and all
> > boards are adjusted.
>
> I wonder, rather than passing $sdr around, could we have a static $sdr
> and support only one single instance of the DRAM controller ? Would that
> trim down the size growth ?

Let me check that. It's worth trying.

Regards,
Simon