From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Gehrlein Date: Mon, 07 Jul 2008 14:21:16 +0200 Subject: [U-Boot-Users] [PATCH 01/10] [ARM] MXC: insert bus busy check in i2c_probe In-Reply-To: <20080705155928.GA9234@game.jcrosoft.org> References: <20080704144552.12049.55374.stgit@tq-sewsrv-4.tq-net.de> <20080704145004.12049.35519.stgit@tq-sewsrv-4.tq-net.de> <20080705155928.GA9234@game.jcrosoft.org> Message-ID: <48720A3C.4040206@tqs.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >> --- >> >> 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