Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] msm_dp_bridge_mode_valid() evaluates wide bus availability using the previously committed mode's YUV420 state rather than the state of the mode being validated. This causes valid high-bandwidth RGB modes to be incorrectly rejected if a YUV420 mode was previously committed. -- --- Patch [2]: [PATCH v9 02/14] drm/msm/dp: drop deprecated .mode_set() and use .atomic_pre_enable --- commit 9ae2d320a8d0fa2507140b418f1dff372f81454c Author: Yongxing Mou <[email protected]> drm/msm/dp: drop deprecated .mode_set() and use .atomic_pre_enable The bridge .mode_set() callback is deprecated. Remove it and move the mode setup logic to .atomic_pre_enable(), where the adjusted_mode is available from the atomic CRTC state. Drop msm_dp_mode from msm_dp_display_private and store the mode directly in the panel. > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c > b/drivers/gpu/drm/msm/dp/dp_display.c > index bce165bac106b..c106aabda588e 100644 > --- a/drivers/gpu/drm/msm/dp/dp_display.c > +++ b/drivers/gpu/drm/msm/dp/dp_display.c [ ... ] > @@ -1309,7 +1325,7 @@ bool msm_dp_wide_bus_available(const struct msm_dp > *msm_dp_display) > > dp = container_of(msm_dp_display, struct msm_dp_display_private, > msm_dp_display); > > - if (dp->msm_dp_mode.out_fmt_is_yuv_420) > + if (dp->panel->msm_dp_mode.out_fmt_is_yuv_420) [Severity: High] This is a pre-existing issue, but does evaluating wide bus availability using the previously committed mode's YUV420 state cause valid high-bandwidth RGB modes to be incorrectly rejected? When a user sets a YUV420 mode, out_fmt_is_yuv_420 is set to true during atomic_pre_enable. If the driver later probes or validates modes from EDID, msm_dp_bridge_mode_valid() calls msm_dp_wide_bus_available(): msm_dp_bridge_mode_valid() if (msm_dp_wide_bus_available(dp)) mode_pclk_khz /= 2; This function then reads the stale out_fmt_is_yuv_420 flag and returns false. Consequently, the pixel clock for high-bandwidth RGB modes is not halved, causing them to exceed the maximum pixel clock and be rejected. While this patch addresses a similar state leak for the DPU encoder by moving the mode state update to atomic_pre_enable, it seems mode validation (which runs before atomic_pre_enable) still relies on this stale state. > return false; > > return dp->wide_bus_supported; -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
