[U-Boot] [PATCHv5 4/4] Add support the Avionic Design Meerkat COM and Kein Baseboard

[Stephen Warren]

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.