Jean-Christophe PLAGNIOL-VILLARD schrieb:
> On 16:50 Fri 04 Jul , Jens Gehrlein wrote:
>> On fast CPUs the time between two chip queries can become too short
>> to issue clear start and stop conditions. The bus seems to be blocked.
>> This cannot be compensated by just waiting for completed byte transfer.
>> The patch introduces polling of the bus busy bit in the I2C
>> controller's status register before the next bus access is possible.
>>
>> Signed-off-by: Jens Gehrlein <[EMAIL PROTECTED]>
>> ---
>>
>> drivers/i2c/mxc_i2c.c | 10 ++++++++++
>> 1 files changed, 10 insertions(+), 0 deletions(-)
>>
>>
>> diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
>> index a218329..6f9306f 100644
>> --- a/drivers/i2c/mxc_i2c.c
>> +++ b/drivers/i2c/mxc_i2c.c
>> @@ -115,6 +115,16 @@ static int rx_byte(void)
>> int i2c_probe(uchar chip)
>> {
>> int ret;
>> + int timeout = 100000;
> Could you explain why 100000?
>> +
>> + /* Check if bus is busy before probing next chip */
>> + while ((__REG16(I2C_BASE + I2SR) & I2SR_IBB) && --timeout)
>> + udelay(1);
>> +
>> + if (timeout == 0) {
>> + printf ("\nerror: bus blocked\n");
>> + return -1;
>> + }
>>
>> __REG16(I2C_BASE + I2CR) = 0; /* Reset module */
>> __REG16(I2C_BASE + I2CR) = I2CR_IEN;
You are right. 100 ms is too high, although it should be irrelevant for
a U-Boot command. Measurement showed, that some 100 microseconds would
be enough. Do you agree if I set the timeout value to 1 ms? Other proposals?
Kind regards,
Jens
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
