Re: [PATCH v7 7/7] drm/verisilicon: fix DC8200 primary plane disable clearing FB_EN

[Joey Lu <a0987203069@gmail.com>]

Icenowy Zheng 於 2026/9/21 下午 03:30 寫道:
> Maybe it's better to just make it the 2nd patch in this patchset, just
> after the binding change.
>
> Waiting for something into drm-misc-fixes again will need another fixes
> pull and another RC back merge, which can consume weeks and miss the
> current merging window.
>
> In addition, it's possible that `drm/verisilicon: introduce per-variant
> hardware ops table` also gets backported for a more clean primary plane
> atomic_update disabling fix.
Understood. I'll fold the FB_EN fix in as patch 2, right after the
dt-bindings patch, targeting the current vs_primary_plane.c directly,
so the ops-table patch just carries the already-corrected code forward
into vs_dc8200.c. Agreed that's faster than round-tripping.

On primary_plane_disable_ex - I'll keep the "_ex" suffix. DC8200 still
has a real per-variant operation there (clearing FB_EN + commit), while
DC8000 leaves it NULL and does nothing, so the suffix still reflects
an actual per-variant difference, not just structure introduced by the
refactor.

While testing the cursor plane, I found the same class of bug there:
the disable register write was being triggered from the plane's
atomic_update() invisible-branch using the old plane state to look up
the CRTC/output, which can be stale or NULL on a plane's very first
commit if it's already invisible then. I've fixed it locally by having
atomic_update() derive the CRTC/output from the state it already holds
before checking visibility, instead of falling through to the
old-state-based disable path. Just flagging it here for now -
vs_cursor_plane.c isn't touched by any of my patches.

Thanks.