Reason for the "one dot" hang found!

[Jonathan Corbet]

[Sorry for the slow response...naturally enough I'm in Europe and
falling behind on things.

On Thu, 10 Jun 2010 18:01:34 -0400
Paul Fox <pgf at laptop.org> wrote:

>  > I doubt it is directly related to locking.
>  > If (as you say) there is no crash in the logs then I suspect it is
>  > related to an infinite loop within the initialization code.

Definitely not locking, there is nothing complex or strange about the
locking there.

>  > And this all seems very familiar. Google for a thread titled
>  > "cafe_ccic/ov7670 hang on boot" from the 8.2 days.
>  > I suspect we never fixed that bug upstream and that same commit needs
>  > to be reverted from the new kernel.  
> 
> good catch, good call.  commit 8815ea29a9bcbab2a3c7fbc28987cac67c2c41d0
> is a revert for 6d77444aca298b43a88086be446f943cd0442ef7, and is present
> in the testing branch (i.e., XO-1 802 and earlier), but not in our
> current 2.6.31 branch.

Wow, ancient history.  I don't really remember what I was thinking at
the time.  Clearly we're seeing yet another i2c flake, something that
both Cafe and ov7670 are good at doing.

There are a couple of ways in which a rewrite of the i2c controller
code could help.  Bypassing the Cafe SMBUS controller and letting the
kernel bit-bang the protocol would probably work a lot better than what
we have now.  I can put that on my list, but I can't promise to get to
get to it soon - more travel looms.

Alternatives:

 - Just mainline the revert so you don't get burned again.  I don't
   believe there are any other users of the cafe_ccic driver, so
   nobody's going to complain.

 - Experiment with the timeout in the do...while loop; s/1/2/ might be
   enough to keep from reading the TSIC1 register before it's prepared
   to deal with the world again.

jon