-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ben Dooks wrote: > On Sun, Oct 12, 2008 at 11:19:53AM +0100, Andy Green wrote: > Hi Ben - > > Is this kind of change to > > arch/arm/mach-s3c2410/include/mach/gpio.h > > 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 >> banks. 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? - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjx2zIACgkQOjLpvpq7dMqPuQCdEIBjbYxbsgQcEFImJ8H5ZfhE 33MAnAt/uD8GG1Obo1dp9ovNgRmAfgnl =OWhg -----END PGP SIGNATURE-----
