Updated switch/glue patch?
Adrian Chadd
adrian at freebsd.org
Sun Dec 18 09:54:03 UTC 2011
.. and some further digging - I've flipped on the i2c_debug value and
slightly modified the debug printing so each _stop call prints a
newline. It makes it very clear how transactions are being handled.
Anyway, there's plenty of instances (even with the transaction DELAY
being 10uS) of the last byte being not acked, ie:
<wa8+ w00+ w80+ w01+ w00+ >
<wa8+ w00+ w90+ w00+ w00+ >
<wa9+ w02+ w80+ r00+ r10- >
<wa8+ w00+ w80+ w01+ w00+ >
<wa8+ w01+ wa0+ w00+ w00+ >
<wa9+ w02+ w80+ r49+ r79- >
<wa8+ w00+ w80+ w01+ w00+ >
<wa8+ w01+ wa0+ w00+ w00+ >
<wa9+ w02+ w80+ r49+ r79- >
<wa8+ w00+ w80+ w01+ w00+ >
<wa8+ w01+ wa0+ w00+ w00+ >
<wa9+ w02+ w80+ r49+ r79- >
.. all of those read transactions that aren't acked, are they ok?
Just as a side note - reducing the udelay value from 10 to 1 in my git
tree doesn't stop the huge CPU use. I'm going to next try removing the
locking, as I note that each GPIO access involves a mutex lock and I
bet the witness code is taking a freaking beating here.
adrian
More information about the freebsd-embedded
mailing list