On Mon, 2017-05-29 at 23:04 +0200, Wolfram Sang wrote: > On Tue, May 23, 2017 at 01:47:34PM +0000, Joakim Tjernlund wrote: > > On Tue, 2017-05-16 at 17:13 +0200, Joakim Tjernlund wrote: > > > On Thu, 2017-05-11 at 14:20 +0200, Joakim Tjernlund wrote: > > > > Current I2C reset procedure is broken in two ways: > > > > 1) It only generate 1 START instead of 9 STARTs and STOP. > > > > 2) It leaves the bus Busy so every I2C xfer after the first > > > > fixup calls the reset routine again, for every xfer there after. > > > > > > > > This fixes both errors. > > > > > > Ping? > > > > Ping again, pretty please? > > I am interested in this patch. Especially why you think the generic > recovery structure is not suitable and if we maybe need to update that, I did my I2C reset analysis many years ago but I found the reason in som old code I had lying around, just sending 9 clocks will not recover the case when stuck in an I2C write sequence. Adding START into the sequence keeps the device in START once it has seen at least one START, then the STOP will release the bus in the end. Other that that I am just not familiar enough with the new recovery structure. > too. But I need time to think into it and that may still need 1-2 weeks. > I am aiming for 4.12 nonetheless. Thanks, I will probably loose track of this one if it doesn't. Jocke-- 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
