wireguard-linux/drivers/gpu/drm/amd/display, branch davem/net

drm/amd/display: Bump frame warning limit for all builds of dml

2026-09-24T13:17:58Z

Some configs with gcc are also now affected. Signed-off-by: Alex Deucher (cherry picked from commit 76b9706e7fa1a6e374703170128b1be2f590cda7)

drm/amd/display: Bump frame warning limit for clang builds of dml

2026-09-23T19:53:05Z

[Why&How] When building the DML files with clang without any sanitizer or LTO, the following -Wframe-larger-than errors break the build under CONFIG_WERROR: display_mode_vba_30.c: error: stack frame size (2512) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' display_mode_vba_31.c: error: stack frame size (2416) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' display_mode_vba_314.c: error: stack frame size (2392) exceeds limit (2048) in 'dml314_ModeSupportAndSystemConfigurationFull' Clang consistently spills more than gcc, pushing the frame past the 2048 byte limit. Apply an existing approach of increasing the warn stack size to the non-sanitizer path so plain clang builds use a 3072 byte limit. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5642 Signed-off-by: Ivan Lipski Signed-off-by: Alex Deucher (cherry picked from commit 21711b6e66bb7b41b1aec67b2d99aafe768c8fcb) Cc: stable@vger.kernel.org

drm/amd/display: Relax DML frame limit with UBSAN

2026-09-23T19:53:05Z

[WHY] UBSAN instrumentation adds checks and handler calls and increases stack usage in the large DML calculation functions, similar to KASAN and KCSAN. With UBSAN enabled these files exceed the default -Wframe-larger-than limit and fail to build when -Werror is in effect. Reproduced with LLVM (make LLVM=1, clang 19.1.1), CONFIG_UBSAN=y, CONFIG_GCOV_PROFILE_ALL=y and CONFIG_DRM_AMDGPU_WERROR=y on x86_64. [HOW] Include CONFIG_UBSAN in the sanitizer check that selects the higher per-file frame warning limit in the dml and dml2_0 Makefiles. Suggested-by: Leo Li Assisted-by: Copilot:Claude-Opus-5.5 Signed-off-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit ebf8b0fd8508b744f85a8eee82b745b1d3502dd0) Cc: stable@vger.kernel.org

drm/amd/display: Fix dc stream excess put in dm_update_crtc_state()

2026-09-23T19:51:09Z

In dm_update_crtc_state(), when a modeset is required the newly created stream is stored in dm_new_crtc_state->stream and an extra reference is taken with dc_stream_retain(). The reference returned by create_validate_stream_for_sink() is released as an extra reference at the skip_modeset label, leaving the stream owned by the new CRTC state. If amdgpu_dm_check_crtc_color_mgmt() fails afterwards, the code jumps to the fail label which releases new_stream again. Since the extra reference was already released at skip_modeset, this drops the reference owned by dm_new_crtc_state->stream and the stream is released while the atomic state still points to it, leading to a premature free of the dc stream. Set new_stream to NULL after releasing the extra reference at the skip_modeset label so that a later goto fail cannot release the reference owned by the new CRTC state. Fixes: 7cd4b70091a5 ("drm/amd/display: Rework CRTC color management") Signed-off-by: Wentao Liang Signed-off-by: Alex Deucher (cherry picked from commit 102a47065a62dc8f6bbbb47cf082a2934282eb08) Cc: stable@vger.kernel.org

drm/amd/display: fix MALL hysteresis timer underflow at high refresh rates

2026-09-17T15:59:24Z

dcn30_apply_idle_power_optimizations() derives the MALL frame cache hysteresis timer with tmr_delay = (uint32_t)(div_u64(..., denom) - 64LL); div_u64() returns a u64, so when the quotient is smaller than 64 the subtraction wraps instead of going negative and tmr_delay ends up huge. The loop that follows tries to squeeze it into the 6 bit register field by doubling denom, but that only makes the quotient smaller, so tmr_delay can never converge. tmr_scale is bumped past 3 and the function gives up with /* Delay exceeds range of hysteresis timer */ ASSERT(false); even though the requested delay is too *short* to encode, not too long. With mall_additional_timer_percent left at its default of 0, the quotient drops below 64 once the refresh rate used for the calculation goes above ~243 Hz. Every DCN 3.0 display above that loses MALL static screen entirely and splats a WARN once per boot. Reproduced on Navi 23 (RX 6600) driving 1920x1080, resetting /sys/kernel/debug/clear_warn_once between modes: refresh MALL ASSERT 144 Hz enabled no 240 Hz enabled no 280 Hz skipped yes 360 Hz skipped yes Commit 3bb68cec4db8 ("drm/amd/display: Add Overflow check to skip MALL") already covered the other end of the range, where a large stutter period makes the delay too long to encode. Cover the short end by clamping to 0, which selects the shortest hysteresis the register can express, 65.28us * 64 = ~4.18ms. That is marginally longer than what the formula asks for at these refresh rates, and erring long is the safe direction: it only delays MALL entry, it can never enter early. The numerator does not change between iterations, only denom does, so compute it once and keep both call sites inside 100 columns. The genuinely out of range case at very low refresh rates still reaches the ASSERT, which is where it belongs. Fixes: 52f2e83e2fe5 ("drm/amdgpu/display: add MALL support (v2)") Signed-off-by: Francis Marlou Pacaro Reviewed-by: Leo Li Signed-off-by: Alex Deucher (cherry picked from commit 387550e53e1405f1f960b62b22f8783db17c8e1d)

drm/amd/display: Fix NULL dereference in dcn50/dcn60 init_hw

2026-09-17T15:57:29Z

