From: "Eric Bénard" <eric@eukrea.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 20:19:28 +0200 [thread overview]
Message-ID: <20130929201928.7f53de9d@e6520eb> (raw)
In-Reply-To: <CAP9ODKqMbY18AyQobwo51F_5Qw6PODm5sefhdgqU=z1=UFm-Ag@mail.gmail.com>
Le Sun, 29 Sep 2013 14:48:32 -0300,
Otavio Salvador <otavio@ossystems.com.br> a ?crit :
> On Sun, Sep 29, 2013 at 2:09 PM, Eric B?nard <eric@eukrea.com> wrote:
> > Hi Beno?t,
> >
> > Le Sun, 29 Sep 2013 15:21:52 +0200 (CEST),
> > Beno?t Th?baudeau <benoit.thebaudeau@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.
>
on which CPU is that ?
It's strange reading PSR works in the kernel and not in u-boot.
Eric
next prev parent reply other threads:[~2013-09-29 18:19 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
2013-09-29 17:09 ` Eric Bénard
2013-09-29 17:48 ` Otavio Salvador
2013-09-29 18:19 ` Eric Bénard [this message]
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=20130929201928.7f53de9d@e6520eb \
--to=eric@eukrea.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.