On Fri, Oct 05, 2012 at 01:03:10PM -0700, Eric Nelson wrote:
On 10/05/2012 12:00 PM, Tom Rini wrote:
[snip]
And we can't deal with this by factoring the code differently?
Hi Tom,
There are two bits to this question:
- Can we represent the policy differences outside of a
board structure? These differences are all inside of include/configs/nitrogen6x.
I'm not certain how, but I suspect that we can get a different _config to work for this.
- Can we represent the board differences without a
board structure? This is a bit harder, since the boards are slightly different. The Nitrogen6X has a different ethernet PHY reset pin and an optional SDIO Wi-Fi module.
We could add code to SABRE Lite to accommodate these, but it seems that sets a bad precedent. Would this be done for every vendor that bases a design on SABRE Lite?
The precise diffs for the configs and sources is attached for reference.
I've also been pondering how to simply re-use the code within the board setup file (mx6qsabrelite.c), but I haven't figured anything out. Clearly a lot of the code is duplicated, but at the same time it's board-specific.
For example, we could create a common module that sets up the SD card pads "like SABRE Lite", and a similar one to configure ethernet pads. Since SABRE Lite is a reference design, perhaps that makes sense.
Does anybody have thoughts about how and where this might be sliced?
Dice some bits of board/freescale/mx6qsabrelite/mx6qsabrelite.c into arch/arm/cpu/armv7/mx6/board.c (or some other filename in mx6/) ? This is what we do on the various OMAP families, and use a few hooks for "let the board fill in this part of setup". Possibly re-use and update mx6/soc.c even.