On 09/27/2012 04:59 PM, Simon Glass wrote:
Hi,
On Thu, Sep 27, 2012 at 3:32 PM, Stephen Warren swarren@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?