[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 <[email protected]> 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 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
