kernel/linux.git/drivers/gpu/drm/vc4/tests, branch v6.19.11

drm/vc4: tests: Retry pv-muxing tests when EDEADLK

2025-04-07T08:29:45+00:00

Some functions used by the HVS->PV muxing tests can return with EDEADLK, meaning the entire sequence should be restarted. It's not a fatal error and we should treat it as a recoverable error, and recover, instead of failing the test like we currently do. Fixes: 76ec18dc5afa ("drm/vc4: tests: Add unit test suite for the PV muxing") Reviewed-by: Maíra Canal Link: https://lore.kernel.org/r/20250403-drm-vc4-kunit-failures-v2-4-e09195cc8840@kernel.org Signed-off-by: Maxime Ripard

drm/vc4: tests: Stop allocating the state in test init

2025-04-07T08:29:44+00:00

The vc4-pv-muxing-combinations and vc5-pv-muxing-combinations test suites use a common test init function which, in part, allocates the drm atomic state the test will use. That allocation relies on drm_kunit_helper_atomic_state_alloc(), and thus requires a struct drm_modeset_acquire_ctx. This context will then be stored in the allocated state->acquire_ctx field. However, the context is local to the test init function, and is cleared as soon as drm_kunit_helper_atomic_state_alloc() is done. We thus end up with an dangling pointer to a cleared context in state->acquire_ctx for our test to consumes. We should really allocate the context and the state in the test functions, so we can also control when we're done with it. Fixes: 30188df0c387 ("drm/tests: Drop drm_kunit_helper_acquire_ctx_alloc()") Reviewed-by: Maíra Canal Link: https://lore.kernel.org/r/20250403-drm-vc4-kunit-failures-v2-3-e09195cc8840@kernel.org Signed-off-by: Maxime Ripard

drm/vc4: tests: Document output handling functions

2025-04-07T08:29:44+00:00

vc4_mock_atomic_add_output() and vc4_mock_atomic_del_output() are public but aren't documented. Let's provide the documentation. In particular, special care should be taken to deal with EDEADLK. Reviewed-by: Maíra Canal Link: https://lore.kernel.org/r/20250403-drm-vc4-kunit-failures-v2-2-e09195cc8840@kernel.org Signed-off-by: Maxime Ripard

drm/vc4: tests: Use return instead of assert

2025-04-07T08:29:43+00:00

The vc4_mock_atomic_add_output() and vc4_mock_atomic_del_output() assert that the functions they are calling didn't fail. Since some of them can return EDEADLK, we can't properly deal with it. Since both functions are expected to return an int, and all caller check the return value, let's just properly propagate the errors when they occur. Fixes: f759f5b53f1c ("drm/vc4: tests: Introduce a mocking infrastructure") Fixes: 76ec18dc5afa ("drm/vc4: tests: Add unit test suite for the PV muxing") Reviewed-by: Maíra Canal Link: https://lore.kernel.org/r/20250403-drm-vc4-kunit-failures-v2-1-e09195cc8840@kernel.org Signed-off-by: Maxime Ripard

drm/tests: Drop drm_kunit_helper_acquire_ctx_alloc()

2025-03-03T13:21:58+00:00

lockdep complains when a lock is released in a separate thread the lock is taken in, and it turns out that kunit does run its actions in a separate thread than the test ran in. This means that drm_kunit_helper_acquire_ctx_alloc() just cannot work as it's supposed to, so let's just get rid of it. Suggested-by: Simona Vetter Reviewed-by: Dmitry Baryshkov Link: https://patchwork.freedesktop.org/patch/msgid/20250220132537.2834168-1-mripard@kernel.org Signed-off-by: Maxime Ripard

drm/vc4: txp: Add a new TXP encoder type

2024-11-27T14:37:20+00:00

Starting with BCM2712, we'll have a two TXP. Let's follow the HDMI example and add two encoder types for TXP: TXP0 and TXP1. Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-19-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson

drm/vc4: txp: Rename TXP data structure

2024-11-27T14:37:20+00:00

The TXP data structure has a name too generic for the multiple variants we'll have to support. Let's rename it to mention the SoC it applies to. Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-14-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson

drm/vc4: txp: Introduce structure to deal with revision differences

2024-11-27T14:37:20+00:00

The BCM2712 will have several TXP with small differences. Let's add a structure tied to the compatible to deal with those differences. Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-13-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson

drm/vc4: hvs: Change prototype of __vc4_hvs_alloc to pass registers

2024-09-09T12:02:54+00:00

The BCM2712 HVS has registers to report the size of the various SRAM the driver uses, and their size actually differ depending on the stepping. The initialisation of the memory pools happen in the __vc4_hvs_alloc() function that also allocates the main HVS structure, that will then hold the pointer to the memory mapping of the registers. This creates some kind of circular dependency that we can break by passing the mapping pointer as an argument for __vc4_hvs_alloc() to use to query to get the SRAM sizes and initialise the memory pools accordingly. Signed-off-by: Maxime Ripard Reviewed-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-29-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson

drm/vc4: Introduce generation number enum

2024-09-09T12:02:53+00:00

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 Reviewed-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-21-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson