From: "Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] gpio: mxc_gpio: Fix gpio_get_value() when the GPIO is an output
Date: Sun, 29 Sep 2013 15:21:52 +0200 (CEST) [thread overview]
Message-ID: <2047769904.2242902.1380460912317.JavaMail.zimbra@advansee.com> (raw)
In-Reply-To: <1380388964-26009-1-git-send-email-festevam@gmail.com>
Hi Fabio,
On Saturday, September 28, 2013 7:22:44 PM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@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
next prev parent reply other threads:[~2013-09-29 13:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-28 17:22 [U-Boot] [PATCH] gpio: mxc_gpio: Fix gpio_get_value() when the GPIO is an output Fabio Estevam
2013-09-28 19:04 ` Otavio Salvador
2013-09-29 13:21 ` Benoît Thébaudeau [this message]
2013-09-29 17:09 ` Eric Bénard
2013-09-29 17:48 ` Otavio Salvador
2013-09-29 18:19 ` Eric Bénard
2013-09-29 18:22 ` Fabio Estevam
2013-09-29 18:26 ` Eric Bénard
2013-09-29 18:48 ` Fabio Estevam
2013-09-29 18:50 ` Benoît Thébaudeau
2013-09-29 18:58 ` Fabio Estevam
2013-09-29 19:25 ` Benoît Thébaudeau
2013-09-29 19:42 ` Otavio Salvador
2013-09-29 19:45 ` Benoît Thébaudeau
2013-09-29 19:49 ` Otavio Salvador
2013-09-29 22:24 ` Otavio Salvador
2013-09-30 1:32 ` Fabio Estevam
2013-09-30 11:08 ` Benoît Thébaudeau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2047769904.2242902.1380460912317.JavaMail.zimbra@advansee.com \
--to=benoit.thebaudeau@advansee.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox