[PATCH] fix-lid302dl-bitbang-all-the-way-baby.patch

[Andy Green]

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

Somebody in the thread at some point said:

| I merged this into the stable 2.6.26 git and it breaks battery again :(
|
| It also didn't solve my lockup. It took a little longer, but first
| input3 stopped then input2 just as before.
|
| There is something odd with the gpio stuff as battery was broken first
| by some old cfgpin calls in the led driver. Perhaps all gpio accesses
| should be made atomic if they are not already.

You are right about that, it is read-modify-write action.  But I can't
see how it trashes HDQ or somehow HDQ pin cfg stuff could trash motion
sensor poll.

| I'm curious why setting the pin before the cfgpin is done. This seems
| counter-intuitive. If it was an input and I call set, then configure it
| as an output wouldn't it just latch to what it was before the config or
| is there a mux on a separate output register?

It's to stop glitching.  Consider we want to drive '0' but the output
register contained '1' already, if we set the pin cell to drive first,
so it drives high, only then we set the output register to '0' that we
want it drives low.  So we can send out the wrong level for a short time
that way and get non-deterministic behaviour.

So by setting the output register first when we start to drive from the
pin we know we simply drive the final level only with no glitch.

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

iEYEARECAAYFAki0wicACgkQOjLpvpq7dMpNcQCgi6q6Iw8s80SpoXjWJGg5mUD8
ykgAn3MvT0JQ+2s++S23H2+FvDkuEQl6
=7R8v
-----END PGP SIGNATURE-----