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

[Stephen Warren]

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.

...
>> 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.

> Could we perhaps delay
> ripping this out for a little while longer?

What is the event that would trigger the end of this delay?