linux/drivers/gpu/drm/amd/display/dc, branch master

Merge v7.0-rc7 into drm-next

2026-04-07T10:36:31Z

Thomas Zimmermann needs 2f42c1a61616 ("drm/ast: dp501: Fix initialization of SCU2C") for drm-misc-next. Conflicts: - drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c Just between e927b36ae18b ("drm/amd/display: Fix NULL pointer dereference in dcn401_init_hw()") and it's cherry-pick that confused git. - drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c Deleted in 6b0a6116286e ("drm/amd/pm: Unify version check in SMUv11") but some cherry-picks confused git. Same for v12/v14. Signed-off-by: Simona Vetter

drm/amd/display: Wire up dcn10_dio_construct() for all pre-DCN401 generations

2026-04-02T19:24:13Z

Description: - Commit b82f0759346617b2 ("drm/amd/display: Migrate DIO registers access from hwseq to dio component") moved DIO_MEM_PWR_CTRL register access behind the new dio abstraction layer but only created the dio object for DCN 4.01. On all other generations (DCN 10/20/21/201/30/301/302/303/ 31/314/315/316/32/321/35/351/36), the dio pointer is NULL, causing the register write to be silently skipped. This results in AFMT HDMI memory not being powered on during init_hw, which can cause HDMI audio failures and display issues on affected hardware including Renoir/Cezanne (DCN 2.1) APUs that use dcn10_init_hw. Call dcn10_dio_construct() in each older DCN generation's resource.c to create the dio object, following the same pattern as DCN 4.01. This ensures the dio pointer is non-NULL and the mem_pwr_ctrl callback works through the dio abstraction for all DCN generations. Fixes: b82f07593466 ("drm/amd/display: Migrate DIO registers access from hwseq to dio component.") Reviewed-by: Ivan Lipski Signed-off-by: Ionut Nechita Signed-off-by: Alex Deucher

drm/amd/display: Fix NULL pointer dereference in dcn401_init_hw()

2026-03-30T20:18:47Z

dcn401_init_hw() assumes that update_bw_bounding_box() is valid when entering the update path. However, the existing condition: ((!fams2_enable && update_bw_bounding_box) || freq_changed) does not guarantee this, as the freq_changed branch can evaluate to true independently of the callback pointer. This can result in calling update_bw_bounding_box() when it is NULL. Fix this by separating the update condition from the pointer checks and ensuring the callback, dc->clk_mgr, and bw_params are validated before use. Fixes the below: ../dc/hwss/dcn401/dcn401_hwseq.c:367 dcn401_init_hw() error: we previously assumed 'dc->res_pool->funcs->update_bw_bounding_box' could be null (see line 362) Fixes: ca0fb243c3bb ("drm/amd/display: Underflow Seen on DCN401 eGPU") Cc: Daniel Sa Cc: Alvin Lee Cc: Roman Li Cc: Alex Hung Cc: Tom Chung Cc: Dan Carpenter Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Hung Signed-off-by: Alex Deucher (cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477) Cc: stable@vger.kernel.org

drm/amd/display: Promote DC to 3.2.376

2026-03-30T19:12:54Z

This version brings along following fixes: - correct unknown plane state patch - Revert "Refactor DC update checks" - Revert "Add 3DLUT DMA broadcast support" - Remove invalid DPSTREAMCLK mask usage - enable eDP DSC seamless boot support - Revert "Rework HDMI link training and YCbCr422 with DSC policy" - Disable PSR & Replay CRTC disable by default - Fix Silence Compiler Warnings - Add link output control for DPIA - eliminate clock manager code duplication - Don't set 4to1MPC config dynamically - Merge pipes for validate - Fix bounds checking in dml2_0 clock table array - Avoid turning off the PHY when OTG is running for DVI - Should support p-state under dcn21 - Enable Replay support for dcn42 - Remove check for DC_DMCUB_ENABLE on DCN42 Acked-by: Wayne Lin Signed-off-by: Taimur Hassan Signed-off-by: Chuanyu Tseng Signed-off-by: Alex Deucher

drm/amd/display: Silence type conversion warnings in dml2

2026-03-30T19:12:47Z

[Why] Compiler build generates type conversion warnings throughout dc/dml2_0 where values are implicitly narrowed (e.g. int/uint32_t/uint64_t assigned to uint8_t, unsigned char, char, bool, or dml_bool_t), cluttering build output and masking genuine issues. [How] Add explicit casts at each narrowing assignment with ASSERT guards to catch out-of-range values in debug builds: - uint8_t: otg_inst, num_planes, pipe_idx, vblank_index fields - unsigned char: pipe_dlg_param.otg_inst from tg->inst - char: mcache num_pipes from num_dpps_required - bool/dml_bool_t: INTERLACE bitfield and fams2 enable flag use != 0 - uint64_t: widen min_hardware_refresh_in_uhz to hold div64_u64 result, then cast to unsigned long for min_refresh_uhz with ASSERT Reviewed-by: Austin Zheng Signed-off-by: Gaghik Khachatrian Signed-off-by: Chuanyu Tseng Signed-off-by: Alex Deucher

drm/amd/display: Fixed Silence complier warnings in dc

2026-03-30T19:12:15Z

[Why] Resolve compiler warnings by marking unused parameters explicitly. [How] In .c and .h function definitions, keep parameter names in signatures and add a line with `(void)param;` in function body Preserved function signatures and avoids breaking code paths that may reference the parameter under conditional compilation. Reviewed-by: Dillon Varone Reviewed-by: Austin Zheng Signed-off-by: Gaghik Khachatrian Signed-off-by: Chuanyu Tseng Signed-off-by: Alex Deucher

drm/amd/display: Move FPU Guards From DML To DC - Part 3

2026-03-30T19:08:45Z

[Why] FPU guards (DC_FP_START/DC_FP_END) are required to wrap around code that can manipulates floats. To do this properly, the FPU guards must be used in a file that is not compiled as a FPU unit. If the guards are used in a file that is a FPU unit, other sections in the file that aren't guarded may be end up being compiled to use FPU operations. [How] Added DC_FP_START and DC_FP_END to DC functions that call DML functions using FPU. Reviewed-by: Dillon Varone Signed-off-by: Rafal Ostrowski Signed-off-by: Alex Hung Signed-off-by: Alex Deucher

drm/amd/display: Move FPU Guards From DML To DC - Part 2

2026-03-30T19:06:26Z

[Why] FPU guards (DC_FP_START/DC_FP_END) are required to wrap around code that can manipulates floats. To do this properly, the FPU guards must be used in a file that is not compiled as a FPU unit. If the guards are used in a file that is a FPU unit, other sections in the file that aren't guarded may be end up being compiled to use FPU operations. [How] Removed DC_FP_START and DC_FP_END. Reviewed-by: Dillon Varone Signed-off-by: Rafal Ostrowski Signed-off-by: Alex Hung Signed-off-by: Chuanyu Tseng Signed-off-by: Alex Deucher

drm/amd/display: Move FPU Guards From DML To DC - Part 1

2026-03-30T19:06:10Z

drm/amd/display: correct unknown plane state patch

2026-03-30T19:01:57Z

[why] dcn42x is using same gfx as dcn35, i.e. not use gfx_address3. Reviewed-by: Ovidiu Bunea Signed-off-by: Charlene Liu Signed-off-by: Chuanyu Tseng Signed-off-by: Alex Deucher