[PATCH] [GPIO]: Handle GPIO shadowing with generic GPIOs

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jonas Bonn wrote:
>>> 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.
> 
> My reading of the generic GPIO API (Documentation/gpio.txt) is that
> <mach/gpio.h> is the correct place to make machine-specific
> implementations of gpio_set/get_value.  The simplest case is what we
> had before I added the GTA02 bits (defer to chip-specific routines),
> but the option of adding inline functions there is explicitly
> suggested in the documentation.
> 
> I can see that perhaps we don't want to clutter that file too much, in
> which case we could pull our GTA02 bits out into a file
> <mach/gpio-gta02.h> which gets pulled in for GTA02 only; this doesn't
> really change the fact that we need to make at least some minor
> modification to <mach/gpio.h>, though.

Sounds fair enough.

> Of course, all this is moot if "generic shadowing" is added, but that
> really seems like overkill to me at this point, especially considering
> that this is a workaround for buggy hardware.
> 
> Just my two cents worth.

There can be a general logical problem with writing output state into a
register and not reading back the same data as you could reasonably
expect.  I have to agree though that you have problems with your design
if you ever meet this... but we do have that problem with A5 revision.

If all s3c24xx are like it I guess it increases the chance of generic
implementation making sense.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjzAm8ACgkQOjLpvpq7dMqA6gCdGa8XXZJODVRKAO/mIZiuSuT0
e/IAnj+/3uHiRE9BdB5s0+0vWUOcga7+
=YbXg
-----END PGP SIGNATURE-----