Hello,
Menon, Nishanth wrote:
-----Original Message-----
From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
owner@xxxxxxxxxxxxxxx] On Behalf Of Sonasath, Moiz
Sent: Monday, June 22, 2009 7:50 PM
To: linux-omap@xxxxxxxxxxxxxxx
Cc: Pandita, Vikram
Subject: [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon
errata 1.153
This patch includes the workarround for I2C Errata 1.153: When an XRDY/XDR
is hit, wait for XUDF before writing data to DATA_REG
Is this workaround valid for omap2430 also?
Some kind of such workaround needs to be applied and for OMAP1 ISR too.
I had
the same problem on our OMAP5910 based custom made board. While writing
a large contiguous amount of data constantly occurs a situation when
dev->buf_len = 0, but I2C_CNT register != 0, and, as result, I2C
controller doesn't generate ARDY IRQ, no complete_cmd occurs in ISR, and
we get "controller timed out" issues then...
So, here is a part of modified OMAP1 ISR. It works for me at least.
/*
* Is there a bug in the OMAP5910 I2C controller? It
* generates a bunch of fake XRDY interrupts under high load.
* As result, there is a very high chance to have a situation
* when dev->buf_len = 0 already, but I2C_CNT != 0. So, there
* is no ARDY irq then, no complete_cmd, controller timed out
* issues...
*
* Workaround:
*
* When we get XRDY interrupt without transmit underflow flag
* (XUDF bit in the I2C_STAT register), delay for 100 microsecs
* and ignore it.
*
* We write data into I2C_DATA register in case of transmit
* underflow condition ONLY.
*/
if (stat & OMAP_I2C_STAT_XRDY) {
if (!(stat & OMAP_I2C_STAT_XUDF)) {
udelay(100);
continue;
} else {
w = 0;
if (dev->buf_len) {
w = *dev->buf++;
dev->buf_len--;
if (dev->buf_len) {
w |= *dev->buf++ << 8;
dev->buf_len--;
}
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
} else {
dev_err(dev->dev, "XRDY IRQ while no "
"data to send\n");
break;
}
continue;
}
}
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
