mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Arnd Bergmann <arnd@arndb.de>, Arnd Bergmann <arnd@kernel.org>,
	Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] media: verisilicon: change confusingly named relaxed register access
Date: Mon, 19 Jun 2023 14:29:38 -0400	[thread overview]
Message-ID: <d9f088d1d548c8735b393a15d5a16dbd914ddeca.camel@collabora.com> (raw)
In-Reply-To: <063a8886-fd31-425f-901c-fc830512eca3@app.fastmail.com>

Le lundi 19 juin 2023 à 16:49 +0200, Arnd Bergmann a écrit :
> On Mon, Jun 19, 2023, at 16:41, Nicolas Dufresne wrote:
> > Le vendredi 16 juin 2023 à 16:48 +0200, Arnd Bergmann a écrit :
> > > From: Arnd Bergmann <arnd@arndb.de>
> > > 
> > > The register abstraction has wrappers around both the normal writel()
> > > and its writel_relaxed() counterpart, but this has led to a lot of users
> > > ending up with the relaxed version.
> > > 
> > > There is sometimes a need to intentionally pick the relaxed accessor for
> > > performance critical functions, but I noticed that each hantro_reg_write()
> > > call also contains a non-relaxed readl(), which is typically much more
> > > expensive than a writel, so there is little benefit here but an added
> > > risk of missing a serialization against DMA.
> > > 
> > > To make this behave like other interfaces, use the normal accessor by
> > > default and only provide the relaxed version as an alternative for
> > > performance critical code. hantro_postproc.c is the only place that
> > > used both the relaxed and normal writel, but this does not seem
> > > cricital either, so change it all to the normal ones.
> > 
> > In this text you spoke about potential performance side effects of existing code
> > and your changes, but its left all very vague and theoretical. Have you done any
> > measurement ? Do you need help with the manner ?
> 
> I don't have this hardware and have not done any measurements.
> Obviously the only point of using relaxed accessors is to
> improve performance in critical code paths, but from the way they
> are used here it seems that this was instead just an accident
> and nobody else did any comparisons either.
> 
> My guess would be that if one wanted to speed up the register
> access, a better way would be to use a regmap cache to avoid
> reading registers when the contents are already known.

All I know is that for the majority of registers when programming stateless
codecs, each 32bit word of registers are fully written too, the read value is
not always meaningful (its a value from last time the HW has been triggered) and
should be ignored, so better to not do that. As for regmap, there is folks that
have reported regmap to be completely overkill for this type of hardware.

That discussion highlight my concern, which is that this specific patch should
require a Tested-by before being merged. A clearer note to say that this patch
is not tested could have helped.

regards,
Nicolas

> 
>      Arnd


  reply	other threads:[~2023-06-19 18:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-16 14:48 [PATCH 1/2] media: verisilicon: fix excessive stack usage Arnd Bergmann
2023-06-16 14:48 ` [PATCH 2/2] media: verisilicon: change confusingly named relaxed register access Arnd Bergmann
2023-06-19 14:41   ` Nicolas Dufresne
2023-06-19 14:49     ` Arnd Bergmann
2023-06-19 18:29       ` Nicolas Dufresne [this message]
2023-06-19 19:26         ` Arnd Bergmann
2023-06-20  8:00           ` Benjamin Gaignard
2023-06-21 14:44 ` [PATCH 1/2] media: verisilicon: fix excessive stack usage Nicolas Dufresne
2023-06-28 18:26 ` Nathan Chancellor
2023-06-29  7:03   ` Hans Verkuil

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=d9f088d1d548c8735b393a15d5a16dbd914ddeca.camel@collabora.com \
    --to=nicolas.dufresne@collabora.com \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=benjamin.gaignard@collabora.com \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mchehab@kernel.org \
    --cc=p.zabel@pengutronix.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

all inboxes | Powered by JetHome®