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 4/5] i2c: omap: reimpelement STP hack via 2-phases transfer
Date: Wed, 3 Dec 2014 18:34:01 +0400 [thread overview]
Message-ID: <1417617242-16869-5-git-send-email-al.kochet@gmail.com> (raw)
In-Reply-To: <1417617242-16869-1-git-send-email-al.kochet@gmail.com>
The main reason is to avoid CON register access by omap_i2c_xfer_msg()
function, after transfer was submitted to IP.
The change takes into account comment from the code:
"Don't write stt and stp together on some hardware."
That mean, what some hardware doesn't support "Full transfers",
transfers with STT and STP bits set together.
While this is doesn't correspond errata and TRM, assume it's true.
According to TRM, "Full transfer" could be expessed with "2 phases transfer":
first start with STT and STP bits set to 1 and 0, second with
0 and 1.
The change affects omap3530 and early boards.
Tested and simulated on omap3730 (Beagleboard XM C).
Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
drivers/i2c/busses/i2c-omap.c | 46 ++++++++++++++++++++---------------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9e0d359..66506db 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -213,6 +213,7 @@ struct omap_i2c_dev {
* the I2C bus state
*/
unsigned receiver:1; /* true when we're in receiver mode */
+ unsigned stop:1; /* ISR send STP after xfer */
u16 iestate; /* Saved interrupt register */
u16 pscstate;
u16 scllstate;
@@ -669,6 +670,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (!dev->b_hw && stop)
w |= OMAP_I2C_CON_STP;
/*
+ * Don't write stt and stp together on some hardware.
+ */
+ dev->stop = (dev->b_hw && stop);
+
+ /*
* NOTE: STAT_BB bit could became 1 here if another master occupy
* the bus. IP successfully complete transfer when the bus will be
* free again (BB reset to 0).
@@ -676,29 +682,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
/*
- * Don't write stt and stp together on some hardware.
- */
- if (dev->b_hw && stop) {
- unsigned long delay = jiffies + OMAP_I2C_TIMEOUT;
- u16 con = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
- while (con & OMAP_I2C_CON_STT) {
- con = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
-
- /* Let the user know if i2c is in a bad state */
- if (time_after(jiffies, delay)) {
- dev_err(dev->dev, "controller timed out "
- "waiting for start condition to finish\n");
- return -ETIMEDOUT;
- }
- cpu_relax();
- }
-
- w |= OMAP_I2C_CON_STP;
- w &= ~OMAP_I2C_CON_STT;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
- }
-
- /*
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
@@ -1021,6 +1004,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
if (stat & OMAP_I2C_STAT_NACK) {
u16 con;
+ dev->stop = 0;
dev->cmd_err |= OMAP_I2C_STAT_NACK;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
@@ -1041,6 +1025,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
if (stat & OMAP_I2C_STAT_AL) {
dev_err(dev->dev, "Arbitration lost\n");
+ dev->stop = 0;
err |= OMAP_I2C_STAT_AL;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL);
}
@@ -1051,6 +1036,21 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
if (stat & OMAP_I2C_STAT_ARDY)
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ARDY);
+ if ((stat & OMAP_I2C_STAT_ARDY) && dev->stop) {
+ u16 con;
+ /* Second phase transfer with STT:STP=01 */
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ARDY);
+ dev->stop = 0;
+
+ con = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+ con |= OMAP_I2C_CON_STP;
+ con &= ~OMAP_I2C_CON_STT;
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, con);
+
+ /* Wait for the next ARDY */
+ continue;
+ }
+
if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_AL)) {
/*
* These are pending events not handled in time
--
1.7.9.5
next prev parent reply other threads:[~2014-12-03 14:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-03 14:33 [RFC 0/5] i2c: omap: new fixes 2 Alexander Kochetkov
2014-12-03 14:33 ` [RFC 1/5] i2c: omap: ack only reported events Alexander Kochetkov
2014-12-03 14:33 ` [RFC 2/5] i2c: omap: simplify i462 errata handling for NACK and AL cases Alexander Kochetkov
2014-12-03 14:34 ` [RFC 3/5] i2c: omap: move STP generation logic into ISR thread Alexander Kochetkov
2014-12-03 14:34 ` Alexander Kochetkov [this message]
2014-12-03 14:34 ` [RFC 5/5] i2c: omap: add trace Alexander Kochetkov
[not found] ` <1417617242-16869-6-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-12-03 14:49 ` Felipe Balbi
2014-12-03 14:52 ` Alexander Kochetkov
[not found] ` <2E40A984-A6AA-4D17-AB1D-725004EF845F-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-12-03 14:55 ` Felipe Balbi
[not found] ` <1417617242-16869-1-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-12-04 18:23 ` [RFC 0/5] i2c: omap: new fixes 2 Tony Lindgren
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=1417617242-16869-5-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).