Daniel Drake <[EMAIL PROTECTED]> wrote: > As far as we can see, this patch was never included in any OLPC builds. > However, we do ship some other delay improvements such as > http://dev.laptop.org/git?p=olpc-2.6;a=commitdiff;h=4ef53002
That patch is a bit of a sledgehammer approach; it really should not be necessary to do things that way. > Any thoughts on where we go from here? I'll try to look into it tomorrow. Things may be slow; whenever I get back into OLPC stuff after a long lapse it always seems to take me a day to get back to where I can build new kernels and successfully install them on a laptop. Meanwhile: > I added a loop counter and made it print out a message when it reaches > the 500th iteration. It hit the condition rather quickly, and in the > first case: addr=0x42 command=0x46 value=0x58 How quickly? Given the schedule_timeout(1) call, it should take a good five seconds to iterate five hundred times at HZ=100. Might you (generic OLPC "you") have bumped HZ at some point? If you have a moment, could you try restoring the upstream code, but changing the schedule_timeout() line to: schedule_timeout(10); My current hypothesis is that something is making the timeout happen too quickly; if you try to query the Cafe chip too soon after starting an SMBUS transfer, it goes off into a sulk and does weird things. Assuming that it's not interrupting (and it shouldn't be given that it has no status to report), lengthening the timeout should tell whether this idea has any basis in reality or not. Thanks, jon _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel