From: khilman@deeprootsystems•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] i2c: omap: ensure writes to dev->buf_len are ordered
Date: Thu, 25 Oct 2012 09:38:06 -0700 [thread overview]
Message-ID: <8739124idt.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1351155648-20429-1-git-send-email-balbi@ti.com> (Felipe Balbi's message of "Thu, 25 Oct 2012 12:00:48 +0300")
+Paul
Felipe Balbi <balbi@ti•com> writes:
> if we allow compiler reorder our writes, we could
> fall into a situation where dev->buf_len is reset
> for no apparent reason.
Any chance this would help with the bug Paul found with I2C timeouts on
beagle userspace startup?
Kevin
> This bug was found with a simple script which would
> transfer data to an i2c client from 1 to 1024 bytes
> (a simple for loop), when we got to transfer sizes
> bigger than the fifo size, dev->buf_len was reset
> to zero before we had an oportunity to handle XDR
> Interrupt. Because dev->buf_len was zero, we entered
> omap_i2c_transmit_data() to transfer zero bytes,
> which would mean we would just silently exit
> omap_i2c_transmit_data() without actually writing
> anything to DATA register. That would cause XDR
> IRQ to trigger forever and we would never transfer
> the remaining bytes.
>
> After adding the memory barrier, we also drop resetting
> dev->buf_len to zero in omap_i2c_xfer_msg() because
> both omap_i2c_transmit_data() and omap_i2c_receive_data()
> will act until dev->buf_len reaches zero, rendering the
> other write in omap_i2c_xfer_msg() redundant.
>
> This patch has been tested with pandaboard for a few
> iterations of the script mentioned above.
>
> Signed-off-by: Felipe Balbi <balbi@ti•com>
> ---
>
> This bug has been there forever, but it's quite annoying.
> I think it deserves being pushed upstream during this -rc
> cycle, but if Wolfram decides to wait until v3.8, I don't
> mind.
>
> drivers/i2c/busses/i2c-omap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index db31eae..1ec4e6e 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -521,6 +521,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
> /* REVISIT: Could the STB bit of I2C_CON be used with probing? */
> dev->buf = msg->buf;
> dev->buf_len = msg->len;
> + wmb();
>
> omap_i2c_write_reg(dev, OMAP_I2C_CNT_REG, dev->buf_len);
>
> @@ -579,7 +580,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
> */
> timeout = wait_for_completion_timeout(&dev->cmd_complete,
> OMAP_I2C_TIMEOUT);
> - dev->buf_len = 0;
> if (timeout == 0) {
> dev_err(dev->dev, "controller timed out\n");
> omap_i2c_init(dev);
next prev parent reply other threads:[~2012-10-25 16:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-25 9:00 [PATCH] i2c: omap: ensure writes to dev->buf_len are ordered Felipe Balbi
2012-10-25 9:16 ` Shubhrajyoti Datta
2012-10-25 16:38 ` Kevin Hilman [this message]
2012-10-25 18:03 ` Felipe Balbi
2012-10-26 23:01 ` Paul Walmsley
2012-10-27 10:50 ` Santosh Shilimkar
2012-10-27 15:59 ` Paul Walmsley
2012-10-28 4:11 ` Santosh Shilimkar
2012-11-01 22:23 ` Wolfram Sang
2012-11-02 8:54 ` Felipe Balbi
2012-11-05 8:04 ` [PATCH v2] " Felipe Balbi
2012-11-14 11:20 ` Wolfram Sang
2012-11-14 14:22 ` [PATCH v3] " Felipe Balbi
2012-11-14 16:46 ` 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=8739124idt.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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