[U-Boot] [PATCH 1/2] tegra: clean up board include hell

[Simon Glass]

Hi Stephen,

On Thu, Sep 27, 2012 at 4:25 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 09/27/2012 04:59 PM, Simon Glass wrote:
>> Hi,
>>
>> On Thu, Sep 27, 2012 at 3:32 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> On 09/27/2012 03:52 PM, Lucas Stach wrote:
>>>> The prototypes used in board files were all scattered out, which lead to
>>>> code duplication between SPL and normal U-Boot and some prototypes not actually
>>>> being used. Consolidate this in a common board header.
>>>
>>>> This will allow to push down the calling of the pinmux functions into the
>>>> respective drivers and this way cut down on complexity from the common board
>>>> code.
>>>
>>> I don't think that (calling pinmux from drivers) would be a good idea.
>>> The entire pinmux should be set up globally when the system boots in
>>> order to avoid conflicts part-way through a change, and to avoid
>>> duplicating pinmux calls into every single driver. Unless a particular
>>> driver actively needs to switch between different pinmux configurations
>>> at run-time (e.g. an I2C bus mux that uses pinmux to do the muxing).
>>
>> Well I'm not so keen on this approach. Ultimately we want to be able
>> to start a driver (and set up its pinmux) only if it is needed during
>> boot.
>
> I disagree.
>
>> The idea behind funcmux is that it is a single line call from a
>> driver or board to select the required setting, so the overhead is
>> small - and we know that for most peripherals there are only a small
>> number of options.
>
> Tegra30's more flexibile pinmux (if not the more convoluted options on
> Tegra20) will eventually convince you that funcmux is not scalable, once
> we support more than a few of the possible options.

Well I am already convinced of that - it is just a placeholder until
we have fdt support after all. Its entire purpose is to avoid lots of
individual pinmux calls in all the board files and drivers, which we
are in the pre-fdt state. Without funcmux we would have had long lists
of duplicated code in each board file.

>
> ...
>>> I think we should just rip out all the CONFIG_SPI_UART_SWITCH stuff.
>>> It's only there to support one board with a completely broken HW design.
>>> Still, that could happen in a separate patch after this though.
>>
>> Yes I agree the seaboard is broken, but this is an upstream board and
>> is in fact the only one I have to test with.
>
> There's zero use for the functionality though. Because the HW design is
> broken, we've decided not to support the SPI flash on
> Seaboard/Springbank. The SPI driver itself works fine on TrimSlice
> without any issues, so there's no testing hole there.

I thought Tom submitted some patches to make it work? It seems fine
for me, but I admit I don't use it extensively.

>
>> Could we perhaps delay
>> ripping this out for a little while longer?
>
> What is the event that would trigger the end of this delay?

Merging of the LCD series, for me.

Regards,
Simon