From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric =?ISO-8859-1?B?QuluYXJk?= Date: Sun, 29 Sep 2013 19:09:53 +0200 Subject: [U-Boot] [PATCH] gpio: mxc_gpio: Fix gpio_get_value() when the GPIO is an output In-Reply-To: <2047769904.2242902.1380460912317.JavaMail.zimbra@advansee.com> References: <1380388964-26009-1-git-send-email-festevam@gmail.com> <2047769904.2242902.1380460912317.JavaMail.zimbra@advansee.com> Message-ID: <20130929190953.4ae4d187@e6520eb> 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, Le Sun, 29 Sep 2013 15:21:52 +0200 (CEST), Beno?t Th?baudeau a ?crit : > Why is this required? Is it because there is a different behavior of the PSR > register on one of the i.MXs? > > See my commit message here: > http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=5dafa4543c399d329c7b01df1afa98437861cac0 > > In case the registers are configured to output some level on a GPIO but there is > a level conflict with other hardware, the general assumption about > gpio_get_value() would probably be that it returns the actual GPIO level, not > the level that the registers try to apply. For the latter, another function > accessing DR could be implemented. > you are right and if that works in the kernel, that should also work in u-boot. It would be interesting to know if the original patch was really fixing a problem as it would be surprising that setting the pin as an input could fix the level sampling problem reliably : Otavio was that tested on real hardware ? BTW Otavio if you read that email through the ML, your MX server rejects my emails : : host mx.ossystems.com.br[66.7.219.172] said: 450 4.1.8 : Sender address rejected: Domain not found (in reply to RCPT TO command) Eric