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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
