From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nikita Kiryanov <nikita@compulab.co.il>
Date: Wed, 27 Nov 2013 18:11:52 +0200
Subject: [U-Boot] [PATCH] arm: omap3: i2c: don't zero cnt in i2c_write
In-Reply-To: <20131127150928.GA420@bill-the-cat>
References: <1385563449-15094-1-git-send-email-nikita@compulab.co.il>
	<20131127150928.GA420@bill-the-cat>
Message-ID: <529619C8.7040006@compulab.co.il>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 11/27/2013 05:09 PM, Tom Rini wrote:
> On Wed, Nov 27, 2013 at 04:44:09PM +0200, Nikita Kiryanov wrote:
>> The zeroing of I2Ci.I2C_CNT register at the end of i2c_write causes
>> random I2C failures in OMAP3 based devices. This is probably related
>> to the following advisory in OMAP3 errata:
>>
>> I2C Module Does Not Allow 0-Byte Data Requests
>> Details:
>> When configured as the master, the I2C module does not allow 0-byte data
>> transfers. Note: Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will cause
>> undefined behavior.
>> Workaround(s):
>> No workaround. Do not use 0-byte data requests.
>>
>> Make the write conditional so that only non-OMAP3 devices will perform it.
>>
>> Cc: Heiko Schocher <hs@denx.de>
>> Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
>> ---
>>   drivers/i2c/omap24xx_i2c.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
>> index 3d38c03..2862a8f 100644
>> --- a/drivers/i2c/omap24xx_i2c.c
>> +++ b/drivers/i2c/omap24xx_i2c.c
>> @@ -473,7 +473,10 @@ static int omap24_i2c_write(struct i2c_adapter *adap, uchar chip, uint addr,
>>   wr_exit:
>>   	flush_fifo(adap);
>>   	writew(0xFFFF, &i2c_base->stat);
>> +	/* This write is known to cause undefined behavior on OMAP3 */
>> +#ifndef CONFIG_OMAP34XX
>>   	writew(0, &i2c_base->cnt);
>> +#endif
>>   	return i2c_error;
>>   }
>
> Yay for tracking this down.  Can you please expand the comment to
> mention the specific advisory?  Thanks!
>

Sure, but I'm going to let the conversation we have about this issue in
another thread play out a little first.

-- 
Regards,
Nikita.