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,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
