From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Wed, 13 Feb 2019 22:10:28 +0100 Subject: [U-Boot] [PATCH] arm: socfpga: move gen5 SDR driver to DM In-Reply-To: References: <20190207212309.27559-1-simon.k.r.goldschmidt@gmail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 09.02.2019 um 11:38 schrieb Simon Goldschmidt: > On Sat, Feb 9, 2019 at 11:25 AM Marek Vasut 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 >>> --- >>> >>> 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