From: Igor Mazanov <i.mazanov@gmail.com>
To: linux-omap@vger.kernel.org
Subject: Re: [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon errata 1.153
Date: Tue, 23 Jun 2009 17:43:01 +0400 [thread overview]
Message-ID: <h1qm0f$r7c$1@ger.gmane.org> (raw)
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C0115F50E6C@dlee02.ent.ti.com>
Hello,
Menon, Nishanth wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
>> owner@vger.kernel.org] On Behalf Of Sonasath, Moiz
>> Sent: Monday, June 22, 2009 7:50 PM
>> To: linux-omap@vger.kernel.org
>> 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.
next prev parent reply other threads:[~2009-06-23 13:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-22 16:49 [PATCH] [RFC][OMAP3:I2C]Workaround for OMAP3430 I2C silicon errata 1.153 Sonasath, Moiz
2009-06-22 22:30 ` Kevin Hilman
2009-06-23 9:55 ` Kamat, Nishant
2009-06-23 10:05 ` Menon, Nishanth
2009-06-23 2:17 ` Paul Walmsley
2009-07-08 16:50 ` Paul Walmsley
2009-07-08 18:21 ` Sonasath, Moiz
2009-06-23 4:20 ` Menon, Nishanth
2009-06-23 13:43 ` Igor Mazanov [this message]
2009-06-23 19:06 ` Menon, Nishanth
2009-06-25 17:17 ` Igor Mazanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='h1qm0f$r7c$1@ger.gmane.org' \
--to=i.mazanov@gmail.com \
--cc=linux-omap@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.