[PATCH] [GPIO]: Handle GPIO shadowing with generic GPIOs
andy at openmoko.com
Sun Oct 12 13:10:43 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Ben Dooks wrote:
> On Sun, Oct 12, 2008 at 11:19:53AM +0100, Andy Green wrote:
> Hi Ben -
> Is this kind of change to
> generally going to be acceptable upstream? This is a workaround for an
> output GPIO which is loaded so heavily on some board revisions here the
> input register for it does not read back the true drive level.
>> Hmm, this is an interesting problem, I did think that when a pin was
>> in output mode GPxDAT actually read back the value of the output latch
>> and not the actual pin. Is it possible to expand on the actual cause
>> of the problem?
I'm running on hearsay.... we have this existing shadowing concept and
now a patch has turned up to bury it in platform GPIO stuff. The
shadowing thing was originally done by Holger based on observation that
we were somehow reading back wrong state on this bad pin on bad board rev.
The GPBDAT description is ambiguous: "When the port is configured as
input port, the corresponding bit is the pin state. When the port is
configured as output port, the ** pin state is the same as the
corresponding bit **. When the port is configured as functional pin,
**the undefined value will be read**." That is all actually completely
compatible with simply showing dynamic state at the pad cell in GPBDAT.
The mistake we made on that board revision was to drive NPN transistor
base with no series resistor. So we assert GPIO as HIGH output, the
base current is so much that we only reach less than 1V, it does not
pass threshold for input stage HIGH, therefore state is read back as LOW
despite we are actually driving a nobbled HIGH. This then breaks later
boolean ops on the register.
>> I am actively interested in removing as many of the s3c24xx gpio calls
>> and replace them with the gpio library. As you may note, there are
>> several driver patches being pushed to move some of the s3c24xx drivers
>> to using these calls.
>> If we are using gpiolib, then moving the entirety of the gpio range to
>> have a shadow would be easier on the hacking of the code for specific
Well, maybe it is interesting generally, if what I describe above is
actually true as I believe.
Side issue on it, GPIO stuff does deal with IRQ but currently doesn't
lock out FIQ, is that likely to change?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel