linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Eichenberger <eichest@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: o.rempel@pengutronix.de,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Andi Shyti <andi.shyti@kernel.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>, Frank Li <Frank.Li@nxp.com>,
	linux-i2c@vger.kernel.org, imx@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Francesco Dolcini <francesco.dolcini@toradex.com>,
	Stefan Eichenberger <stefan.eichenberger@toradex.com>
Subject: Re: [PATCH v4 3/4] i2c: imx: use readb_relaxed and writeb_relaxed
Date: Wed, 2 Oct 2024 16:36:05 +0200	[thread overview]
Message-ID: <Zv1aVatIlToneign@eichest-laptop> (raw)
In-Reply-To: <a65ddcab-4ba9-4dfe-93ec-352b31845eb4@app.fastmail.com>

On Wed, Oct 02, 2024 at 01:36:04PM +0000, Arnd Bergmann wrote:
> On Wed, Oct 2, 2024, at 13:08, Stefan Eichenberger wrote:
> > On Wed, Oct 02, 2024 at 11:51:22AM +0000, Arnd Bergmann wrote:
> >> On Wed, Oct 2, 2024, at 11:19, Stefan Eichenberger wrote:
> >> > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> >> >
> >> > Use the relaxed version of readb and writeb to reduce overhead. It is
> >> > safe to use the relaxed version because we either do not rely on dma
> >> > completion, or we use a dma callback to ensure that the dma transfer is
> >> > complete before we continue.
> >> 
> >> I would still consider this a bug in general, you should
> >> never default to the unsafe variants.
> >> 
> >> If there is a codepath that needs the barrierless version,
> >> please add imx_i2c_write_reg_relaxed()/imx_i2c_read_reg_relaxed()
> >> helpers that use those only in the places where it makes
> >> a measurable difference, with a comment that explains
> >> the usage.
> >
> > I added the patch because of the following dicussion:
> > https://lore.kernel.org/linux-i2c/ZpVWXlR6j2i0ZtVQ@lizhi-Precision-Tower-5810/
> >
> > I can't determine if the relaxed version improves performance. The
> > 'normal' version worked well for our use case too. Therefore, dropping
> > the change would be acceptable for us. Another potential solution could
> > be to use the relaxed version only inside the ISR. Would that be an
> > acceptable solution? What is your impression, Frank Li
> > <Frank.Li@nxp.com>?
> 
> I'm pretty sure that Frank meant to use readb_relaxed()/writeb_relaxed()
> inside of the FIFO access loop, not for everything else. This
> makes a lot of sense, since the FIFO read in particular is
> clearly performance sensitive and already serialized by the
> implied control dependency.
> 
> If you can read multiple bytes, the best interface to use
> would in fact be readsb() or possibly readsl() to read
> four bytes with each access.
> 
> It appears that you did not implement the suggestion to
> read the entire FIFO though, so you can probably just skip
> the _relaxed() change entirely.

This makes sense, it appears this was a misunderstanding. If no one
objects, I will drop the patch in the next version. Thank you for the
clarification.

Regards,
Stefan


  reply	other threads:[~2024-10-02 14:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-02 11:19 [PATCH v4 0/4] i2c: imx: prevent rescheduling in non-dma mode Stefan Eichenberger
2024-10-02 11:19 ` [PATCH v4 1/4] i2c: imx: only poll for bus busy in multi master mode Stefan Eichenberger
2024-10-02 14:40   ` Lucas Stach
2024-10-02 14:56     ` Stefan Eichenberger
2024-10-02 15:16       ` Lucas Stach
2024-10-02 11:19 ` [PATCH v4 2/4] i2c: imx: separate atomic, dma and non-dma use case Stefan Eichenberger
2024-10-02 11:19 ` [PATCH v4 3/4] i2c: imx: use readb_relaxed and writeb_relaxed Stefan Eichenberger
2024-10-02 11:51   ` Arnd Bergmann
2024-10-02 13:08     ` Stefan Eichenberger
2024-10-02 13:36       ` Arnd Bergmann
2024-10-02 14:36         ` Stefan Eichenberger [this message]
2024-10-02 11:19 ` [PATCH v4 4/4] i2c: imx: prevent rescheduling in non dma mode Stefan Eichenberger

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=Zv1aVatIlToneign@eichest-laptop \
    --to=eichest@gmail.com \
    --cc=Frank.Li@nxp.com \
    --cc=andi.shyti@kernel.org \
    --cc=arnd@arndb.de \
    --cc=festevam@gmail.com \
    --cc=francesco.dolcini@toradex.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=stefan.eichenberger@toradex.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).