[U-Boot] [PATCH] gpio: mxc_gpio: Fix gpio_get_value() when the GPIO is an output

[Otavio Salvador]

On Sun, Sep 29, 2013 at 2:09 PM, Eric Bénard <eric at eukrea.com> wrote:
> Hi Benoît,
>
> Le Sun, 29 Sep 2013 15:21:52 +0200 (CEST),
> Benoît Thébaudeau <benoit.thebaudeau at advansee.com> 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 ?

Yes; it did.

Both my original patch (setting it as input) and Fabio's one checking
the other register when in output worked fine.

> BTW Otavio if you read that email through the ML, your MX server rejects
> my emails :
> <otavio at ossystems.com.br>: host mx.ossystems.com.br[66.7.219.172] said:
> 450 4.1.8 <eric at eukrea.com>: Sender address rejected: Domain not found
> (in reply to RCPT TO command)

Indeed. I am trying to fix it :-( my bad.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750