Hi Sekhar,
Thanks for rapidly weighing-in here.
On Thu, Mar 17, 2011 at 10:28 AM, Nori, Sekhar <nsekhar@xxxxxx> wrote:
> On Thu, Mar 17, 2011 at 18:55:00, Ben Gardiner wrote:
>
>> I noticed on the e2e forums that there is a reason why the PSP uses a
>> bitbanging i2c interface -- since the 1.0v OPP makes the i2c
>> controller unusable [1] (I've added Sekhar to the CC since he pointed
>> out the problem in that post).
>
> There was a problem with the way I2C was implemented on the SoM. Here is
> the information I have for the modifications required on the SoM.
>
> "
> It is likely that the errors seen were a result of the buffer on the I2C clock. The hardware fix for this issue is to remove U24 and R161 and short U24 pins 2 to 4.
> "
>
> There should be an EVM with these fixes already, though I have not
> tested it myself.
>
> Also, recently a bug in the I2C driver was brought to my attention.
> In the bus busy function:
>
> /*
> * Waiting for bus not busy
> */
> static int i2c_davinci_wait_bus_not_busy(struct davinci_i2c_dev *dev,
> char allow_sleep)
> {
> unsigned long timeout;
> static u16 to_cnt;
>
> timeout = jiffies + dev->adapter.timeout;
> while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
> & DAVINCI_I2C_STR_BB) {
> if (to_cnt <= DAVINCI_I2C_MAX_TRIES) {
> if (time_after(jiffies, timeout)) {
> dev_warn(dev->dev,
> "timeout waiting for bus ready\n");
> to_cnt++;
> return -ETIMEDOUT;
> } else {
> to_cnt = 0;
> i2c_recover_bus(dev);
> i2c_davinci_init(dev);
> }
> }
> if (allow_sleep)
> schedule_timeout(1);
> }
>
> return 0;
> }
>
> If there is a context switch immediately after the while statement,
> the loop can return a timeout error while there is none. The
> simple solution would be to check for bus busy again if the
> timeout condition occurs. There should be a more elegant way
> to write the loop, but it is too late in the evening to think
> about it :)
>
> I doubt if this is related to the errors you guys are seeing,
> but it is worth trying anyway.
Thanks. I tried it (anyways) but there was no change in behaviour here
(diff attached).
I've posted to the e2e forum [1]. I hope it turns up some more info.
Best Regards,
Ben Gardiner
[1] http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/99895/350080.aspx
---
Nanometrics Inc.
http://www.nanometrics.ca
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 5795c83..ab8e0f3 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -44,7 +44,7 @@
/* ----- global defines ----------------------------------------------- */
-#define DAVINCI_I2C_TIMEOUT (1*HZ)
+#define DAVINCI_I2C_TIMEOUT (2*HZ)
#define DAVINCI_I2C_MAX_TRIES 2
#define I2C_DAVINCI_INTR_ALL (DAVINCI_I2C_IMR_AAS | \
DAVINCI_I2C_IMR_SCD | \
@@ -282,7 +282,10 @@ static int i2c_davinci_wait_bus_not_busy(struct
davinci_i2c_dev *dev,
while (davinci_i2c_read_reg(dev, DAVINCI_I2C_STR_REG)
& DAVINCI_I2C_STR_BB) {
if (to_cnt <= DAVINCI_I2C_MAX_TRIES) {
- if (time_after(jiffies, timeout)) {
+ if (time_after(jiffies, timeout)
+ && (davinci_i2c_read_reg(dev,
+ DAVINCI_I2C_STR_REG)
+ & DAVINCI_I2C_STR_BB)) {
dev_warn(dev->dev,
"timeout waiting for bus ready\n");
to_cnt++;
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
