On Wed, Jul 22, 2026 at 06:54:56PM +0800, Yongxing Mou wrote: > > > On 7/22/2026 2:47 AM, Dmitry Baryshkov wrote: > > 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. > > > Sure. Will update it next version.
I needed to pick up your patches, so I ended up looking at the issue. See https://lore.kernel.org/dri-devel/20260722-drm-msm-display-interface-v1-0-368c10fe6...@oss.qualcomm.com/T/#t -- With best wishes Dmitry
