On Mon, Jul 20, 2026 at 06:33:16AM +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s)
> to consider:
>
> New issues:
> - [High] Moving mode state updates to `.atomic_enable` causes the DPU encoder
> to read stale wide bus configuration.
>
> Pre-existing issues:
> - [High] `mode_valid` incorrectly evaluates wide bus availability based on
> the currently active mode's state rather than the candidate mode, causing
> valid modes to be rejected.
> --
>
> > @@ -1386,7 +1406,7 @@ void msm_dp_bridge_atomic_enable(struct drm_bridge
> > *drm_bridge,
> > if (msm_dp_display->link->sink_count == 0)
> > return;
> >
> > - rc = msm_dp_display_set_mode(dp, &msm_dp_display->msm_dp_mode);
> > + rc = msm_dp_display_set_mode(dp, &crtc_state->adjusted_mode,
> > msm_dp_display->panel);
> > if (rc) {
> > DRM_ERROR("Failed to perform a mode set, rc=%d\n", rc);
> > return;
>
> [Severity: High]
> Does moving this mode setup into .atomic_enable() cause the DPU encoder
> to read a stale wide bus configuration?
>
> In the DRM atomic commit flow, the encoder's .atomic_enable() (which executes
> dpu_encoder_virt_atomic_enable()) is called before the bridge's
> .atomic_enable().
>
> Because msm_dp_display_set_mode() updates the format state
> (msm_dp_panel->msm_dp_mode.out_fmt_is_yuv_420), the DPU encoder will query
> msm_dp_wide_bus_available() before this new mode's format has been stored.
>
> Won't this cause the hardware to be programmed using the wide bus state from
> the previously active mode, potentially causing display corruption or a blank
> screen when switching between RGB and YUV420?
Indeed, both look like an issue. Please add a patch before this one,
adding drm_display_mode to the msm_dp_wide_bus_available() call. It will
solve both issues.
--
With best wishes
Dmitry
