kernel/drivers/gpu/drm/amd/display/dc/dccg, branch linux-rolling-stable

drm/amd/display: Add more DC HW state info to underflow logging

2025-10-28T13:57:44Z

[Why] Debugging underflow issues frequently requires knowing the HW state at the time of underflow. To enable capturing this HW state information, interface functions are needed for the various DC HW blocks. [How] This change adds the interface functions to read HW state for the following DC HW blocks: - HUBBUB - HUBP - DPP - MPC - OPP - DSC - OPTC - DCCG Reviewed-by: George Shen Signed-off-by: Karen Chen Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Fix GFP_ATOMIC abuse

2025-10-20T22:26:08Z

There is a lot GFP_ATOMIC allocations which are not in interrupt context. Change them to use GFP_KERNEL instead. Reviewed-by: Leo Li Signed-off-by: Aurabindo Pillai Signed-off-by: Tom Chung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Move all DCCG RCG into HWSS root_clock_control

2025-10-20T22:21:59Z

[why & how] Enabling/disabling DCCG RCG should be done as a last-level step when enabling/disable blocks. This is handled by HWSS root_clock_control already during optimize_bandwidth. However, dccg35_dpp_root_clock_control was missing the RCG enable call on the disable path. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Ovidiu Bunea Signed-off-by: Aurabindo Pillai Signed-off-by: Alex Deucher

drm/amd/display: fix dppclk rcg poweron check

2025-10-20T22:21:52Z

[WHY & HOW] dppclk rcg power down will flip the poweron flag in the cache to cause dppclk rcg will never run the rcg ungate sequence in some condition. Wait 10us to let dpp dto fully ramp. Reviewed-by: Ovidiu (Ovi) Bunea Reviewed-by: Nicholas Kazlauskas Signed-off-by: Yihan Zhu Signed-off-by: Aurabindo Pillai Signed-off-by: Alex Deucher

drm/amd/display: add dccg dfs mask def

2025-10-20T22:20:35Z

[why] add some register masks for DCCG Reviewed-by: Yihan Zhu Reviewed-by: Alvin Lee Signed-off-by: Charlene Liu Signed-off-by: Aurabindo Pillai Signed-off-by: Alex Deucher

drm/amd/display: add dispclk ramping to dcn35.

2025-10-20T22:19:35Z

[why] this is a required logic based on HW programming guide. tested/ported on dcn401. Reviewed-by: Yihan Zhu Signed-off-by: Charlene Liu Signed-off-by: Aurabindo Pillai Signed-off-by: Alex Deucher

drm/amd/display: Prevent Gating DTBCLK before It Is Properly Latched

2025-10-13T18:14:32Z

[why] 1. With allow_0_dtb_clk enabled, the time required to latch DTBCLK to 600 MHz depends on the SMU. If DTBCLK is not latched to 600 MHz before set_mode completes, gating DTBCLK causes the DP2 sink to lose its clock source. 2. The existing DTBCLK gating sequence ungates DTBCLK based on both pix_clk and ref_dtbclk, but gates DTBCLK when either pix_clk or ref_dtbclk is zero. pix_clk can be zero outside the set_mode sequence before DTBCLK is properly latched, which can lead to DTBCLK being gated by mistake. [how] Consider both pixel_clk and ref_dtbclk when determining when it is safe to gate DTBCLK; this is more accurate. Reviewed-by: Charlene Liu Reviewed-by: Aurabindo Pillai Signed-off-by: Fangzhi Zuo Signed-off-by: Roman Li Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Insert dccg log for easy debug

2025-09-23T14:32:15Z

[why] Log for sequence tracking Reviewed-by: Ovidiu (Ovi) Bunea Reviewed-by: Yihan Zhu Signed-off-by: Charlene Liu Signed-off-by: Ivan Lipski Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Correct sequences and delays for DCN35 PG & RCG

2025-09-05T21:38:41Z

[why] The current PG & RCG programming in driver has some gaps and incorrect sequences. [how] Added delays after ungating clocks to allow ramp up, increased polling to allow more time for power up, and removed the incorrect sequences. Cc: Mario Limonciello Cc: Alex Deucher Reviewed-by: Charlene Liu Signed-off-by: Ovidiu Bunea Signed-off-by: Wayne Lin Tested-by: Dan Wheeler Signed-off-by: Alex Deucher

drm/amd/display: incorrect conditions for failing dto calculations

2025-08-29T14:14:05Z

[Why & How] Previously, when calculating dto phase, we would incorrectly fail when phase <=0 without additionally checking for the integer value. This meant that calculations would incorrectly fail when the desired pixel clock was an exact multiple of the reference clock. Reviewed-by: Dillon Varone Signed-off-by: Clay King Signed-off-by: Alex Hung Tested-by: Dan Wheeler Signed-off-by: Alex Deucher