linux-toradex.git/drivers/gpu/drm/tests, branch v6.19

Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes

2025-12-15T11:53:27+00:00

Pull in rc1 to include all changes since the merge window closed,
and grab all fixes and changes from drm/drm-next.

Signed-off-by: Maarten Lankhorst

drm/tests: Handle EDEADLK in set_up_atomic_state()

2025-12-12T09:12:46+00:00

Fedora/CentOS/RHEL CI is reporting intermittent failures while running
the drm_validate_modeset test [1]:

    # drm_test_check_connector_changed_modeset: EXPECTATION FAILED at
    # drivers/gpu/drm/tests/drm_atomic_state_test.c:162
    Expected ret == 0, but
        ret == -35 (0xffffffffffffffdd)

Change the set_up_atomic_state() helper function to return on error and
restart the atomic sequence when the returned error is EDEADLK.

[1] https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/2106744096/test_x86_64/11762450343/artifacts/jobwatch/logs/recipes/19797909/tasks/204139142/results/945095586/logs/dmesg.log

Fixes: 73d934d7b6e3 ("drm/tests: Add test for drm_atomic_helper_commit_modeset_disables()")
Closes: https://datawarehouse.cki-project.org/issue/4004
Reviewed-by: Maxime Ripard 
Signed-off-by: José Expósito 
Link: https://patch.msgid.link/20251104102535.12212-2-jose.exposito89@gmail.com

drm/tests: Handle EDEADLK in drm_test_check_valid_clones()

2025-12-12T09:12:45+00:00

Fedora/CentOS/RHEL CI is reporting intermittent failures while running
the drm_test_check_valid_clones() KUnit test.

The error log can be either [1]:

    # drm_test_check_valid_clones: ASSERTION FAILED at
    # drivers/gpu/drm/tests/drm_atomic_state_test.c:295
    Expected ret == param->expected_result, but
        ret == -35 (0xffffffffffffffdd)
        param->expected_result == 0 (0x0)

Or [2] depending on the test case:

    # drm_test_check_valid_clones: ASSERTION FAILED at
    # drivers/gpu/drm/tests/drm_atomic_state_test.c:295
    Expected ret == param->expected_result, but
        ret == -35 (0xffffffffffffffdd)
        param->expected_result == -22 (0xffffffffffffffea)

Restart the atomic sequence when EDEADLK is returned.

[1] https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/2113057246/test_x86_64/11802139999/artifacts/jobwatch/logs/recipes/19824965/tasks/204347800/results/946112713/logs/dmesg.log
[2] https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/2106744297/test_aarch64/11762450907/artifacts/jobwatch/logs/recipes/19797942/tasks/204139727/results/945094561/logs/dmesg.log

Fixes: 88849f24e2ab ("drm/tests: Add test for drm_atomic_helper_check_modeset()")
Closes: https://datawarehouse.cki-project.org/issue/4004
Reviewed-by: Maxime Ripard 
Signed-off-by: José Expósito 
Link: https://patch.msgid.link/20251104102535.12212-1-jose.exposito89@gmail.com

drm/tests: hdmi: Handle drm_kunit_helper_enable_crtc_connector() returning EDEADLK

2025-12-12T09:07:43+00:00

Fedora/CentOS/RHEL CI is reporting intermittent failures while running
the KUnit tests present in drm_hdmi_state_helper_test.c [1].

While the specific test causing the failure change between runs, all of
them are caused by drm_kunit_helper_enable_crtc_connector() returning
-EDEADLK. The error trace always follow this structure:

    # : ASSERTION FAILED at
    # drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c:
    Expected ret == 0, but
        ret == -35 (0xffffffffffffffdd)

As documented, if the drm_kunit_helper_enable_crtc_connector() function
returns -EDEADLK (-35), the entire atomic sequence must be restarted.

Handle this error code for all function calls.

Closes: https://datawarehouse.cki-project.org/issue/4039  [1]
Fixes: 6a5c0ad7e08e ("drm/tests: hdmi_state_helpers: Switch to new helper")
Reviewed-by: Maxime Ripard 
Signed-off-by: José Expósito 
Link: https://patch.msgid.link/20251104102258.10026-1-jose.exposito89@gmail.com

drm/tests: Add a few tests around drm_fixed.h

2025-11-26T22:03:33+00:00

