linux-toradex.git/drivers/gpu/drm/amd/display, branch v6.10

drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport

2024-07-01T20:53:24+00:00

[Why]
Potential out of bounds access in dml2_calculate_rq_and_dlg_params()
because the value of out_lowest_state_idx used as an index for FCLKChangeSupport
array can be greater than 1.

[How]
Currently dml2 core specifies identical values for all FCLKChangeSupport
elements. Always use index 0 in the condition to avoid out of bounds access.

Acked-by: Rodrigo Siqueira 
Signed-off-by: Jerry Zuo 
Signed-off-by: Roman Li 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Update efficiency bandwidth for dcn351

2024-07-01T20:52:24+00:00

Fix 4k240 underflow on dcn351

Acked-by: Rodrigo Siqueira 
Signed-off-by: Fangzhi Zuo 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Fix refresh rate range for some panel

2024-07-01T20:51:15+00:00

[Why]
Some of the panels does not have the refresh rate range info
in base EDID and only have the refresh rate range info in
DisplayID block.
It will cause the max/min freesync refresh rate set to 0.

[How]
Try to parse the refresh rate range info from DisplayID if the
max/min refresh rate is 0.

Reviewed-by: Sun peng Li 
Signed-off-by: Jerry Zuo 
Signed-off-by: Tom Chung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Account for cursor prefetch BW in DML1 mode support

2024-07-01T20:50:02+00:00

[Description]
We need to ensure to take into account cursor prefetch BW in
mode support or we may pass ModeQuery but fail an actual flip
which will cause a hang. Flip may fail because the cursor_pre_bw
is populated during mode programming (and mode programming is
never called prior to ModeQuery).

Reviewed-by: Chaitanya Dhere 
Reviewed-by: Nevenko Stupar 
Signed-off-by: Jerry Zuo 
Signed-off-by: Alvin Lee 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Add refresh rate range check

2024-07-01T20:48:40+00:00

[Why]
We only enable the VRR while monitor usable refresh rate range
is greater than 10 Hz.
But we did not check the range in DRM_EDID_FEATURE_CONTINUOUS_FREQ
case.

[How]
Add a refresh rate range check before set the freesync_capable flag
in DRM_EDID_FEATURE_CONTINUOUS_FREQ case.

Reviewed-by: Mario Limonciello 
Reviewed-by: Rodrigo Siqueira 
Signed-off-by: Jerry Zuo 
Signed-off-by: Tom Chung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Reset freesync config before update new state

2024-07-01T20:45:05+00:00

[Why]
Sometimes the new_crtc_state->vrr_infopacket did not sync up with the
current state.
It will affect the update_freesync_state_on_stream() does not update
the state correctly.

[How]
Reset the freesync config before get_freesync_config_for_crtc() to
make sure we have the correct new_crtc_state for VRR.

Reviewed-by: Sun peng Li 
Signed-off-by: Jerry Zuo 
Signed-off-by: Tom Chung 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Send DP_TOTAL_LTTPR_CNT during detection if LTTPR is present

2024-06-25T18:15:45+00:00

[WHY]
New register field added in DP2.1 SCR, needed for auxless ALPM

[HOW]
Echo value read from 0xF0007 back to sink

Reviewed-by: Wenjing Liu 
Cc: Mario Limonciello 
Cc: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Alex Hung 
Signed-off-by: Michael Strauss 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher

drm/amd/display: Disable CONFIG_DRM_AMD_DC_FP for RISC-V with clang

2024-06-19T18:17:25+00:00

Commit 77acc6b55ae4 ("riscv: add support for kernel-mode FPU") and
commit a28e4b672f04 ("drm/amd/display: use ARCH_HAS_KERNEL_FPU_SUPPORT")
enabled support for CONFIG_DRM_AMD_DC_FP with RISC-V. Unfortunately,
this exposed -Wframe-larger-than warnings (which become fatal with
CONFIG_WERROR=y) when building ARCH=riscv allmodconfig with clang:

  drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:58:13: error: stack frame size (2448) exceeds limit (2048) in 'DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation' [-Werror,-Wframe-larger-than]
     58 | static void DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation(
        |             ^
  1 error generated.

Many functions in this file use a large number of parameters, which must
be passed on the stack at a certain pointer due to register exhaustion,
which can cause high stack usage when inlining and issues with stack
slot analysis get involved. While the compiler can and should do better
(as GCC uses less than half the amount of stack space for the same
function), it is not as simple as a fix as adjusting the functions not
to take a large number of parameters.

Unfortunately, modifying these files to avoid the problem is a difficult
to justify approach because any revisions to the files in the kernel
tree never make it back to the original source (so copies of the code
for newer hardware revisions just reintroduce the issue) and the files
are hard to read/modify due to being "gcc-parsable HW gospel, coming
straight from HW engineers".

Avoid building the problematic code for RISC-V by modifying the existing
condition for arm64 that exists for the same reason. Factor out the
logical not to make the condition a little more readable naturally.

Fixes: a28e4b672f04 ("drm/amd/display: use ARCH_HAS_KERNEL_FPU_SUPPORT")
Reported-by: Palmer Dabbelt 
Closes: https://lore.kernel.org/20240530145741.7506-2-palmer@rivosinc.com/
Reviewed-by: Harry Wentland 
Signed-off-by: Nathan Chancellor 
Signed-off-by: Alex Deucher

drm/amd/display: Attempt to avoid empty TUs when endpoint is DPIA

2024-06-19T18:17:25+00:00

[WHY]
Empty SST TUs are illegal to transmit over a USB4 DP tunnel.
Current policy is to configure stream encoder to pack 2 pixels per pclk
even when ODM combine is not in use, allowing seamless dynamic ODM
reconfiguration. However, in extreme edge cases where average pixel
count per TU is less than 2, this can lead to unexpected empty TU
generation during compliance testing. For example, VIC 1 with a 1xHBR3
link configuration will average 1.98 pix/TU.

[HOW]
Calculate average pixel count per TU, and block 2 pixels per clock if
endpoint is a DPIA tunnel and pixel clock is low enough that we will
never require 2:1 ODM combine.

Cc: stable@vger.kernel.org # 6.6+
Reviewed-by: Wenjing Liu 
Acked-by: Hamza Mahfooz 
Signed-off-by: Michael Strauss 
Signed-off-by: Alex Deucher

drm/amd/display: change dram_clock_latency to 34us for dcn35

2024-06-19T18:17:25+00:00

[Why & How]
Current DRAM setting would cause underflow on customer platform.
Modify dram_clock_change_latency_us from 11.72 to 34.0 us as per recommendation from HW team

Reviewed-by: Nicholas Kazlauskas 
Acked-by: Zaeem Mohamed 
Signed-off-by: Paul Hsieh 
Tested-by: Daniel Wheeler 
Signed-off-by: Alex Deucher