linux/drivers/gpu/drm/sun4i, branch master

drm/display: hdmi: Use drm_output_color_format instead of hdmi_colorspace

2026-03-24T12:54:35Z

The hdmi_colorspace enum was defined to represent the colorspace value of the HDMI infoframes. It was later used by some HDMI drivers to express the output format they should be setting up. During the introduction of the HDMI helpers, it then was used to represent it in the drm_connector_hdmi_state structure. However, it's always been somewhat redundant with the DRM_COLOR_FORMAT_* defines, and now with the drm_output_color_format enum. Let's consolidate around drm_output_color_format in drm_connector_hdmi_state to facilitate the current effort to provide a global output format selection mechanism. Acked-by: Jani Nikula Reviewed-by: Nicolas Frattaroli Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-14-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard

drm/sun4i: Use backend/mixer as dedicated DMA device

2026-03-23T05:23:29Z

The sun4i DRM driver deals with DMA constraints in a peculiar way. Instead of using the actual DMA device in various helpers, it justs reconfigures the DMA constraints of the virtual display device using the DMA device's device tree node by calling of_dma_configure(). Turns out of_dma_configure() should only be called from bus code. Lately this also triggers a big warning through of_iommu_configure() and ultimately __iommu_probe_device(): late IOMMU probe at driver bind, something fishy here! Now that the GEM DMA helpers have proper support for allocating and mapping buffers with a dedicated DMA device, switch over to it as the proper solution. The mixer change was tested on a Pine H64 model B. The backend change was only compile tested. Though I don't expect any issues, help testing on an older device would be appreciated. Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20260311094929.3393338-5-wenst@chromium.org Signed-off-by: Chen-Yu Tsai

drm/sun4i: layers: Use drm_fb_dma_get_gem_addr() to get display memory

2026-03-14T08:08:51Z

Commit 4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()") adds a new helper, which covers fetching a drm_framebuffer's GEM object and calculating the buffer address for a given plane. This patch uses this helper to replace our own open coded version of the same function. Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260309165635.1138413-1-wens@kernel.org Signed-off-by: Chen-Yu Tsai

drm/sun4i: Fix resource leaks

2026-03-14T08:07:52Z

Three clocks are not being released in devm_regmap_init_mmio() error path. Add proper goto and set ret to the error code. Fixes: 8270249fbeaf0 ("drm/sun4i: backend: Create regmap after access is possible") Signed-off-by: Ethan Tidmore Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260226163836.10335-1-ethantidmore06@gmail.com Signed-off-by: Chen-Yu Tsai

drm/sun4i: fix kernel-doc warnings in sunxi_engine.h

2026-02-24T18:01:16Z

Correct the kernel-doc notation, add a missing struct member comment, and add a missing "Returns:" function comment to eliminate kernel-doc warnings: Warning: drivers/gpu/drm/sun4i/sunxi_engine.h:116 Incorrect use of kernel-doc format: * @mode_set Warning: drivers/gpu/drm/sun4i/sunxi_engine.h:125 struct member 'mode_set' not described in 'sunxi_engine_ops' Warning: drivers/gpu/drm/sun4i/sunxi_engine.h:144 struct member 'list' not described in 'sunxi_engine' Warning: drivers/gpu/drm/sun4i/sunxi_engine.h:168 No description found for return value of 'sunxi_engine_layers_init' Signed-off-by: Randy Dunlap Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260219215524.468142-1-rdunlap@infradead.org Signed-off-by: Chen-Yu Tsai

drm/sun4i: backend: fix error pointer dereference

2026-02-24T17:52:42Z

The function drm_atomic_get_plane_state() can return an error pointer and is not checked for it. Add error pointer check. Detected by Smatch: drivers/gpu/drm/sun4i/sun4i_backend.c:496 sun4i_backend_atomic_check() error: 'plane_state' dereferencing possible ERR_PTR() Fixes: 96180dde23b79 ("drm/sun4i: backend: Add a custom atomic_check for the frontend") Signed-off-by: Ethan Tidmore Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260217014801.60760-1-ethantidmore06@gmail.com Signed-off-by: Chen-Yu Tsai

drm/sun4i: mixer: Fix layer init code

2026-02-24T17:37:34Z

Code refactoring dropped extra NULL sentinel entry at the end of the drm planes array. Add it back. Reported-by: Chen-Yu Tsai Closes: https://lore.kernel.org/linux-sunxi/CAGb2v65wY2pF6sR+0JgnpLa4ysvjght5hAKDa1RUyo=zEKXreg@mail.gmail.com/ Fixes: 4fa45b04a47d ("drm/sun4i: layer: move num of planes calc out of layer code") Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai Link: https://patch.msgid.link/20260218183454.7881-1-jernej.skrabec@gmail.com [wens@kernel.org: Fix "Fixes" commit hash] Signed-off-by: Chen-Yu Tsai

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51Z

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28Z

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

drm/display: hdmi_state_helper: split InfoFrame functions per type

2026-01-19T11:11:46Z

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 Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-6-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov