On Sun, Sep 04, 2016 at 11:47:06AM -0300, Fabio Estevam wrote:
On Sun, Sep 4, 2016 at 10:32 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Please do read the thread fully before commenting, I've mentioned the state of hardware when I relied to Peng. And also this is an RFC patch I'm looking for comments on function like changes whether the flow of adding code to existing software is meaningful or not and not intended to directly applying these onto ML.
I have already stated my opinion that you should put your board code into board/engicam.
Yes, this sounds right.
But I prefer to maintain the same on board/freescale/imx6ul. Becuase, If the most of the code is common to all boards with specific SOC it's better to have common code for reusability instead of adding different board files with duplicate code. For example please see board/sunxi or board/xilinx/zynq where microzed, zed or zynbo not directly manufactured from xilinx but they maintained as common.
All the ifdefery inside board/sunxi/board.c is exactly what I would like to avoid here.
Now, in fairness to sunxi, that's more like what would happen if you decided to support all of the imx6 and imx7 SoCs in a single board.c.
mx6ul is a recent SoC and there is only mx6ul evk and pico mx6ul boards currently supported in U-Boot.
I don't think this can scale to support all upcoming boards into a single board/freescale/mx6ul/board.c.
Why is mx6ul special in this case compared to the other mx6 variants?
Will you be able to support all mx6q boards into board/freescale/mx6q/board.c as well?
I am sure this will be unmaintainable.
I suspect there's a certain amount of code that should be in arch/arm/mach-imx/board.c like a __weak dram_init() and maybe some ${soc}.c files too for things that really aren't board specific but rather SoC-required. Of course I'm biased since this is how the TI stuff evolved to.
But also, if the enigcam board is an example of "take the ref board, cut it down a bit, ship" or even "take the ref board, tweak slightly", there will still be some code duplication as they simply made the same board decisions that NXP did in the reference platform.