summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/tests
AgeCommit message (Collapse)AuthorLines
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds-3/+3
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook-3/+3
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-23Merge tag 'drm-misc-next-2026-01-22' of ↵Dave Airlie-0/+843
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.20: Core Changes: - buddy: Fix free_trees memory leak, prevent a BUG_ON - dma-buf: Start to introduce cgroup memory accounting in heaps, Remove sysfs stats, add new tracepoints - hdmi: Limit infoframes exposure to userspace based on driver capabilities - property: Account for property blobs in memcg Driver Changes: - atmel-hlcdc: Switch to drmm resources, Support nomodeset parameter, various patches to use newish helpers and fix memory safety bugs - hisilicon: Fix various DisplayPort related bugs - imagination: Introduce hardware version checks - renesas: Fix kernel panic on reboot - rockchip: Fix RK3576 HPD interrupt handling, Improve RK3588 HPD interrupt handling - v3d: Convert to drm logging helpers - bridge: - Continuation of the refcounting effort - new bridge: Algoltek AG6311 - panel: - new panel: Anbernic RG-DS Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260122-antique-sexy-junglefowl-1bc5a8@houat
2026-01-21drm/tests/drm_buddy: Add tests for allocations exceeding max_orderSanjay Yadav-0/+35
Add kunit tests that exercise edge cases where allocation requests exceed mm->max_order after rounding. This can happen with non-power-of-two VRAM sizes when the allocator rounds up requests. For example, with 10G VRAM (8G + 2G roots), mm->max_order represents the 8G block. A 9G allocation can round up to 16G in multiple ways: CONTIGUOUS allocation rounds to next power-of-two, or non-CONTIGUOUS with 8G min_block_size rounds to next alignment boundary. The test validates CONTIGUOUS and RANGE flag combinations, ensuring that only CONTIGUOUS-alone allocations use try_harder fallback, while other combinations return -EINVAL when rounded size exceeds memory, preventing BUG_ON assertions. Cc: Christian König <christian.koenig@amd.com> Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Suggested-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patch.msgid.link/20260108113227.2101872-6-sanjay.kumar.yadav@intel.com
2026-01-20drm/tests: hdmi: fix build failureDmitry Baryshkov-1/+1
The commit ca59e33f5a1f ("drm/atomic: add max_size check to drm_property_replace_blob_from_id()") added a new parameter to drm_property_replace_blob_from_id(), however commit 7436a87db99d ("drm/tests: hdmi: check the infoframes behaviour") was based on the older tree and used the old number of params (with me failing to run kunit tests when applying). Fix the build error by specifying -1 as the max_size (as expected). Fixes: 7436a87db99d ("drm/tests: hdmi: check the infoframes behaviour") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601200306.dgF5deFm-lkp@intel.com/ Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20260119-fix-kunit-infoframe-v1-1-5f2f9b066594@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/display: hdmi_state_helper: split InfoFrame functions per typeDmitry Baryshkov-47/+69
Havign a single set of InfoFrame callbacks doesn't provide enough information to the DRM framework about the InfoFrame types that are actually supported. Also it's not really future-proof: it provides a way to program only a single Vendor-Specific frame, however we might need to support multiple VSIs at the same time (e.g. HDMI vs HDMI Forum VSIs). Provide separate sets of callbacks, one per the InfoFrame type. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-6-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/connector: make clear_infoframe callback mandatory for HDMI connectorsDmitry Baryshkov-0/+37
We already require both hdmi_write_infoframe and hdmi_clear_infoframe for bridges implementing DRM_BRIDGE_OP_HDMI. It makes sense to require the clear_infoframes callback for HDMI connectors utilizing drmm_connector_hdmi_init(). Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-4-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-19drm/tests: hdmi: check the infoframes behaviourDmitry Baryshkov-0/+749
Verify the InfoFrames behaviour. Check that reporting InfoFrame as unsupported doesn't result in a commit error. Also check that HDR and Audio InfoFrames are not triggered if corresponding features are not enabled. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-1-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-01-09Merge tag 'drm-misc-next-2026-01-08' of ↵Dave Airlie-10/+241
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.20: UAPI Changes: Cross-subsystem Changes: Core Changes: - draw: Add API to check if a format conversion can be done - panic: Rename draw_panic_static_* to draw_panic_screen_*, Add kunit tests - shmem: Improve tests Driver Changes: - ast: Big endian fixes - etnaviv: Add PPU flop reset support - panfrost: Add GPU_PM_RT support for RZ/G3E SoC - panthor: multiple fixes around VM termination, huge page support - pl111: Fix build regression - v3d: Fix DMA segment size - bridge: - Add connector argument to .hpd_notify - Plenty of patches to convert existing drivers to refcounting - Convert Rockchip's inno hdmi support to a proper bridge - lontium-lt9611uxc: Switch to HDMI audio helpers - panel: - New panel: BOE NV140WUM-T08 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260108-literate-nyala-of-courtesy-de501a@houat
2026-01-05drm/panic: Add kunit tests for drm_panicJocelyn Falempe-0/+221
Add kunit tests for drm_panic. They check that drawing the panic screen doesn't crash, but they don't check the correctness of the resulting image. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20251216082524.115980-3-jfalempe@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-12-21drm/tests: shmem: Hold reservation lock around purgeThomas Zimmermann-1/+3
Acquire and release the GEM object's reservation lock around calls to the object's purge operation. The tests use drm_gem_shmem_purge_locked(), which led to errors such as show below. [ 58.709128] WARNING: CPU: 1 PID: 1354 at drivers/gpu/drm/drm_gem_shmem_helper.c:515 drm_gem_shmem_purge_locked+0x51c/0x740 Only export the new helper drm_gem_shmem_purge() for Kunit tests. This is not an interface for regular drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.16+ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251212160317.287409-6-tzimmermann@suse.de
2025-12-21drm/tests: shmem: Hold reservation lock around madviseThomas Zimmermann-4/+4
Acquire and release the GEM object's reservation lock around calls to the object's madvide operation. The tests use drm_gem_shmem_madvise_locked(), which led to errors such as show below. [ 58.339389] WARNING: CPU: 1 PID: 1352 at drivers/gpu/drm/drm_gem_shmem_helper.c:499 drm_gem_shmem_madvise_locked+0xde/0x140 Only export the new helper drm_gem_shmem_madvise() for Kunit tests. This is not an interface for regular drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.16+ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251212160317.287409-5-tzimmermann@suse.de
2025-12-21drm/tests: shmem: Hold reservation lock around vmap/vunmapThomas Zimmermann-2/+4
Acquire and release the GEM object's reservation lock around vmap and vunmap operations. The tests use vmap_locked, which led to errors such as show below. [ 122.292030] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:390 drm_gem_shmem_vmap_locked+0x3a3/0x6f0 [ 122.468066] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:293 drm_gem_shmem_pin_locked+0x1fe/0x350 [ 122.563504] WARNING: CPU: 3 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:234 drm_gem_shmem_get_pages_locked+0x23c/0x370 [ 122.662248] WARNING: CPU: 2 PID: 1413 at drivers/gpu/drm/drm_gem_shmem_helper.c:452 drm_gem_shmem_vunmap_locked+0x101/0x330 Only export the new vmap/vunmap helpers for Kunit tests. These are not interfaces for regular drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 954907f7147d ("drm/shmem-helper: Refactor locked/unlocked functions") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.16+ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251212160317.287409-4-tzimmermann@suse.de
2025-12-21drm/tests: shmem: Add clean-up action to unpin pagesThomas Zimmermann-0/+6
Automatically unpin pages on cleanup. The test currently fails with the error [ 58.246263] drm-kunit-mock-device drm_gem_shmem_test_get_sg_table.drm-kunit-mock-device: [drm] drm_WARN_ON(refcount_read(&shmem->pages_pin_count)) while cleaning up the GEM object. The pin count has to be zero at this point. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: d586b535f144 ("drm/shmem-helper: Add and use pages_pin_count") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.16+ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251212160317.287409-3-tzimmermann@suse.de
2025-12-21drm/tests: shmem: Swap names of export testsThomas Zimmermann-3/+3
GEM SHMEM has 2 helpers for exporting S/G tables. Swap the names of the rsp. tests, so that each matches the helper it tests. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 93032ae634d4 ("drm/test: add a test suite for GEM objects backed by shmem") Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patch.msgid.link/20251212160317.287409-2-tzimmermann@suse.de
2025-12-15Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixesMaarten Lankhorst-1/+181
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 <dev@lankhorst.se>
2025-12-12drm/tests: Handle EDEADLK in set_up_atomic_state()José Expósito-5/+22
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 <mripard@kernel.org> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://patch.msgid.link/20251104102535.12212-2-jose.exposito89@gmail.com
2025-12-12drm/tests: Handle EDEADLK in drm_test_check_valid_clones()José Expósito-0/+13
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 <mripard@kernel.org> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://patch.msgid.link/20251104102535.12212-1-jose.exposito89@gmail.com
2025-12-12drm/tests: hdmi: Handle drm_kunit_helper_enable_crtc_connector() returning ↵José Expósito-0/+143
EDEADLK 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: # <test name>: ASSERTION FAILED at # drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c:<line> 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 <mripard@kernel.org> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://patch.msgid.link/20251104102258.10026-1-jose.exposito89@gmail.com
2025-11-26drm/tests: Add a few tests around drm_fixed.hHarry Wentland-1/+73
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 <louis.chauvet@bootlin.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20251115000237.3561250-22-alex.hung@amd.com
2025-10-31drm: include drm_print.h where neededJani Nikula-0/+1
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 <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/5fe67395907be33eb5199ea6d540e29fddee71c8.1761734313.git.jani.nikula@intel.com
2025-10-07drm/buddy: Add KUnit tests for allocator performance under fragmentationArunpravin Paneer Selvam-0/+105
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 <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20251006095124.1663-3-Arunpravin.PaneerSelvam@amd.com
2025-09-16drm/tests: make sure drm_client_modeset tests are enabledDmitry Baryshkov-0/+2
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 <louis.chauvet@bootlin.com> Link: https://lore.kernel.org/r/20250821-drm-client-tests-v1-1-49e7212c744a@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2025-09-15Merge tag 'v6.17-rc6' into drm-nextDave Airlie-1/+2
This is a backmerge of Linux 6.17-rc6, needed for msm, also requested by misc. Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-08-29drm/test: drm_exec: use kzalloc() to allocate GEM objectsDanilo Krummrich-7/+15
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 <aliceryhl@google.com> Cc: Christian König <christian.koenig@amd.com> Fixes: e7fa80e2932c ("drm_gem: add mutex to drm_gem_object.gpuva") Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Nirmoy Das <nirmoyd@nvidia.com> Link: https://lore.kernel.org/r/20250829075633.2306-1-dakr@kernel.org [ Use kunit_kzalloc() instead of kzalloc(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-08-11drm/tests: Fix drm_test_fb_xrgb8888_to_xrgb2101010() on big-endianJosé Expósito-0/+1
Fix failures on big-endian architectures on tests cases single_pixel_source_buffer, single_pixel_clip_rectangle, well_known_colors and destination_pitch. Fixes: 15bda1f8de5d ("drm/tests: Add calls to drm_fb_blit() on supported format conversion tests") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250630090054.353246-2-jose.exposito89@gmail.com
2025-08-11drm/tests: Fix endian warningJosé Expósito-1/+1
When compiling with sparse enabled, this warning is thrown: warning: incorrect type in argument 2 (different base types) expected restricted __le32 const [usertype] *buf got unsigned int [usertype] *[assigned] buf Add a cast to fix it. Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_xrgb2101010()") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250630090054.353246-1-jose.exposito89@gmail.com
2025-07-16drm: Pass the format info to .fb_create()Ville Syrjälä-0/+1
Pass along the format information from the top to .fb_create() so that we can avoid redundant (and somewhat expensive) lookups in the drivers. Done with cocci (with some manual fixups): @@ identifier func =~ ".*create.*"; identifier dev, file, mode_cmd; @@ struct drm_framebuffer *func( struct drm_device *dev, struct drm_file *file, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd) { ... ( - const struct drm_format_info *info = drm_get_format_info(...); | - const struct drm_format_info *info; ... - info = drm_get_format_info(...); ) <... - if (!info) - return ...; ...> } @@ identifier func =~ ".*create.*"; identifier dev, file, mode_cmd; @@ struct drm_framebuffer *func( struct drm_device *dev, struct drm_file *file, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd) { ... } @find@ identifier fb_create_func =~ ".*create.*"; identifier dev, file, mode_cmd; @@ struct drm_framebuffer *fb_create_func( struct drm_device *dev, struct drm_file *file, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd); @@ identifier find.fb_create_func; expression dev, file, mode_cmd; @@ fb_create_func(dev, file + ,info ,mode_cmd) @@ expression dev, file, mode_cmd; @@ drm_gem_fb_create(dev, file + ,info ,mode_cmd) @@ expression dev, file, mode_cmd; @@ drm_gem_fb_create_with_dirty(dev, file + ,info ,mode_cmd) @@ expression dev, file_priv, mode_cmd; identifier info, fb; @@ info = drm_get_format_info(...); ... fb = dev->mode_config.funcs->fb_create(dev, file_priv + ,info ,mode_cmd); @@ identifier dev, file_priv, mode_cmd; @@ struct drm_mode_config_funcs { ... struct drm_framebuffer *(*fb_create)(struct drm_device *dev, struct drm_file *file_priv, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd); ... }; v2: Fix kernel docs (Laurent) Fix commit msg (Geert) Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Inki Dae <inki.dae@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Rob Clark <robdclark@gmail.com> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Dmitry Baryshkov <lumag@kernel.org> Cc: Sean Paul <sean@poorly.run> Cc: Marijn Suijten <marijn.suijten@somainline.org> Cc: Marek Vasut <marex@denx.de> Cc: Stefan Agner <stefan@agner.ch> Cc: Lyude Paul <lyude@redhat.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Cc: Biju Das <biju.das.jz@bp.renesas.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Andy Yan <andy.yan@rock-chips.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Mikko Perttunen <mperttunen@nvidia.com> Cc: Dave Stevenson <dave.stevenson@raspberrypi.com> Cc: "Maíra Canal" <mcanal@igalia.com> Cc: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> Cc: Gurchetan Singh <gurchetansingh@chromium.org> Cc: Chia-I Wu <olvaffe@gmail.com> Cc: Zack Rusin <zack.rusin@broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: amd-gfx@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: virtualization@lists.linux.dev Cc: spice-devel@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250701090722.13645-5-ville.syrjala@linux.intel.com
2025-07-16drm/tests: edid: Add edid-decode --check outputMaxime Ripard-0/+51
Some of our EDIDs are (rightfully) invalid, but most of them should be valid. Let's add the edid-decode --check of these EDIDs when they were generated, so we know what to expect going forward, and a comment to explicitly mention when we expect them to be broken. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250625-drm-update-edid-v1-3-2d963743ab9e@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-07-16drm/tests: edid: Update CTA-861 HDMI Vendor Specific Data BlockMaxime Ripard-45/+40
For some reason, the HDMI VSDBs in our kunit EDIDs had a length longer than expected. While this was harmless, we should get rid of it to make it somewhat predictable. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250625-drm-update-edid-v1-2-2d963743ab9e@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-07-16drm/tests: edid: Fix monitor range limitsMaxime Ripard-6/+6
For some reason, some EDIDs used by kunit had Monitor Range Limits making no sense, and not matching the edid-decode output in the comment. While they were in the comments as: Display Range Limits: Monitor ranges (GTF): 50-70 Hz V, 30-70 kHz H, max dotclock 150 MHz They were actually: Display Range Limits: Monitor ranges (GTF): 50-70 Hz V, 0-0 kHz H, max dotclock 1960 MHz Fix that section of the EDIDs to match the expected edid-decode output. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250625-drm-update-edid-v1-1-2d963743ab9e@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-27drm/format-helper: Split off byte swapping from drm_fb_xrgb8888_to_rgb565()Thomas Zimmermann-4/+4
Move big-endian support from drm_fb_xrgb8888_to_rgb565() into the new helper drm_xrgb8888_to_rgb565be(). The functionality is required for displays with big-endian byte order. Update all callers. With the change applied, drm_fb_xrgb8888_to_rgb565() has the same signature as the other conversion functions, which is required for further updates to drm_fb_blit(). Also makes the format-conversion helper available to panic handlers, if necessary. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250625114911.1121301-1-tzimmermann@suse.de
2025-06-18drm/format-helper: Move drm_fb_build_fourcc_list() to sysfb helpersThomas Zimmermann-11/+13
Only sysfb drivers use drm_fb_build_fourcc_list(). Move the function to sysfb helpers and rename it accordingly. Update drivers and tests. v3: - update naming in tests v2: - select DRM_SYSFB_HELPER (kernel test robot) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250616083846.221396-4-tzimmermann@suse.de
2025-06-18drm/tests: Test drm_fb_build_fourcc_list() in separate test suiteThomas Zimmermann-143/+168
Only sysfb drivers use drm_fb_build_fourcc_list(). The helper will be moved from format helpers to sysfb helpers. Moving the related tests to their own test suite. v3: - rename tests according to filename (José) v2: - rename filename to match tested code (Maxime) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250616083846.221396-3-tzimmermann@suse.de
2025-06-18drm/tests: Do not use drm_fb_blit() in format-helper testsThomas Zimmermann-92/+16
Export additional helpers from the format-helper library and open-code drm_fb_blit() in tests. Prepares for the removal of drm_fb_blit(). Only sysfb drivers use drm_fb_blit(). The function will soon be removed from format helpers and be refactored within sysfb helpers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: José Expósito <jose.exposito89@gmail.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250616083846.221396-2-tzimmermann@suse.de
2025-06-16drm: Include <linux/export.h>Thomas Zimmermann-0/+1
Fix the compile-time warnings drivers/gpu/drm/drm_atomic.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_atomic_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_atomic_state_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_atomic_uapi.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_auth.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_buddy.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_color_mgmt.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_connector.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_damage_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_debugfs_crc.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_drv.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_edid.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_exec.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_fb_dma_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_file.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_flip_work.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_format_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_gpusvm.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_gpuvm.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_managed.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_mipi_dbi.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_mipi_dsi.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_mode_config.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_modeset_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_modeset_lock.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_panic.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_plane.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_plane_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_print.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_privacy_screen.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_self_refresh_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_simple_kms_helper.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_suballoc.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_syncobj.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_vblank_work.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_vma_manager.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/drm_writeback.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/lib/drm_random.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing drivers/gpu/drm/tests/drm_kunit_helpers.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: a934a57a42f6 ("scripts/misc-check: check missing #include <linux/export.h> when W=1") Reviewed-by: André Almeida <andrealmeid@igalia.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250612121633.229222-3-tzimmermann@suse.de
2025-06-13drm/format-helper: Update tests after BT.601 changesThomas Zimmermann-6/+6
Commit a979a54165c2 ("drm/format-helper: Normalize BT.601 factors to 256") improved rounding precision of the BT.601 calculation, which impacts the results of soem of the format-helper tests. Adapt the test to the new results. v2: - fix spelling in commit description Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: a979a54165c2 ("drm/format-helper: Normalize BT.601 factors to 256") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250613111711.136993-1-tzimmermann@suse.de
2025-06-06drm/tests: bridge: add KUnit tests for devm_drm_bridge_alloc()Luca Ceresoli-0/+89
Add KUnit tests for the newly introduced devm_drm_bridge_alloc(). Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-3-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/tests: bridge: convert to devm_drm_bridge_alloc() APILuca Ceresoli-36/+51
Use the new DRM bridge allocation API, which is the only supported now, for the kunit tests. This change is more massive than for the typical DRM bridge driver because struct drm_bridge_init_priv currently embeds a struct drm_bridge, which is not supported anymore. We now have to use devm_drm_bridge_alloc() to dynamically allocate a "private driver struct", which is a bit awkward here because there is no real bridge driver. Thus let's add a "dummy" DRM bridge struct to represent it. As a nice cleanup we can now move the enable_count and disable_count members, which are counting bridge-specific events, into the new "private driver struct" (and avoid adding new unnecessary indirections). Also add a trivial bridge_to_dummy_bridge() function just like many drivers do. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-1-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Add test for unsuccessful fallback to YUV420Cristian Ciocaltea-0/+87
Provide test to verify a mandatory fallback to YUV420 output cannot succeed when driver doesn't advertise YUV420 support. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-19-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Add max TMDS rate fallback tests for YUV420 modeCristian Ciocaltea-0/+154
Provide tests to verify drm_atomic_helper_connector_hdmi_check() helper fallback behavior when using YUV420 output format. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-18-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Provide EDID supporting 4K@30Hz with RGB/YUVCristian Ciocaltea-0/+114
Create a test EDID advertising the following capabilities: Max resolution: 3840x2160@30Hz with RGB, YUV444, YUV422, YUV420 Max BPC: 16 for all modes Max TMDS clock: 340 MHz Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-17-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Rename max TMDS rate fallback testsCristian Ciocaltea-4/+4
In preparation to extend the max TMDS rate fallback tests for covering YUV420 output, update the rather generic function names drm_test_check_max_tmds_rate_{bpc|format}_fallback() to properly indicate the intended test cases. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-16-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Add limited range tests for YUV420 modeCristian Ciocaltea-5/+103
Provide tests to verify that drm_atomic_helper_connector_hdmi_check() helper behaviour when using YUV420 output format is to always set the limited RGB quantization range to 'limited', no matter what the value of Broadcast RGB property is. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-15-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Provide EDID supporting 4K@30Hz with YUV420 onlyCristian Ciocaltea-0/+118
Create a test EDID advertising the following capabilities: Max resolution: - 1920x1080@60Hz with RGB, YUV444, YUV422 - 3840x2160@30Hz with YUV420 only Max BPC: 16 for all modes Max TMDS clock: 200 MHz Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-14-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Switch to drm_atomic_get_new_connector_state() where possibleCristian Ciocaltea-6/+6
Replace the calls to drm_atomic_get_connector_state() with drm_atomic_get_new_connector_state() for cases which do not require allocating the connector state, e.g. after drm_atomic_check_only() when the intent is to only read the new connector state. The rational is to avoid the need to handle the potential EDEADLK error returned by the former helper, which would require restarting the entire atomic sequence. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-13-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Setup ycbcr_420_allowed before initializing connectorCristian Ciocaltea-0/+2
Initializing HDMI connector via drmm_connector_hdmi_init() requires its ->ycbcr_420_allowed flag to be adjusted according to the supported formats passed as function argument, prior to the actual invocation. In order to allow providing test coverage for YUV420 modes, ensure the flag is properly setup. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-12-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Drop unused drm_kunit_helper_connector_hdmi_init_funcs()Cristian Ciocaltea-10/+0
After updating the code to make use of the new EDID setup helper, drm_kunit_helper_connector_hdmi_init_funcs() became unused, hence drop it. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-11-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Replace open coded EDID setupCristian Ciocaltea-142/+92
Make use of the recently introduced macros to reduce boilerplate code around EDID setup. This also helps dropping the redundant calls to set_connector_edid(). No functional changes intended. Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-10-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-02drm/tests: hdmi: Add macro to simplify EDID setupCristian Ciocaltea-18/+28
Factor out the HDMI connector initialization from drm_kunit_helper_connector_hdmi_init_funcs() into a common __connector_hdmi_init() function, while extending its functionality to allow setting custom (i.e. non-default) EDID data. Introduce a macro as a wrapper over the new helper to allow dropping the open coded EDID setup from all test cases. The actual conversion will be handled separately; for now just apply it to drm_kunit_helper_connector_hdmi_init() helper. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250527-hdmi-conn-yuv-v5-9-74c9c4a8ac0c@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
generated by cgit v1.2.3 (git 2.46.0) at 2026-03-19 11:43:35 +0000