From: Alexander Kochetkov <al.kochet@gmail.com>
To: Kevin Hilman <khilman@kernel.org>,
Tony Lindgren <tony@atomide.com>, Felipe Balbi <balbi@ti.com>,
Wolfram Sang <wsa@the-dreams.de>,
Alexander Kochetkov <al.kochet@gmail.com>
Cc: linux-omap@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [RFC 2/2] i2c: omap: show that the reason of system lockup is an unhandled ISR event
Date: Sun, 30 Nov 2014 01:00:03 +0400 [thread overview]
Message-ID: <1417294803-14729-3-git-send-email-al.kochet@gmail.com> (raw)
In-Reply-To: <1417294803-14729-1-git-send-email-al.kochet@gmail.com>
Commit 079d8af24b948261e1dae5d7df6b31b7bf205cb4 ("i2c: omap: bus:
add a receiver flag") changed ISR loop to silently ignore unwanted
XDR/XRDY or RDR/RRDY events without processing. That unwanted events
will fire interrupt again and most likely they will be ignored again.
As a result, system enters lockup state. CPU loops through omap_i2c_isr()
and omap_i2c_isr_thread(). The lockup is signaled with the message
"sched: RT throttling activated" shown on console.
The commit allow unwanted events to enter into processing loop and
to be acked (at least) and processed (show error message).
Sometimes if unwannted event is acked, the ISR can continue it's work.
Sometimes system still remains in the lockup, but at least the reason
is obvious.
That unwanted events I tested with are events from IP slave receiver,
fired when General Call (GC) command is detected on the bus. As after
every master transfer IP enter into slave receiver mode. ISR must be
ready for events from slave receiver or slave receiver must be
disabled after master transfer to avoid lockups.
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
Fixes 079d8af24b948261e1dae5d7df6b31b7bf205cb4 "i2c: omap: bus: add a receiver flag"
---
drivers/i2c/busses/i2c-omap.c | 28 ++++++++++++++++++++++------
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e890295..192f9ce 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -939,6 +939,22 @@ static void omap_i2c_receive_data(struct omap_i2c_dev *dev, u8 num_bytes,
bool is_rdr)
{
u16 w;
+ int warn = 0;
+
+ if (unlikely(!dev->receiver)) {
+ warn = 1;
+ /* REVISIT: errata i207 during transmission? */
+ if (dev->errata & I2C_OMAP_ERRATA_I207) {
+ if (is_rdr & !num_bytes)
+ warn = 0;
+ }
+ num_bytes = 0;
+ }
+
+ if (unlikely(warn)) {
+ dev_err(dev->dev, "%s interrupt while sending\n",
+ is_rdr ? "RDR" : "RRDY");
+ }
if (unlikely(num_bytes > dev->buf_len)) {
dev_err(dev->dev, "%s interrupt can't receive %u byte(s)\n",
@@ -971,6 +987,12 @@ static int omap_i2c_transmit_data(struct omap_i2c_dev *dev, u8 num_bytes,
{
u16 w;
+ if (unlikely(dev->receiver)) {
+ dev_err(dev->dev, "%s interrupt while receiving\n",
+ is_xdr ? "XDR" : "XRDY");
+ num_bytes = 0;
+ }
+
if (unlikely(num_bytes > dev->buf_len)) {
dev_err(dev->dev, "%s interrupt can't transmit %u byte(s)\n",
is_xdr ? "XDR" : "XRDY", (num_bytes - dev->buf_len));
@@ -1043,12 +1065,6 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
stat &= bits;
- /* If we're in receiver mode, ignore XDR/XRDY */
- if (dev->receiver)
- stat &= ~(OMAP_I2C_STAT_XDR | OMAP_I2C_STAT_XRDY);
- else
- stat &= ~(OMAP_I2C_STAT_RDR | OMAP_I2C_STAT_RRDY);
-
if (!stat) {
/* my work here is done */
goto out;
--
1.7.9.5
next prev parent reply other threads:[~2014-11-29 21:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-29 21:00 [RFC 0/2] i2c: omap: new fixes for driver Alexander Kochetkov
2014-11-29 21:00 ` [RFC 1/2] i2c: omap: fix buffer overruns during RX/TX data processing Alexander Kochetkov
[not found] ` <1417294803-14729-2-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-12-01 19:58 ` Tony Lindgren
[not found] ` <20141201195841.GD2817-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2014-12-02 11:17 ` Alexander Kochetkov
[not found] ` <B3F4FEFF-2333-473D-8A35-7D4EF1C44D90-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-12-04 18:09 ` Tony Lindgren
[not found] ` <20141204180946.GG2817-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2014-12-05 17:18 ` Alexander Kochetkov
2014-11-29 21:00 ` Alexander Kochetkov [this message]
[not found] ` <1417294803-14729-1-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-12-01 20:04 ` [RFC 0/2] i2c: omap: new fixes for driver Kevin Hilman
[not found] ` <7hoarn3zme.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2014-12-02 11:21 ` Alexander Kochetkov
2015-01-13 10:04 ` Wolfram Sang
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=1417294803-14729-3-git-send-email-al.kochet@gmail.com \
--to=al.kochet@gmail.com \
--cc=balbi@ti.com \
--cc=khilman@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
--cc=wsa@the-dreams.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).