[U-Boot] [PATCH 2/5] vf610: refactor DDRMC code

[Stefan Agner]

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
>
>