On 09/19/2016 07:35 AM, Julian Scheel wrote:
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
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.
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?
I wouldn't.
I've been told by syseng that pins need to be configured once to their
final setting. If SW attempts to configure only a subset of the pins,
then likely other pins' default settings will conflict, and the
conflicts will have to be resolved by programming those conflicting pins
too. To do that, you have to pick some non-conflicting configuration,
which may or may not just happen to match the intended final
configuration. If it doesn't, then the pin will be reprogrammed again
later, and it's my understanding that is the issue syseng wants to
avoid. Still, there aren't many details, so it's hard to understand the
problem completely, and whether it's a practical or theoretical issue.
IIUC the safest and only supported way is to just program the entire
pinmux once and completely as early as possible during 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.
-Julian
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
