Re: [PATCH v3] i2c: davinci: Fix race when setting up for TX

[Troy Kisky <troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>]

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?