Hi Markus,
On 13.03.2015 10:05, Markus Niebel wrote:
-static void tqma6_iomuxc_spi(void)
+__weak void tqma6_iomuxc_spi(void)
{
unsigned i;
When implementing an baseboard specific init handler, we will get
a warning about unused
tqma6_ecspi1_pads and tqma6_ecspi1_cs, or did I miss something?
I'm not getting one with the current (unfinished) WRU4 baseboard. Which has no
SPI.
Oops, not understand the weak mechanism completely - compiler sees usage of data
in weak function but linker selects function from baseboard - correct?
If this is the case, we have only the duplication of IOMUX and CS gpio.
Just as a thought (not ready): Could we supply CS initialisation
data via defines in the
baseboard config header and append it to the tables if needed?
Not sure if I understand this correctly. Could you give an example? Again, my
current baseboard has no SPI at all.
tqma6_iomux_spi is for the SPI controller the serial nor is connected,
so baseboard specific data are additional CS.
You could solve the data duplication using
#define TQMA6_BB_ECSPI1_CS_GPIO IMX_GPIO_NR(n, mm),
#define TQMA6_BB_CS_PAD_CTRL NEW_PAD_CTRL(MX6_PAD_bla__GPIOn, IOmm,
<PAD_CTRL)
and in the board file:
if !defined(TQMA6_BB_ECSPI1_CS_GPIO)
#define TQMA6_BB_ECSPI1_CS_GPIO
#endif
static unsigned const tqma6_ecspi1_cs[] = {
TQMA6_SF_CS_GPIO,
TQMA6_BB_ECSPI1_CS_GPIO
};
But OK, this looks not very nice
As I said, not completely ready, but would prevent some code duplication.
With my current approach we have code duplication. I suggest we give
this version a try and see if it scales for other, future baseboards as
well. If not, we can always try a solution like you described above.
Okay?
Thanks,
Stefan
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