dc->clk_mgr is checked for NULL earlier in dcn50_init_hw() and dcn60_init_hw(), but dcn50_initialize_min_clocks() and dcn401_initialize_min_clocks() are called without any guard, causing Smatch to report potential NULL dereferences. Guard both call sites with the same pattern used throughout both functions: if (dc->clk_mgr && dc->clk_mgr->funcs) Also fix dcn50_initialize_min_clocks() which calls get_dispclk_from_dentist without checking the function pointer, unlike the dcn401 equivalent which guards that call. Fix kernel-doc in dcn60_hwseq.c by adding missing parameter descriptions for @probe in dcn60_update_probe_status() and @type in is_probe_measurement_type_for_hubbub(). Fixes: 7f7d7ea1fa51 ("drm/amd/display: Add new sources for DCN6") Reported-by: Dan Carpenter Cc: Aurabindo Pillai Cc: Ivan Lipski Cc: Dan Wheeler Cc: Roman Li Cc: Alex Hung Cc: Tom Chung Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 325c9a827cdd748e126eafeadaffc556204773d2)

drm/amd/display: Atomize IRQ register read/modify/write ops

2026-09-17T15:52:06Z

[Why] The OTG_GLOBAL_SYNC_STATUS register controls various HW IRQ sources for the output timing generator (OTG). VUPDATE_NO_LOCK is one of them. To enable the IRQ, driver sets the VUPDATE_NO_LOCK_EN bit in the GLOBAL_SYNC_STATUS register. To ack the IRQ after it fires, the driver sets the VUPDATE_NO_LOCK_CLEAR bit in the same GLOBAL_SYNC_STATUS register. The bit sets are done through read/modify/write operations, which are not atomic. Thus, the following race is possible: Thread A: IRQ handler: *HW IRQ fires* # IRQ disable val = read(GLOBAL_SYNC_STATUS) unset(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # ACK reads VUPDATE_NO_LOCK_EN unset val1 = read(GLOBAL_SYNC_STATUS) set(val1, VUPDATE_NO_LOCK_CLEAR) # IRQ enable val = read(GLOBAL_SYNC_STATUS) set(val, VUPDATE_NO_LOCK_EN) write(val, GLOBAL_SYNC_STATUS) # BAD! clears VUPDATE_NO_LOCK_EN write(val1, GLOBAL_SYNC_STATUS) Regarding the tagged Fixes: change, it appears the change made this race more likely to occur. Since VUPDATE_NO_LOCK is now the sole IRQ source for vblank handling, a single race on high refresh panels can lead to a time out. [How] The GLOBAL_SYNC_STATUS register is only one example, other IRQ control registers also share the same scheme. On top of GLOBAL_SYNC_STATUS, let's clean up those as well. To keep things simple, Let's atomize the IRQ rmw ops via a single driver-wide spinlock. Due to the small scope of this lock, it is unlikely to cause noticeable overhead on top of all the existing locking within the IRQ set/handle paths. Since DM is responsible for locking, wrap dc_interrupt_set/ack with the spinlock in the new amdgpu_dm_irq_set/ack functions. Migrate/drop all references in DM to dc_interrupt_set/ack to use amdgpu_dm_irq_set/ack instead. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5616 Fixes: c87e6635d2db ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Reviewed-by: Mario Limonciello Signed-off-by: Leo Li Signed-off-by: Chenyu Chen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 70de0a0216583a53c946155f8c8adedfdca6b4e7) Cc: stable@vger.kernel.org

drm/amd/display: Rebuild InfoFrames on output color space changes

2026-09-10T16:55:35Z

resource_build_info_frame() derives colorimetry and RGB quantization from stream->output_color_space. A Broadcast RGB-only atomic commit updates that field and reprograms the output CSC, but none of the InfoFrame update predicates include output_color_space. The sink can therefore retain the previous AVI InfoFrame range while the source starts transmitting a different pixel range. Treat an output color space change as an InfoFrame change in update classification and in both stream programming paths. Hardware testing on an HDMI 2.1 television confirmed that its automatic black-level selection follows Full to Limited and Limited to Full transitions in SDR, HDR, and HDR with VRR active, without a modeset or visible link blank. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit d6faca79f5720893843e649e70aeb19147ee0578) Cc: stable@vger.kernel.org

drm/amd/display: Honor Broadcast RGB for BT.2020 RGB output

2026-09-10T16:55:28Z

amdgpu_dm_get_output_color_space() applies the Broadcast RGB connector property to default RGB output, but always selects full-range output for BT.2020 RGB. Consequently, explicitly selecting Limited has no effect on the output CSC or AVI InfoFrame when HDR uses BT.2020 RGB. Select COLOR_SPACE_2020_RGB_LIMITEDRANGE when the output encoding is RGB and Broadcast RGB is Limited. Keep Automatic and Full at full range, and leave YCbCr output unchanged. Add KUnit coverage for limited-range RGB output through both BT.2020 connector colorspace values. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 022236eaa63bbf65761aa8aec43f661451a94654) Cc: stable@vger.kernel.org

drm/amd/display: Propagate HDMI RGB quantization selectability

2026-09-10T16:55:08Z

DC uses dc_edid_caps.qs_bit when constructing the HDMI AVI InfoFrame quantization-range field. Although DRM parses the sink capability into drm_display_info, DM never copies it into the DC EDID capabilities. The field therefore remains zero and the AVI quantization range stays at its default value. Copy rgb_quant_range_selectable for HDMI sinks and extend the existing EDID-capability KUnit test to cover it. Fixes: 6eb4c13a3845 ("drm/amd/display: Support "Broadcast RGB" drm property") Signed-off-by: Satyajit Roy Reviewed-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher (cherry picked from commit 892659399f64642e33072562a11ec1b2e7bd2263) Cc: stable@vger.kernel.org