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