[U-Boot] [PATCH 2/3] arm: mx6: tqma6: Update to optionally configure an alternative SPI setup

[Stefan Roese]

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