While working on the CTM implementation of VKMS I had to ascertain
myself of a few assumptions. One of those is whether drm_fixed.h
treats its numbers using signed-magnitude or twos-complement. It is
twos-complement.

In order to make someone else's day easier I am adding the
drm_test_int2fixp test that validates the above assumption.

I am also adding a test for the new sm2fixp function that converts
from a signed-magnitude fixed point to the twos-complement fixed
point.

Reviewed-by: Louis Chauvet 
Signed-off-by: Alex Hung 
Signed-off-by: Harry Wentland 
Reviewed-by: Daniel Stone 
Signed-off-by: Simon Ser 
Link: https://patch.msgid.link/20251115000237.3561250-22-alex.hung@amd.com

drm: include drm_print.h where needed

2025-10-31T08:34:52+00:00

There are a gazillion files that depend on drm_print.h being indirectly
included via drm_buddy.h, drm_mm.h, or ttm/ttm_resource.h. In
preparation for removing those includes, explicitly include drm_print.h
where needed.

Cc: Thomas Zimmermann 
Reviewed-by: Thomas Zimmermann 
Signed-off-by: Jani Nikula 
Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com

drm/buddy: Add KUnit tests for allocator performance under fragmentation

2025-10-07T13:49:15+00:00

Add KUnit test cases that create severe memory fragmentation and
measure allocation/free performance.

The tests simulate two scenarios -

1. Allocation under severe fragmentation
   - Allocate the entire 4 GiB space as 8 KiB blocks with 64 KiB alignment,
     split them into two groups and free with mixed flags to block coalescing.
   - Repeatedly allocate and free 64 KiB blocks while timing the loop.
   - Freelist runtime: 76475 ms(76.5 seconds), soft-lockup triggered.
     RB-tree runtime: 186 ms.

2. Reverse free order under fragmentation
   - Create a similarly fragmented space, free half the blocks, reverse
     the order of the remainder, and release them with the cleared flag.
   - Freelist runtime: 85620 ms(85.6 seconds).
     RB-tree runtime: 114 ms.

Signed-off-by: Arunpravin Paneer Selvam 
Reviewed-by: Matthew Auld 
Link: https://lore.kernel.org/r/20251006095124.1663-3-Arunpravin.PaneerSelvam@amd.com

drm/tests: make sure drm_client_modeset tests are enabled

2025-09-16T17:20:21+00:00

Default config for UML (x86_64) doesn't include any driver which
supports DRM_CLIENT_SELECTION, which makes drm_client_modeset disabled
(and correspondingly tests for that module are not executed too).

Enable DRM_VKMS and DRM_FBDEV_EMULATION in order to be able to run DRM
client modesetting tests.

Reviewed-by: Louis Chauvet 
Link: https://lore.kernel.org/r/20250821-drm-client-tests-v1-1-49e7212c744a@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov

Merge tag 'v6.17-rc6' into drm-next

2025-09-15T07:51:07+00:00

This is a backmerge of Linux 6.17-rc6, needed for msm,
also requested by misc.

Signed-off-by: Dave Airlie

drm/test: drm_exec: use kzalloc() to allocate GEM objects

2025-08-29T15:42:20+00:00

Since commit e7fa80e2932c ("drm_gem: add mutex to drm_gem_object.gpuva")
it is possible for test_prepare_array() to exceed a stack frame size of
2048 bytes depending on the exact configuration of the kernel.

  drivers/gpu/drm/tests/drm_exec_test.c: In function ‘test_prepare_array’:
  drivers/gpu/drm/tests/drm_exec_test.c:171:1: error: the frame size of 2128 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
    171 | }
        | ^
  cc1: all warnings being treated as errors
  make[6]: *** [scripts/Makefile.build:287: drivers/gpu/drm/tests/drm_exec_test.o] Error 1
  make[6]: *** Waiting for unfinished jobs....

In order to fix this, allocate the GEM objects in test_prepare_array()
with kzalloc(), rather than placing them on the stack.

Cc: Alice Ryhl 
Cc: Christian König 
Fixes: e7fa80e2932c ("drm_gem: add mutex to drm_gem_object.gpuva")
Reviewed-by: Christian König 
Reviewed-by: Alice Ryhl 
Reviewed-by: Nirmoy Das 
Link: https://lore.kernel.org/r/20250829075633.2306-1-dakr@kernel.org
[ Use kunit_kzalloc() instead of kzalloc(). - Danilo ]
Signed-off-by: Danilo Krummrich