[v2,20/31] drm/vc4: Introduce generation number enum
Marek Szyprowski
m.szyprowski at samsung.com
Mon Oct 7 11:59:35 UTC 2024
Hi Dave,
On 21.06.2024 17:20, Dave Stevenson wrote:
> From: Maxime Ripard <mripard at kernel.org>
>
> With the introduction of the BCM2712 support, we will get yet another
> generation of display engine to support.
>
> The binary check of whether it's VC5 or not thus doesn't work anymore,
> especially since some parts of the driver will have changed with BCM2711,
> and some others with BCM2712.
>
> Let's introduce an enum to store the generation the driver is running
> on, which should provide more flexibility.
>
> Signed-off-by: Maxime Ripard <mripard at kernel.org>
> Signed-off-by: Dave Stevenson <dave.stevenson at raspberrypi.com>
This patch landed recently in linux-next as commit 24c5ed3ddf27
("drm/vc4: Introduce generation number enum"). In my tests I found that
it introduces the following warning on Raspberry Pi3B+ board:
================================================
WARNING: lock held when returning to user space!
6.11.0-rc5+ #15405 Tainted: G C
------------------------------------------------
(udev-worker)/161 is leaving the kernel with locks still held!
1 lock held by (udev-worker)/161:
#0: ffff80008338bff8 (drm_unplug_srcu){.?.?}-{0:0}, at:
drm_dev_enter+0x0/0xdc
I suspect that the error path is somewhere broken and the conversion
triggered that path.
A wild guess (noticed by grepping for 'drm_dev_enter') is that the
following chunk is broken:
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 933177cb8d66..7380a02a69a2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -224,7 +224,7 @@ static void vc4_hvs_lut_load(struct vc4_hvs *hvs,
> if (!drm_dev_enter(drm, &idx))
> return;
>
> - if (hvs->vc4->is_vc5)
> + if (hvs->vc4->gen == VC4_GEN_4)
> return;
>
> /* The LUT memory is laid out with each HVS channel in order,
as changing the above check to 'if (hvs->vc4->gen > VC4_GEN_4)' fixes this issue (tested also on top of linux-next). I think that one has to review the checks again as well as the error paths in the driver.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
More information about the dri-devel
mailing list