linux/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c, branch v6.19

drm/amd/display: To apply the adjusted DP ref clock for DP devices

2025-04-21T15:26:59Z

[Why] For some pixel clock margin sensitive external monitor, we could not keep original DP ref clock for the ASICs supported SSC DP ref clock. [How] From slicon design team's comment, we have to apply the adjusted DP ref clock for DP devices. DP 128b (DP2) signals uses the DTBCLK not DP ref. Reviewed-by: Nicholas Kazlauskas Signed-off-by: Yiling Chen Signed-off-by: Zaeem Mohamed Tested-by: Mark Broadworth Signed-off-by: Alex Deucher

drm/amd/display: Block Invalid TMDS operation

2024-12-18T17:21:37Z

[Why] When sink type is TMDS, PHY programming does not block against pixel clock greater than 600MHz. [How] Based on sink type, block greater than 600MHz phy programming. Tested-by: Daniel Wheeler Reviewed-by: Aric Cyr Signed-off-by: Chris Park Signed-off-by: Dillon Varone Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher

drm/amd/display: Fix possible overflow in integer multiplication

2024-07-01T20:06:53Z

[WHAT & HOW] Integer multiplies integer may overflow in context that expects an expression of unsigned/siged long long (64 bits). This can be fixed by casting integer to unsigned/siged long long to force 64 bits results. This fixes 26 OVERFLOW_BEFORE_WIDEN issues reported by Coverity. Reviewed-by: Harry Wentland Signed-off-by: Jerry Zuo Signed-off-by: Alex Hung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Prevent overflow on DTO calculation

2024-06-14T20:17:15Z

[Why] uint32_t is implicitly converted to uint64_t while multiplication still happens on uint32_t side. This creates digit overflow for large pixel clock which is meant to be retained in uint64_t. [How] Calculate multiplication of units in uint64_t domain instead of uint32_t in DTO parameter clock caculation. Reviewed-by: Alvin Lee Acked-by: Zaeem Mohamed Signed-off-by: Chris Park Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Modify HPO pixel clock programming to support DPM

2024-05-20T20:20:24Z

Need to select DTBCLK and DPREFCLK as DTBCLK_p source according to hardware guidance. Reviewed-by: Rodrigo Siqueira Signed-off-by: Dillon Varone Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Use the correct TMDS function to avoid DVI issues

2024-05-20T20:19:34Z

[Why] DVI is TMDS signal like HDMI but without audio. Current signal check does not correctly reflect DVI clock programming. [How] Define a new signal check for TMDS that includes DVI to HDMI TMDS programming. Reviewed-by: Rodrigo Siqueira Signed-off-by: Chris Park Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: Add misc DC changes for DCN401

2024-04-26T21:23:34Z

Add miscellaneous changes to enable DCN401 init Signed-off-by: Aurabindo Pillai Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher

drm/amd/display: Adjust dprefclk by down spread percentage.

2024-04-10T02:16:45Z

[Why] OLED panels show no display for large vtotal timings. [How] Check if ss is enabled and read from lut for spread spectrum percentage. Adjust dprefclk as required. DP_DTO adjustment is for edp only. Cc: stable@vger.kernel.org Reviewed-by: Nicholas Kazlauskas Acked-by: Hamza Mahfooz Signed-off-by: Zhongwei Signed-off-by: Alex Deucher

drm/amd/display: To adjust dprefclk by down spread percentage

2024-01-09T20:43:53Z

[Why] Panels show corruption with high refresh rate timings when ssc is enabled. [How] Read down-spread percentage from lut to adjust dprefclk. Issues come from S0i3 with this commit has been fixed by SMU. Reviewed-by: Nicholas Kazlauskas Acked-by: Rodrigo Siqueira Signed-off-by: Martin Tsai Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher

drm/amd/display: switch DC over to the new DRM logging macros

2023-09-26T21:00:21Z

For multi-GPU systems it is difficult to tell which GPU a particular message is being printed for and that is undesirable because it complicates debugging efforts. Also, the new macros allow us to enable logging for particular parts of the codebase more selectively (since we no longer need to throw everything at DRM_DEBUG_KMS()). So, for the reasons outlined above we should switch to the new macros. We can accomplish this by using the existing DC_LOGGER code to pass around the relevant `struct drm_device` which will be fed to the new macros in logger_types.h. Also, we must get rid of all instances of the DC_LOG_.*() functions that are currently in amdgpu_dm since we don't use the DC logger there and we can simply refer to the macros directly there instead. Reviewed-by: Rodrigo Siqueira Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher