On 09/27/2012 04:59 PM, Simon Glass wrote: > Hi, > > On Thu, Sep 27, 2012 at 3:32 PM, Stephen Warren <swar...@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? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot