From: sashiko-bot@kernel.org
To: "Naman Arora" <namanarora029@gmail.com>
Cc: neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org
Subject: Re: [PATCH 6/6] drm/meson: Open-code drm_simple_encoder_init() in encoder_dsi
Date: Sun, 31 May 2026 08:25:46 +0000 [thread overview]
Message-ID: <20260531082546.D98F81F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260531074627.8936-3-namanarora029@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The encoder atomic enable callback uses a sleeping polling function, which violates DRM atomic context rules.
--
commit 7905b259e0fff97b6803c2360bf97ff0dc74dae2
Author: Naman Arora <namanarora029@gmail.com>
drm/meson: Open-code drm_simple_encoder_init() in encoder_dsi
The helper drm_simple_encoder_init() is a thin wrapper around
drm_encoder_init() with a simple destroy-only encoder funcs struct.
Remove the dependency on drm_simple_kms_helper by open-coding the
encoder initialization directly in the driver.
> diff --git a/drivers/gpu/drm/meson/meson_encoder_dsi.c b/drivers/gpu/drm/meson/meson_encoder_dsi.c
> index c1f4685073bbc..bbb5b65cb0d94 100644
> --- a/drivers/gpu/drm/meson/meson_encoder_dsi.c
> +++ b/drivers/gpu/drm/meson/meson_encoder_dsi.c
[ ... ]
> @@ -99,6 +98,10 @@ static const struct drm_bridge_funcs meson_encoder_dsi_bridge_funcs = {
> .atomic_reset = drm_atomic_helper_bridge_reset,
> };
[Severity: High]
This is a pre-existing issue, but does this bridge configuration cause a
sleep in atomic context?
Looking at the atomic_enable path for this bridge in
drivers/gpu/drm/meson/meson_encoder_dsi.c:
meson_encoder_dsi_atomic_enable()
meson_encl_load_gamma()
meson_encl_set_gamma_table()
In drivers/gpu/drm/meson/meson_venc.c, meson_encl_set_gamma_table() calls:
readl_relaxed_poll_timeout(..., 10, 10000)
The readl_relaxed_poll_timeout macro expands to usleep_range when a non-zero
delay is provided (like 10 here), which will cause the thread to sleep.
Since bridge atomic_enable callbacks execute in an atomic context where
sleeping is strictly forbidden, could this cause kernel warnings (might_sleep)
or potential deadlocks if locks are held?
Should this code path use a non-sleeping polling mechanism such as
readl_relaxed_poll_timeout_atomic instead?
> +static const struct drm_encoder_funcs meson_encoder_dsi_drm_encoder_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
> int meson_encoder_dsi_probe(struct meson_drm *priv)
> {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260531074627.8936-1-namanarora029@gmail.com?part=6
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2026-05-31 8:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-31 7:35 [PATCH 0/6] drm: Open-code drm_simple_encoder_init() in several drivers Naman Arora
2026-05-31 7:35 ` Naman Arora
2026-05-31 7:35 ` [PATCH 1/6] drm/fsl-dcu: Open-code drm_simple_encoder_init() Naman Arora
2026-05-31 7:35 ` Naman Arora
2026-05-31 7:35 ` [PATCH 2/6] drm/tidss: " Naman Arora
2026-05-31 7:35 ` Naman Arora
2026-05-31 7:57 ` sashiko-bot
2026-05-31 7:35 ` [PATCH 3/6] drm/virtio: " Naman Arora
2026-05-31 7:35 ` Naman Arora
2026-05-31 8:00 ` sashiko-bot
2026-05-31 7:46 ` [PATCH 4/6] drm/meson: Open-code drm_simple_encoder_init() in encoder_cvbs Naman Arora
2026-05-31 7:46 ` Naman Arora
2026-05-31 7:46 ` [PATCH 5/6] drm/meson: Open-code drm_simple_encoder_init() in encoder_hdmi Naman Arora
2026-05-31 7:46 ` Naman Arora
2026-05-31 8:17 ` sashiko-bot
2026-05-31 7:46 ` [PATCH 6/6] drm/meson: Open-code drm_simple_encoder_init() in encoder_dsi Naman Arora
2026-05-31 7:46 ` Naman Arora
2026-05-31 8:25 ` sashiko-bot [this message]
2026-05-31 8:08 ` [PATCH 4/6] drm/meson: Open-code drm_simple_encoder_init() in encoder_cvbs sashiko-bot
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=20260531082546.D98F81F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=namanarora029@gmail.com \
--cc=neil.armstrong@linaro.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.