From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julian Scheel Date: Mon, 19 Sep 2016 15:35:11 +0200 Subject: [U-Boot] [PATCHv5 4/4] Add support the Avionic Design Meerkat COM and Kein Baseboard In-Reply-To: <8145486f-21fd-5550-f870-a2b3605ebc7f@wwwdotorg.org> References: <20160905132952.27280-1-julian@jusst.de> <20160905132952.27280-5-julian@jusst.de> <6f9977fa-826b-d555-6d59-5dfd2b6e1d37@jusst.de> <8145486f-21fd-5550-f870-a2b3605ebc7f@wwwdotorg.org> Message-ID: <9068aa4a-f94f-1187-7ea0-057c10e2ba9a@jusst.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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