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

[Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>]

Am 09.02.2019 um 11:38 schrieb Simon Goldschmidt:
> On Sat, Feb 9, 2019 at 11:25 AM Marek Vasut <marex@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@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.

Unfortunately, that didn't help. And to make it worse, it seems like my 
last tests were somehow off by some 100 bytes.

However, I can keep SPL growth (without DTB growth) at +364 bytes by 
leaving sequencer.c as it is now (constant address) and only changing 
sdram_calibration_full() to take the address from DTB and checking it to 
be SOCFPGA_SDR_ADDRESS. I'll incorporate it like that into v2 of the 
'arm: socfpga: implement proper peripheral reset' series [1].

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=88303

Regards,
Simon