kernel/linux.git/drivers/gpu, branch v6.19.5

drm/exynos: vidi: fix to avoid directly dereferencing user pointer

2026-02-26T23:01:41+00:00

commit d4c98c077c7fb2dfdece7d605e694b5ea2665085 upstream. In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it. Cc: Signed-off-by: Jeongjun Park Signed-off-by: Inki Dae Signed-off-by: Greg Kroah-Hartman

drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl()

2026-02-26T23:01:40+00:00

commit d3968a0d85b211e197f2f4f06268a7031079e0d0 upstream. vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer. Cc: Signed-off-by: Jeongjun Park Signed-off-by: Inki Dae Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Enable DAC in DCE link encoder

2026-02-26T23:01:38+00:00

[ Upstream commit 4bd8b5f8bcb57b430c35494d8a2471ce5fd7661d ] Ensure that the DAC output is enabled at the correct time by moving it to the DCE link encoder similarly to how digital outputs are enabled. This also removes the call to DAC1EncoderControl from the DCE HWSS, which always felt like it was a hacky solution. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf Tested-by: Mauro Rossi Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Set CRTC source for DAC using registers

2026-02-26T23:01:38+00:00

[ Upstream commit cbced93894d145239c83881d7fd953b7392c23a8 ] Apparently the VBIOS SelectCRTC_Source function overwrites a few registers (such as FMT_*) which DC writes in a different place, which can cause problems. Instead of using the SelectCRTC_Source function from the VBIOS, use the DAC_SOURCE_SELECT register directly, similarly to how it is done for digital link encoders. Fixes: 3be26d81b150 ("drm/amd/display: Support DAC in dce110_hwseq") Signed-off-by: Timur Kristóf Tested-by: Mauro Rossi Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Initialize DAC in DCE link encoder using VBIOS

2026-02-26T23:01:38+00:00

[ Upstream commit e2a024345bce78a8e1ed7d9e84c859b05979e41e ] The VBIOS DAC1EncoderControl() function can initialize the DAC, by writing board-specific values to certain registers. Call this at link encoder hardware initialization time similarly to how the equivalent UNIPHYTransmitterControl initialization is done. This fixes DAC output on the Radeon HD 7790. Also remove the ENCODER_CONTROL_SETUP enum from the dac_encoder_control_prepare_params function which is actually not a supported operation for DAC encoders. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf Tested-by: Mauro Rossi Suggested-by: Alex Deucher Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Turn off DAC in DCE link encoder using VBIOS

2026-02-26T23:01:38+00:00

[ Upstream commit e021ee995056ee7e58114edd92bcd4578d8b4bb5 ] Apparently, the VBIOS DAC1EncoderControl function is much more graceful about turning off the DAC. It writes various DAC registers in a specific sequence. Use that instead of just clearing the DAC_ENABLE register. Do this in just the dce110_link_encoder_disable_output function and remove it from the HWSS. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf Tested-by: Mauro Rossi Suggested-by: Alex Deucher Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Don't call find_analog_engine() twice

2026-02-26T23:01:38+00:00

[ Upstream commit 613b1737abe1bd0a65b49851e777231302095e28 ] The analog engine is already there in the link_analog_engine variable and assigned to enc_init_data.analog_engine already. I suspect this was a rebase mistake. Fixes: 436d0d22aa70 ("drm/amd/display: Pass proper DAC encoder ID to VBIOS") Signed-off-by: Timur Kristóf Tested-by: Mauro Rossi Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Use same max plane scaling limits for all 64 bpp formats

2026-02-26T23:01:38+00:00

[ Upstream commit f0157ce46cf0e5e2257e19d590c9b16036ce26d4 ] The plane scaling hw seems to have the same min/max plane scaling limits for all 16 bpc / 64 bpp interleaved pixel color formats. Therefore add cases to amdgpu_dm_plane_get_min_max_dc_plane_scaling() for all the 16 bpc fixed-point / unorm formats to use the same .fp16 up/downscaling factor limits as used by the fp16 floating point formats. So far, 16 bpc unorm formats were not handled, and the default: path returned max/min factors for 32 bpp argb8888 formats, which were wrong and bigger than what many DCE / DCN hw generations could handle. The result sometimes was misscaling of framebuffers with DRM_FORMAT_XRGB16161616, DRM_FORMAT_ARGB16161616, DRM_FORMAT_XBGR16161616, DRM_FORMAT_ABGR16161616, leading to very wrong looking display, as tested on Polaris11 / DCE-11.2. So far this went unnoticed, because only few userspace clients used such 16 bpc unorm framebuffers, and those didn't use hw plane scaling, so they did not experience this issue. With upcoming Mesa 26 exposing 16 bpc unorm formats under both OpenGL and Vulkan under Wayland, and the upcoming GNOME 50 Mutter Wayland compositor allowing for direct scanout of these formats, the scaling hw will be used on these formats if possible for HiDPI display scaling, so it is important to use the correct hw scaling limits to avoid wrong display. Tested on AMD Polaris 11 / DCE 11.2 with upcoming Mesa 26 and GNOME 50 on HiDPI displays with scaling enabled. The mutter Wayland compositor now correctly falls back to scaling via desktop compositing instead of direct scanout, thereby avoiding wrong image display. For unscaled mode, it correctly uses direct scanout. Fixes: 580204038f5b ("drm/amd/display: Enable support for 16 bpc fixed-point framebuffers.") Signed-off-by: Mario Kleiner Tested-by: Mario Kleiner Cc: Alex Deucher Cc: Harry Wentland Cc: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Only use analog stream encoder with analog engine

2026-02-26T23:01:38+00:00

[ Upstream commit 17ff034f805e032ed1358624a71381f9d6e29e9e ] Some GPUs have analog connectors that work with a DP bridge chip and don't actually have an internal DAC: Those should not use the analog stream encoders. Fixes: 5834c33fd3f6 ("drm/amd/display: Add concept of analog encoders (v2)") Signed-off-by: Timur Kristóf Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Only use analog link encoder with analog engine

2026-02-26T23:01:37+00:00

[ Upstream commit f402898bd101af3166bde236b7f6a43d926e17a0 ] Some GPUs have analog connectors that work with a DP bridge chip and don't actually have an internal DAC: Those should not use the analog link encoder code path. Fixes: 0fbe321a93ce ("drm/amd/display: Implement DCE analog link encoders (v2)") Signed-off-by: Timur Kristóf Reviewed-by: Alex Hung Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin