From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Wolfram Sang <wsa@the-dreams.de>, linux-i2c@vger.kernel.org
Cc: linux-sh@vger.kernel.org, Magnus Damm <magnus.damm@gmail.com>,
Simon Horman <horms@verge.net.au>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Kuninori Morimoto <kuninori.morimoto.gx@gmail.com>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v3 09/11] i2c: rcar: revoke START request early
Date: Thu, 31 Mar 2016 21:02:56 +0000 [thread overview]
Message-ID: <56FD9080.4090203@cogentembedded.com> (raw)
In-Reply-To: <1447948611-2615-10-git-send-email-wsa@the-dreams.de>
Hello.
On 11/19/2015 06:56 PM, Wolfram Sang wrote:
> From: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
> If we don't clear START generation as soon as possible, it may cause
> another message to be generated, e.g. when receiving NACK in address
> phase. To keep the race window as small as possible, we clear it right
> at the beginning of the interrupt. We don't need any checks since we
> always want to stop START and STOP generation on the next occasion after
> we started it.
>
> This patch improves the situation but sadly does not completely fix it.
> It is still to be researched if we can do better given this HW design.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Thanks for a great work, Wolfram!
We need this patch in -stable kernels. The R-Car audio just doesn't work
without it...
> ---
> drivers/i2c/busses/i2c-rcar.c | 23 +++++++----------------
> 1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
> index f237b4fc5b5e55..40979130200935 100644
> --- a/drivers/i2c/busses/i2c-rcar.c
> +++ b/drivers/i2c/busses/i2c-rcar.c
> @@ -83,6 +83,7 @@
>
> #define RCAR_BUS_PHASE_START (MDBS | MIE | ESG)
> #define RCAR_BUS_PHASE_DATA (MDBS | MIE)
> +#define RCAR_BUS_MASK_DATA (~(ESG | FSB) & 0xFF)
> #define RCAR_BUS_PHASE_STOP (MDBS | MIE | FSB)
>
> #define RCAR_IRQ_SEND (MNR | MAL | MST | MAT | MDE)
> @@ -289,13 +290,6 @@ static void rcar_i2c_irq_send(struct rcar_i2c_priv *priv, u32 msr)
> if (!(msr & MDE))
> return;
>
> - /*
> - * If address transfer phase finished,
> - * goto data phase.
> - */
> - if (msr & MAT)
> - rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_DATA);
> -
> if (priv->pos < msg->len) {
> /*
> * Prepare next data to ICRXTX register.
> @@ -345,11 +339,7 @@ static void rcar_i2c_irq_recv(struct rcar_i2c_priv *priv, u32 msr)
> return;
>
> if (msr & MAT) {
> - /*
> - * Address transfer phase finished,
> - * but, there is no data at this point.
> - * Do nothing.
> - */
> + /* Address transfer phase finished, but no data at this point. */
> } else if (priv->pos < msg->len) {
> /*
> * get received data
> @@ -365,8 +355,6 @@ static void rcar_i2c_irq_recv(struct rcar_i2c_priv *priv, u32 msr)
> */
> if (priv->pos + 1 >= msg->len)
> rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_STOP);
> - else
> - rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_DATA);
>
> if (priv->pos = msg->len && !(priv->flags & ID_LAST_MSG))
> rcar_i2c_next_msg(priv);
> @@ -432,7 +420,11 @@ static bool rcar_i2c_slave_irq(struct rcar_i2c_priv *priv)
> static irqreturn_t rcar_i2c_irq(int irq, void *ptr)
> {
> struct rcar_i2c_priv *priv = ptr;
> - u32 msr;
> + u32 msr, val;
> +
> + /* Clear START or STOP as soon as we can */
> + val = rcar_i2c_read(priv, ICMCR);
> + rcar_i2c_write(priv, ICMCR, val & RCAR_BUS_MASK_DATA);
>
> msr = rcar_i2c_read(priv, ICMSR);
>
> @@ -454,7 +446,6 @@ static irqreturn_t rcar_i2c_irq(int irq, void *ptr)
> /* Nack */
> if (msr & MNR) {
> /* HW automatically sends STOP after received NACK */
> - rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_DATA);
> rcar_i2c_write(priv, ICMIER, RCAR_IRQ_STOP);
> rcar_i2c_flags_set(priv, ID_NACK);
> goto out;
MBR, Sergei
next prev parent reply other threads:[~2016-03-31 21:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-19 15:56 [PATCH v3 00/11] i2c: rcar: tackle race conditions in the driver Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 01/11] i2c: rcar: make sure clocks are on when doing clock calculation Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 02/11] i2c: rcar: rework hw init Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 03/11] i2c: rcar: remove unused IOERROR state Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 04/11] i2c: rcar: remove spinlock Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 05/11] i2c: rcar: refactor setup of a msg Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 06/11] i2c: rcar: init new messages in irq Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 07/11] i2c: rcar: don't issue stop when HW does it automatically Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 08/11] i2c: rcar: check master irqs before slave irqs Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 09/11] i2c: rcar: revoke START request early Wolfram Sang
2016-03-31 21:02 ` Sergei Shtylyov [this message]
2016-03-31 22:48 ` Wolfram Sang
2016-04-01 19:55 ` Sergei Shtylyov
2016-04-01 20:14 ` Wolfram Sang
2016-04-01 23:05 ` Sergei Shtylyov
2016-04-02 7:27 ` Wolfram Sang
2016-04-02 12:51 ` Sergei Shtylyov
2016-04-03 8:25 ` Wolfram Sang
2016-04-03 13:35 ` Sergei Shtylyov
2016-04-03 13:47 ` Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 10/11] i2c: rcar: clean up after refactoring Wolfram Sang
2015-11-19 15:56 ` [PATCH v3 11/11] i2c: rcar: handle difference in setting up non-first message Wolfram Sang
2015-11-19 16:01 ` [PATCH v3 00/11] i2c: rcar: tackle race conditions in the driver Laurent Pinchart
2015-11-30 13:27 ` 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=56FD9080.4090203@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=geert@linux-m68k.org \
--cc=horms@verge.net.au \
--cc=kuninori.morimoto.gx@gmail.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=stable@vger.kernel.org \
--cc=wsa@the-dreams.de \
--cc=yoshihiro.shimoda.uh@renesas.com \
/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).