On 9/17/2010 6:09 AM, Sudhakar Rajashekhara wrote: > Hi, > > On Fri, Sep 17, 2010 at 08:32:11, Jon Povey wrote: >> When setting up to transmit, a race exists between the ISR and >> i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. >> This is mostly visible for transmits > 1 byte long. >> >> The hardware starts sending immediately that MDR is loaded. IMR trickery >> doesn't work because if we start sending, finish the first byte and an >> XRDY event occurs before we load IMR to unmask it, we never get an >> interrupt, and we timeout. >> >> Move the MDR load after DXR,IMR loads to avoid this race without locking. >> >> Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 >> > > I remember I had some issues on OMAP-L138 with this fix, that's when I > reverted to configuring ICMDR before writing to DXR (Please see here: > https://patchwork.kernel.org/patch/75262/). I checked the BIOS I2C > driver code for OMAP-L138 and there also we are configuring MDR before > accessing DXR. > > Regards, > Sudhakar How about killing the lines from commit c6c7c729a22bfeb8e63eafce48dbaeea20e68703 ------------------------------- /* * First byte should be set here, not after interrupt, * because transmit-data-ready interrupt can come before * NACK-interrupt during sending of previous message and * ICDXR may have wrong data */ if ((!(msg->flags & I2C_M_RD)) && dev->buf_len) { davinci_i2c_write_reg(dev, DAVINCI_I2C_DXR_REG, *dev->buf++); dev->buf_len--; } ---------------------- and resetting the i2c upon a NAK interrupt (after the stop) to clear the bad fifo data? -- 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
