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

[Stephen Warren]

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