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

[Julian Scheel]

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?

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