On 09/12/2016 08:03 AM, Julian Scheel wrote:
On 06.09.2016 19:15, Stephen Warren wrote:
diff --git a/board/avionic-design/common/meerkat.c b/board/avionic-design/common/meerkat.c
+void pinmux_init(void) +{
- pinmux_set_tristate_input_clamping();
That should be pinmux_clear_tristate_input_clamping();
gpio_config_table() is missing here.
I checked back our internal history. In fact we had this first (starting from Jetson TK1 as base), but later on removed it. The reason for removing it, was the assumption that whenever a driver wants to use a GPIO it will request it anyway, so that it will be confiured correctly. As this init code is generic for our SoM there is no predefined functionality for certain GPIOs which would make sense to preinit in the bootloader. In fact we even had some issues when the init was there because customers did not expect the pin to be a GPIO and wondered why a certain special function did not work as expected.
Do you see any other reason why a gpio init would be really needed here?
Definitely. Without explicitly setting a pin to a GPIO, its currently muxed special function will be active. If multiple pins are muxed to the same signal, it's undefined which pin will actually transmit/receive that signal. To avoid such conflicts in the pinmux, any pin that isn't actively used needs to be either set to a guaranteed-non-conflicting mux function or, much easier, be set to a GPIO input. I suppose if your mux table has been manually gone over with a fine toothcomb and you're 100% sure there are no conflicts even if no driver requests the GPIO functionality on any pin, then you're fine. However, my instinct is that this is unlikely.
Note that the pinmux setup in U-Boot should be complete; if a customer ends up assigning a particular use to a pin that's otherwise not assigned/dedicated by the SOM's design, then the U-Boot pinmux table needs to be updated to reflect that. Tegra HW doesn't support changing pin mux functions at run-time (it can be done register-wise, but there's no guarantee that doing so won't cause at least glitches on the pins while changing the mux functions). This means that it's perfectly safe to program unused/unassigned pins to GPIO in the U-Boot pinmux tables, since the user is required to regenerate those in order to use the pins as anything other than GPIO anyway.