linux-sh.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: linux-i2c@vger.kernel.org, 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: Fri, 01 Apr 2016 19:55:49 +0000	[thread overview]
Message-ID: <56FED245.4010503@cogentembedded.com> (raw)
In-Reply-To: <20160331224838.GA7381@katana>

Hello.

On 04/01/2016 01:48 AM, 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...

> Really only this patch?

    Well, my "reverse" bisection pointed at it. :-)

> IIRC my tests showed that if you don't remove
> the spinlocks (patch 4), the interrupt latency will already be too high
> again.

    Thank you for the valuable info!

> In any case, you'd need to do some careful backporting to rip
> this out of the whole refactoring series.

    Yes, I've already figured that.

> But maybe you did that already
> and have good experiences?

    Not yet, I will report back after more backporting/testing.

MBR, Sergei


  reply	other threads:[~2016-04-01 19:55 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
2016-03-31 22:48     ` Wolfram Sang
2016-04-01 19:55       ` Sergei Shtylyov [this message]
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=56FED245.4010503@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).