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