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

Benoît Thébaudeau benoit.thebaudeau at advansee.com
Sun Sep 29 15:21:52 CEST 2013


Hi Fabio,

On Saturday, September 28, 2013 7:22:44 PM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam at freescale.com>
> 
> When the GPIO is configured as an output, we should return the value from the
> DR
> register.
> 
> This implements the same fix as in the following kernel commit from FSL BSP:
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/arch/arm/plat-mxc/gpio.c?h=imx_3.0.35_4.1.0&id=d6f32393eaf455ce3c32d4e9bafd34d9091eaf45

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.

One could also argue that such GPIO level conflicts are just the result of a
flawed hardware design, and so that normal software should not care about such a
case. But it's good to be able to detect hardware issues from software, and this
patch seems to change the meaning of gpio_get_value() to cover some hardware
issue. Please give more details.

In any case, there should probably be a comment in the code for this function to
explain the various issues and how they are addressed.

Best regards,
Benoît


More information about the U-Boot mailing list