On 12.09.2016 18:54, Stephen Warren wrote:
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

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

I'm pretty sure we do not have any conflicts in there ;)

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

Why would you consider a glitch on a pin more harmful when triggered from a running kernel compared to be trigerred from u-boot?

Anyway, we'll regenerate a pinmux/gpio init set for the kein-baseboard, that fully matches the configuration used in the kernel. Unfortunately it'll take me a few more days before I'll get to it.

U-Boot mailing list

Reply via email to