Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-496-g8c46984af0-fm-20230615.001-g8c46984a
Mime-Version: 1.0
Message-Id: <300ecb3e-8747-4399-8452-77724f85330b@app.fastmail.com>
In-Reply-To: <d9f088d1d548c8735b393a15d5a16dbd914ddeca.camel@collabora.com>
References: <20230616144854.3818934-1-arnd@kernel.org>
 <20230616144854.3818934-2-arnd@kernel.org>
 <e264ac3a15e0f115aa7e941a77eb312429b8f65e.camel@collabora.com>
 <063a8886-fd31-425f-901c-fc830512eca3@app.fastmail.com>
 <d9f088d1d548c8735b393a15d5a16dbd914ddeca.camel@collabora.com>
Date:   Mon, 19 Jun 2023 21:26:34 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Nicolas Dufresne" <nicolas.dufresne@collabora.com>,
        "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
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Jun 19, 2023, at 20:29, Nicolas Dufresne wrote:
> Le lundi 19 juin 2023 =C3=A0 16:49 +0200, Arnd Bergmann a =C3=A9crit=C2=
=A0:
>> >=20
>> > 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 ?
>>=20
>> 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.
>>=20
>> 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 stat=
eless
> codecs, each 32bit word of registers are fully written too, the read v=
alue is
> not always meaningful (its a value from last time the HW has been trig=
gered) and
> should be ignored, so better to not do that. As for regmap, there is f=
olks that
> have reported regmap to be completely overkill for this type of hardwa=
re.

Right, most likely neither the cache nor avoiding the readl() is necessa=
ry,
and that was exactly my point to start with: don't add potentially dange=
rous
microoptimizations like relaxed accessors unless the obvious optimizatio=
ns
are also needed and used.

Obviously, testing my patch would still be a good idea before applying i=
t.

       Arnd