On 7/22/2026 9:11 PM, Dmitry Baryshkov wrote:
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
Thanks for the series. With modeset() moved into pre_enable(), this
issue is no longer present.
Do I still need to send a v9 to address the comments on patch 6/10?
If I send a new version, should I include the first two patches as well,
or only resend the remaining patches that still need changes?
