Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] The patch silently introduces an undocumented change that incorrectly configures the `REG_DSI_ACTIVE_VSYNC_HPOS` register by assigning a vertical timing value (`vs_end`) to a horizontal position field. --
commit 2bb1060f4bf71f32baecff799ef80f36dc371942 Author: YİĞİTCAN KAVAKLI <[email protected]> drm/msm/dsi: make command and video mode configuration mutually exclusive This commit ensures explicit mutual exclusion between command and video modes by clearing the opposing enable bit in dsi_op_mode_config() to prevent hardware collisions. > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c > @@ -1094,7 +1094,9 @@ static void dsi_timing_setup(struct msm_dsi_host > *msm_host, bool is_bonded_dsi) > dsi_write(msm_host, REG_DSI_ACTIVE_HSYNC, > DSI_ACTIVE_HSYNC_START(hs_start) | > DSI_ACTIVE_HSYNC_END(hs_end)); > - dsi_write(msm_host, REG_DSI_ACTIVE_VSYNC_HPOS, 0); > + dsi_write(msm_host, REG_DSI_ACTIVE_VSYNC_HPOS, > + DSI_ACTIVE_VSYNC_HPOS_START(hs_start) | > + DSI_ACTIVE_VSYNC_HPOS_END(vs_end)); [Severity: High] Could this inadvertently corrupt the hardware timing configuration? It looks like vs_end, which is a vertical timing parameter, is being written into the DSI_ACTIVE_VSYNC_HPOS_END field, which expects a horizontal position. Because this happens unconditionally in dsi_timing_setup() for video-mode displays during the DSI host power-on sequence, this might lead to display tearing, sync failure, or a blank screen. Additionally, since it uses vs_end instead of hs_end, this appears to bypass the bonded DSI scaling logic where hs_end is halved, which might feed incorrect horizontal synchronization bounds to bonded configurations. Was this an accidental copy-paste inclusion? [ ... ] -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=8
