From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Arnd Bergmann <arnd@kernel.org>,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
Philipp Zabel <p.zabel@pengutronix.de>,
Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
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 10:41:19 -0400 [thread overview]
Message-ID: <e264ac3a15e0f115aa7e941a77eb312429b8f65e.camel@collabora.com> (raw)
In-Reply-To: <20230616144854.3818934-2-arnd@kernel.org>
Hi Arnd,
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 ?
regards,
Nicolas
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> I did not look whether there is an actual bug here, just noticed this
> when I debugged the excessive stack usage.
> ---
> drivers/media/platform/verisilicon/hantro.h | 6 +++---
> drivers/media/platform/verisilicon/hantro_postproc.c | 12 ++++++------
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/verisilicon/hantro.h b/drivers/media/platform/verisilicon/hantro.h
> index 6c5e56ce5b351..a481d957fef93 100644
> --- a/drivers/media/platform/verisilicon/hantro.h
> +++ b/drivers/media/platform/verisilicon/hantro.h
> @@ -441,14 +441,14 @@ static __always_inline void hantro_reg_write(struct hantro_dev *vpu,
> const struct hantro_reg *reg,
> u32 val)
> {
> - vdpu_write_relaxed(vpu, vdpu_read_mask(vpu, reg, val), reg->base);
> + vdpu_write(vpu, vdpu_read_mask(vpu, reg, val), reg->base);
> }
>
> -static __always_inline void hantro_reg_write_s(struct hantro_dev *vpu,
> +static __always_inline void hantro_reg_write_relaxed(struct hantro_dev *vpu,
> const struct hantro_reg *reg,
> u32 val)
> {
> - vdpu_write(vpu, vdpu_read_mask(vpu, reg, val), reg->base);
> + vdpu_write_relaxed(vpu, vdpu_read_mask(vpu, reg, val), reg->base);
> }
>
> void *hantro_get_ctrl(struct hantro_ctx *ctx, u32 id);
> diff --git a/drivers/media/platform/verisilicon/hantro_postproc.c b/drivers/media/platform/verisilicon/hantro_postproc.c
> index c977d64105b18..0224ff68ab3fc 100644
> --- a/drivers/media/platform/verisilicon/hantro_postproc.c
> +++ b/drivers/media/platform/verisilicon/hantro_postproc.c
> @@ -21,11 +21,11 @@
> val); \
> }
>
> -#define HANTRO_PP_REG_WRITE_S(vpu, reg_name, val) \
> +#define HANTRO_PP_REG_WRITE_RELAXED(vpu, reg_name, val) \
> { \
> - hantro_reg_write_s(vpu, \
> - &hantro_g1_postproc_regs.reg_name, \
> - val); \
> + hantro_reg_write_relaxed(vpu, \
> + &hantro_g1_postproc_regs.reg_name, \
> + val); \
> }
>
> #define VPU_PP_IN_YUYV 0x0
> @@ -72,7 +72,7 @@ static void hantro_postproc_g1_enable(struct hantro_ctx *ctx)
> dma_addr_t dst_dma;
>
> /* Turn on pipeline mode. Must be done first. */
> - HANTRO_PP_REG_WRITE_S(vpu, pipeline_en, 0x1);
> + HANTRO_PP_REG_WRITE(vpu, pipeline_en, 0x1);
>
> src_pp_fmt = VPU_PP_IN_NV12;
>
> @@ -242,7 +242,7 @@ static void hantro_postproc_g1_disable(struct hantro_ctx *ctx)
> {
> struct hantro_dev *vpu = ctx->dev;
>
> - HANTRO_PP_REG_WRITE_S(vpu, pipeline_en, 0x0);
> + HANTRO_PP_REG_WRITE(vpu, pipeline_en, 0x0);
> }
>
> static void hantro_postproc_g2_disable(struct hantro_ctx *ctx)
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2023-06-19 14:41 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 [this message]
2023-06-19 14:49 ` Arnd Bergmann
2023-06-19 18:29 ` Nicolas Dufresne
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=e264ac3a15e0f115aa7e941a77eb312429b8f65e.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