andy at openmoko.com
Wed Aug 27 04:55:35 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
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
| 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.
-----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