From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Agner Date: Mon, 13 Jul 2015 21:01:56 +0200 Subject: [U-Boot] [PATCH 2/5] vf610: refactor DDRMC code In-Reply-To: <559F7DC3.1090905@denx.de> References: <1434716311-26189-1-git-send-email-albert.aribaud@3adev.fr> <1434716311-26189-2-git-send-email-albert.aribaud@3adev.fr> <1434716311-26189-3-git-send-email-albert.aribaud@3adev.fr> <55843188.2020205@toradex.com> <20150619193332.058a2487.albert.aribaud@3adev.fr> <559F7DC3.1090905@denx.de> Message-ID: <55A40B24.6020309@toradex.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Albert, Hi Stefano, On 10.07.2015 10:09, Stefano Babic wrote: > Hi Albert, Stefan, > > On 19/06/2015 19:33, Albert ARIBAUD wrote: > >> I could probably factor back out the JEDEC settings, but there are >> still differences in the lists of registers to write between the >> existing vf610twr/colibri_vf and the new pcm052, especially the PHY >> regs but elsewhere too, and there are some writes in the driver that >> the PCM052 does not have. >> >> As I wanted to leave the existing boards strictly unaffected, and as I >> did not want to start sprinkling '#if defined(some-board)' over the >> driver code, I went for a fully board-controlled design so that no >> board could possibly be affected by any future change to the driver. >> >> How about a mix? I could keep the JEDEC and lvl pointers in the DDR >> controller init call arguments and append "per-boards" CR and PHY >> arrays. The driver would do the JEDEC writes (thus keeping JEDEC DDR3 >> additions simple), the LVL writes if not NULL, then the "per-board" CR >> writes if not NULL, then the current common PHY writes, then the >> "per-board" PHY writes if not null. > This matches IMHO what we have already tried to do with most of > Frescale's i.MXes, putting general code and setting in the arch/cpu/ (or > in the imx_common for MX5 and MX6), but letting the board code to write > the board specific part. > > Some mix seems to me a goog compromise between flexibility and common code. As far as I understood Alberts proposition it would mean that we write some registers directly from board code right? I'm not sure if this works out for all registers, since some might have JEDEC and Board specific fields in one register...? Looking throug some CR registers lead me to belive that most settings are exact the same or already covered by the JEDEC struct... The few remaning ones could be part of a renamed ddrmc_lvl_info struct (e.g. ddrmc_cr_info). The same for the PHY settings (ddrmc_phy_info). This would lead to a common place where all registers gets written, while having the flexibility to use board specific data... No back and forth between the board file and the common code. I did not an exact survey how much of the registers are actually different, but I feel that the difference is not that big that moving the whole initialization to the board files is worth the effort... -- Stefan >> This would keep common parts (JEDEC and minimal settings) in the driver >> while allowing board their own specific settings -- even overriding the >> driver settings, since the per-board writes would come last before >> CR000 is rewritten. >> >> Would that be ok ? >> >>> -- > Best regards, > Stefano Babic > >