kernel.git/drivers/gpu/drm/amd/display/dc/dml, branch linux-6.17.y

drm/amd/display: update dpp/disp clock from smu clock table

2025-11-13T20:36:57Z

[ Upstream commit 2e72fdba8a32ce062a86571edff4592710c26215 ] [Why] The reason some high-resolution monitors fail to display properly is that this platform does not support sufficiently high DPP and DISP clock frequencies [How] Update DISP and DPP clocks from the smu clock table then DML can filter these mode if not support. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Paul Hsieh Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Fix unsafe uses of kernel mode FPU

2025-10-19T14:37:23Z

commit ddbfac152830e38d488ff8e45ab7eaf5d72f8527 upstream. The point of isolating code that uses kernel mode FPU in separate compilation units is to ensure that even implicit uses of, e.g., SIMD registers for spilling occur only in a context where this is permitted, i.e., from inside a kernel_fpu_begin/end block. This is important on arm64, which uses -mgeneral-regs-only to build all kernel code, with the exception of such compilation units where FP or SIMD registers are expected to be used. Given that the compiler may invent uses of FP/SIMD anywhere in such a unit, none of its code may be accessible from outside a kernel_fpu_begin/end block. This means that all callers into such compilation units must use the DC_FP start/end macros, which must not occur there themselves. For robustness, all functions with external linkage that reside there should call dc_assert_fp_enabled() to assert that the FPU context was set up correctly. Fix this for the DCN35, DCN351 and DCN36 implementations. Cc: Austin Zheng Cc: Jun Lei Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: "Christian König" Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Ard Biesheuvel Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Remove redundant semicolons

2025-10-15T10:03:42Z

[ Upstream commit 90b810dd859c0df9db2290da1ac5842e5f031267 ] Remove unnecessary semicolons. Fixes: dda4fb85e433 ("drm/amd/display: DML changes for DCN32/321") Signed-off-by: Liao Yuanhong Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

drm/amd/display: Remove dml/dcn401 files and references

2025-06-18T16:19:16Z

[WHY & HOW] DCN401 is only supported using DML2.1, so remove unused code and files. Reviewed-by: Alvin Lee Signed-off-by: Dillon Varone Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: replace fast_validate with enum dc_validate_mode

2025-06-03T19:36:23Z

[Why] The boolean fast_validate is used as an input parameter in multiple functions. To support more scenarios, we are replacing it with enum dc_validate_mode. [How] The enum dc_validate_mode introduces three possible values: 1) DC_VALIDATE_MODE_AND_PROGRAMMING: Apply the mode to hardware 2) DC_VALIDATE_MODE_ONLY: Check whether the mode can be supported 3) DC_VALIDATE_MODE_AND_STATE_INDEX: Check if the mode can be supported, and determine the optimal voltage level needed to support it. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Yan Li Signed-off-by: Wayne Lin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

Revert: "drm/amd/display: Enable urgent latency adjustment on DCN35"

2025-05-13T13:27:44Z

This reverts commit 756c85e4d0dd ("drm/amd/display: Enable urgent latency adjustment on DCN35") Reason for revert: Negative power impact. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Gabe Teeger Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Refactor SubVP cursor limiting logic

2025-05-05T16:58:49Z

[WHY] There are several gaps that can result in SubVP being enabled with incompatible HW cursor sizes, and unjust restrictions to cursor size due to wrong predictions on future usage of SubVP. [HOW] - remove "prediction" logic in favor of tagging based on previous SubVP usage - block SubVP if current HW cursor settings are incompatible - provide interface for DM to determine if HW cursor should be disabled due to an attempt to enable SubVP Reviewed-by: Alvin Lee Signed-off-by: Dillon Varone Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

Revert "drm/amd/display: Refactor SubVP cursor limiting logic"

2025-05-05T16:55:35Z

This reverts commit 19e743f0fb73 ("drm/amd/display: Refactor SubVP cursor limiting logic") Reason for revert: Corruption Reviewed-by: Alvin Lee Signed-off-by: Ryan Seto Signed-off-by: Ray Wu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Correct prefetch calculation

2025-04-22T12:51:45Z

[Why] The minimum value of the dst_y_prefetch_equ was not correct in prefetch calculation whice causes OPTC underflow. [How] Add the min operation of dst_y_prefetch_equ in prefetch calculation for legacy DML. Reviewed-by: Nicholas Kazlauskas Signed-off-by: TungYu Lu Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher

drm/amd/display: Refactor SubVP cursor limiting logic

2025-04-22T12:51:45Z

[WHY] There are several gaps that can result in SubVP being enabled with incompatible HW cursor sizes, and unjust restrictions to cursor size due to wrong predictions on future usage of SubVP [HOW] - remove "prediction" logic in favor of tagging based on previous SubVP usage - block SubVP if current HW cursor settings are incompatible - provide interface for DM to determine if HW cursor should be disabled due to an attempt to enable SubVP Reviewed-by: Alvin Lee Signed-off-by: Dillon Varone Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher