From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Tue, 01 Oct 2013 14:29:55 -0700 Subject: [U-Boot] [PATCH] mx6: Add IOMUX_CONFIG_SION flag to all GPIO pins In-Reply-To: <1938105334.2320821.1380657041367.JavaMail.zimbra@advansee.com> References: <1380492900-910-1-git-send-email-otavio@ossystems.com.br> <524ACA60.3020504@denx.de> <524ADB98.9010605@boundarydevices.com> <524AE107.1050404@denx.de> <524AF09B.7040505@boundarydevices.com> <524AF3ED.6030501@denx.de> <524AF582.1030907@boundarydevices.com> <1938105334.2320821.1380657041367.JavaMail.zimbra@advansee.com> Message-ID: <524B3ED3.6010204@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Beno?t, On 10/01/2013 12:50 PM, Beno?t Th?baudeau wrote: > On Tuesday, October 1, 2013 6:17:06 PM, Eric Nelson wrote: >> On 10/01/2013 09:10 AM, Stefano Babic wrote: >>> On 01/10/2013 17:56, Eric Nelson wrote: >>>> On 10/01/2013 07:49 AM, Stefano Babic wrote: >>>>> On 01/10/2013 16:26, Eric Nelson wrote: >>>> ... >>>> Did I miss something in this thread that does actually require >>>> that ability? It seems a pretty obscure thing in the normal case >>>> to drive an output without confidence that it will succeed. >>> >>> Yes, it seems quite strange, but it helps to debug the hardware. It is >>> not the first time we see that, even driving the output, the signal does >>> not go to the expected value, due for example to a conflict (another >>> peripheral driving the signal) or to a wrong pull up resistor. As U-Boot >>> is a great tool for hardware debugging, reading the signal back let >>> check that the output is set to the desired value. >>> >> >> I agree with all of that, though this only covers the case of a >> pin set up as a GPIO output, and that same debugging approach >> is often used for other functions (display data pins, clock inputs >> and outputs, et cetera). >> >> You probably wouldn't just set SION on all pins, right? I suspect >> that there'd be some ramification in terms of power consumption if >> nothing else. > > Right. Well, instead of adding SION to the pin definition header files, then we > could just add SION where needed on a per-pin basis, e.g.: > --- > imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | > IOMUX_CONFIG_SION << MUX_MODE_SHIFT); > --- > > A helper macro could be defined in arch/arm/include/asm/imx-common/iomux-v3.h in > order to simplify the writing, e.g.: > --- > #define MUX_MODE_SION (IOMUX_CONFIG_SION << MUX_MODE_SHIFT) > --- > imx_iomux_v3_setup_pad(MX6_PAD_NANDF_D1__GPIO_2_1 | MUX_MODE_SION); > --- > I like this approach much better since it lets the reader know there's something special about the pin. Regards, Eric