Simon, On Tue, Sep 18, 2012 at 12:53 PM, Simon Glass <s...@chromium.org> wrote: > Hi, > > On Thu, Sep 13, 2012 at 3:37 PM, Stephen Warren <swar...@wwwdotorg.org> wrote: >> On 09/12/2012 04:10 PM, Tom Warren wrote: >>> Signed-off-by: Tom Warren <twar...@nvidia.com> >>> --- >>> board/nvidia/common/board.c | 27 ++++++++++++++++++++++++++- >>> 1 files changed, 26 insertions(+), 1 deletions(-) >> >> Common code:-) :-) But ... >> >>> diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c >> >>> +#ifdef CONFIG_TEGRA30 >>> +#include "../cardhu/pinmux-config-common.h" >>> +#endif >> >> Not all Tegra30 will be Cardhu... >> >> Given this is really board-specific, shouldn't the following be an empty >> weak definition: >> >>> +/* >>> + * Routine: pinmux_init >>> + * Description: Do individual peripheral pinmux configs >>> + */ >>> +static void pinmux_init(void) >>> +{ >>> +#if defined(CONFIG_TEGRA30) >>> + pinmux_config_table(tegra3_pinmux_common, >>> + ARRAY_SIZE(tegra3_pinmux_common)); >>> + >>> + pinmux_config_table(unused_pins_lowpower, >>> + ARRAY_SIZE(unused_pins_lowpower)); >>> +#endif >>> +} >> >> ... and the function be overridden in board files as needed? >> >> If we are moving to a model of a single function that sets up the entire >> pin mux at boot (which seems fine to me, and could eventually be driven >> by DT if it happened late enough), then it seems like we wouldn't need >> e.g. pin_mux_mmc() or pin_mux_usb() any more. > > While the fdt may eventually remove this discussion, I don't think > forcing a one-time pinmux init is the best idea. Some peripherals will > not be needed on every boot (e.g. normally boot from eMMC unless USB > is available). Some peripherals may want to change their config based > on run-time settings (although this is unlikely I suppose, > particularly if we have the fdt).
I've been basically adapting our internal T30 U-Boot code to fit within the framework of what's upstream, including Allen's SPL reorg. Pinmux on our T30 codebase (including the Chromium U-Boot code, I believe) was done in a single monolithic file, as demonstrated in this patch. The advantages are that you can construct the table to ensure there are no conflicts, no small task with 4 options per mux and over 100 muxes. Even the HW power-on defaults have conflicts. The only exception in this patchset was the UART muxing, so we can start putting out debug/status spew to the console as early as possible. As far as I'm aware, an FDT pinmux for Tegra (which is on my plate, but quite a bit behind T30) would be essentially the same deal - one large list of mux settings per build/board. Also, we've had bugs submitted by the kernel guys at times because U-Boot didn't do _enough_ init. While I agree with the U-Boot philosophy of doing just what's necessary to get a kernel loaded, I don't consider pinmux init from a table as a time-consuming or code-intensive operation, and see no harm in leaving it in. The driver can always remap the muxes as it chooses at a later date, based on what it discovers or knows from its config or the DT. Thanks, Tom > > Regards, > Simon > >> _______________________________________________ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot