On Thu, Jun 13, 2013 at 11:33:56AM +0300, Andy Shevchenko wrote: > On Thu, 2013-06-13 at 10:16 +0200, Christian Ruppert wrote: > > As promised, I gave this one some over-night stress testing and I can > > confirm what I said previously: > > > > - The patch does _not_ solve the interrupt loop lockups on its own. > > So, it just means my assumptions about what is happening there were > wrong. So were my initial ones... Or at least insufficient. > > - The patch works well in conjunction with > > http://patchwork.ozlabs.org/patch/249622/ (which in turn depends on > > Mika's patch). Under this condition you can assume > > Tested-By: Christian Ruppert <christian.ruppert@xxxxxxxxxx> > > > > I still think the code is more logical with this patch than without it > > and I am in favour of applying both (if Andy agrees that is). > > Since my patch doesn't fix anything, I think we may drop it away. > > > We must keep in mind, however, that http://patchwork.ozlabs.org/patch/249622 > > does fix a real problem we can observe on our chip and for our TB10x > > product we do require some form of it for stability reasons. > > I feel like a real fix is to add a memory barier to make changes in the > structure consistent. However, I have no clue where. I'm still not sure about the interrupt behaviour of the dw-i2c block in the case of error (and since our problem is fixed it's difficult to justify spending time to investigate further). I suspect that the thing in some situations sends spurious interrupts which confuse the state machine - in which case memory barriers won't help us either. Greetings, Christian -- Christian Ruppert , <christian.ruppert@xxxxxxxxxx> /| Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri _// | bilis Systems CH-1228 Plan-les-Ouates -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
