From: Fangzhi Zuo Jerry.Zuo@amd.com
[ Upstream commit 146a4429b5674b7520a96aea34233949731c6086 ]
[why] In the mode validation, mst dsc is considered for bw calculation after common dsc config is determined. Currently it considered common dsc config is found if max and min target bpp are non zero which is not accurate. Invalid max and min target bpp values would not get max_kbps and min_kbps calculated, leading to falsefully pass a mode that does not have valid dsc parameters available.
[how] Use the return value of decide_dsc_bandwidth_range() to determine whether valid dsc common config is found or not. Prune out modes that do not have valid common dsc config determined.
Reviewed-by: Wayne Lin wayne.lin@amd.com Signed-off-by: Fangzhi Zuo Jerry.Zuo@amd.com Tested-by: Daniel Wheeler daniel.wheeler@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org ---
**YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Analysis of the Bug **1. Nature of the Issue** This commit fixes a clear logic bug in the DSC (Display Stream Compression) mode validation for MST (Multi-Stream Transport) displays. The problem is in the `is_dsc_common_config_possible()` function in `drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c`. **2. The Bug Details** The current implementation has a flawed detection mechanism for valid DSC configurations: ```c // OLD (buggy) code: dc_dsc_compute_bandwidth_range(..., bw_range); return bw_range->max_target_bpp_x16 && bw_range->min_target_bpp_x16; ``` The bug is that it only checks if `max_target_bpp_x16` and `min_target_bpp_x16` are non-zero, but these values might be set even when the DSC configuration is invalid. The function `dc_dsc_compute_bandwidth_range()` returns a boolean indicating whether a valid DSC configuration was actually found, but this return value was being ignored. **3. The Fix** The fix correctly uses the return value from `dc_dsc_compute_bandwidth_range()`: ```c // NEW (fixed) code: bool is_dsc_possible; is_dsc_possible = dc_dsc_compute_bandwidth_range(..., bw_range); return is_dsc_possible; ``` ## Impact Analysis **1. User- Visible Impact** - **Before**: The driver could incorrectly approve display modes that don't have valid DSC parameters, leading to display failures or poor visual quality - **After**: Only modes with valid DSC configurations are approved, preventing display issues **2. Risk Assessment** - **Risk of Regression**: Very low - the change makes the validation more restrictive, only rejecting modes that shouldn't have been approved - **Scope**: Limited to AMD display driver DSC MST functionality - **Size**: Very small, contained change (3 lines of code) ## Comparison with Similar Commits All the provided similar commits were marked as "Backport Status: NO" because they were: 1. Feature additions (enabling new DSC functionality) 2. Policy improvements (changing compression ratios) 3. New algorithm implementations (fair share algorithms) 4. API extensions (adding DSC support to PBN calculations) This commit is fundamentally different - it's a **pure bug fix** that corrects faulty logic without adding new features. ## Stable Tree Suitability This commit meets all stable tree criteria: ✅ **Fixes important bugs**: Yes - prevents display mode validation failures ✅ **Small and contained**: Yes - only 3 lines changed in one function ✅ **No architectural changes**: Yes - uses existing API correctly ✅ **Minimal regression risk**: Yes - makes validation more conservative ✅ **Clear side effects**: Yes - only rejects invalid modes that were incorrectly approved ✅ **Affects critical subsystem**: Yes - display functionality is critical for users ## Technical Verification From examining the kernel code, I confirmed that `dc_dsc_compute_bandwidth_range()` performs comprehensive validation including: 1. Intersection of DSC capabilities between source and sink 2. DSC configuration setup with timing constraints 3. Bandwidth range calculation with `decide_dsc_bandwidth_range()` The old code ignored these validation results and only checked if some bandwidth values were set, which could happen even with invalid configurations. This is a textbook stable tree candidate: a small, low-risk fix for a clear logic error that affects user-visible functionality.
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c index 2698e5c74ddfd..66c1905102a5d 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c @@ -1620,16 +1620,17 @@ static bool is_dsc_common_config_possible(struct dc_stream_state *stream, struct dc_dsc_bw_range *bw_range) { struct dc_dsc_policy dsc_policy = {0}; + bool is_dsc_possible;
dc_dsc_get_policy_for_timing(&stream->timing, 0, &dsc_policy, dc_link_get_highest_encoding_format(stream->link)); - dc_dsc_compute_bandwidth_range(stream->sink->ctx->dc->res_pool->dscs[0], - stream->sink->ctx->dc->debug.dsc_min_slice_height_override, - dsc_policy.min_target_bpp * 16, - dsc_policy.max_target_bpp * 16, - &stream->sink->dsc_caps.dsc_dec_caps, - &stream->timing, dc_link_get_highest_encoding_format(stream->link), bw_range); - - return bw_range->max_target_bpp_x16 && bw_range->min_target_bpp_x16; + is_dsc_possible = dc_dsc_compute_bandwidth_range(stream->sink->ctx->dc->res_pool->dscs[0], + stream->sink->ctx->dc->debug.dsc_min_slice_height_override, + dsc_policy.min_target_bpp * 16, + dsc_policy.max_target_bpp * 16, + &stream->sink->dsc_caps.dsc_dec_caps, + &stream->timing, dc_link_get_highest_encoding_format(stream->link), bw_range); + + return is_dsc_possible; }
enum dc_status dm_dp_mst_is_port_support_mode(