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;
+
+ /* 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;
-------------------------------------------------------------------------
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
