Filed this as armbian/build#10551 and was (reasonably) pointed here instead, since it's a kernel-code observation rather than a build-framework bug. Posting for the record — this is a question about the code, not a bug report.

Where: drivers/gpu/drm/rockchip/rockchip_drm_vop2.c — identical across Rockchip BSP 6.1, ubuntu-rockchip, and Armbian rk35xx-vendor-6.1 (carried unpatched).

rk3568_vop2_cfg_done() waits for the layer-select latch to take effect when it changes:

 

old_layer_sel_val = vop2_readl(vop2, layer_sel_offset);
cfg_layer_sel_val = vop2->regsbak[layer_sel_offset >> 2];
...
vop2_writel(vop2, 0, val);
/* Make sure the layer sel is take effect when it's updated. */
if (old_layer_sel_val != cfg_layer_sel_val) {
        vp->layer_sel_update = true;
        vop2_wait_for_fs_by_done_bit_status(vp);
}

rk3588_vop2_cfg_done() has no equivalent — it writes cfg_done (with masked write-enable bits) and returns:

 

val = RK3568_VOP2_GLB_CFG_DONE_EN | BIT(vp->id) | (BIT(vp->id) << 16);
if (vcstate->splice_mode)
        val |= BIT(vp_data->splice_vp_id) | (BIT(vp_data->splice_vp_id) << 16);
...
vop2_writel(vop2, 0, val);

Why it may be intentional: on RK3568 the converge sits next to a documented workaround for its un-masked cfg-done bits (back-to-back writes can override a not-yet-latched one). RK3588 writes masked done bits (BIT(vp->id) << 16), so each VP's cfg_done is atomic and that override race can't occur — i.e. RK3588 may simply not need it. Just asking whether anyone knows if the omission is by design vs. carried over.

For transparency: I mirrored the rk3568 converge into the rk3588 path as a test — harmless but inert. The 4K browser flicker I was chasing turned out to be userspace (Chromium/ANGLE compositing; zero VOP2 activity at a stable mode; Firefox clean on the same stack), so I'm not claiming this asymmetry causes any user-visible bug. Related but distinct: multi-output layer_sel tearing is already fixed in mainline (Ciocaltea's "Fix layer cfg done timeout on multi-output setups" series, merged with Andy Yan's review) — mainline restructured this path entirely, so the question only applies to the BSP.

Every mode change also logs this pair, reproducibly, with no visible impact — noting it in case it points at PD accounting:

 

[drm:vop2_power_domain_off_by_disabled_vp] *ERROR* unexpected power on pd6
[drm:vop2_power_domain_off_by_disabled_vp] *ERROR* unexpected power on pd5

If anyone from the Rockchip side (or anyone who's traced this) knows the history, I'd love the answer. Otherwise — consider this documentation for the next person who greps cfg_done.

On the "intentional?" question: your mirroring experiment is the strongest evidence I have seen that RK3588 does not need the
converge. If the layer_sel latch race existed on the rk3588 path,back-porting the rk3568 wait would either fix visible tearing or
change timing observably. It did neither — inert, as you said.Combined with the masked cfg-done bits (BIT(vp->id) << 16) making
each VP's done signal atomic, my working assumption is also "by design", and it would be interesting to hear from the Rockchip side
whether the rk3588 path was deliberately simplified during bring-up.We reproduce the PD accounting pair on every mode change as well:

    [drm:vop2_power_domain_off_by_disabled_vp] *ERROR* unexpected power on pd6

    [drm:vop2_power_domain_off_by_disabled_vp] *ERROR* unexpected power on pd5

On our side it is tied to VP enable/disable ordering during hotplug and dual-HDMI mode switching (EM3588: 2x HDMI 2.1 + DP 1.4 + 2x
MIPI-DSI). One note for the industrial angle: in fanless enclosures we watch PD state indirectly through current draw, and these
"unexpected power on" events make power telemetry look noisy even though the behaviour is benign. In our data the domains stay latched
for a few ms and it does not move the thermal budget — but it would be worth quantifying if anyone is measuring per-domain power on
RK3588.

On the mainline relationship: since Ciocaltea's multi-output series restructured the cfg_done path, the BSP-only question stands. There
is also a related thread on dri-devel where Igor Paunovic is scaling the VOP2 AXI clock (v2 series); in our on-list reply we noted that
commit_tail ordering can affect power-domain handoffs on multi-CRTC configs. If that change lands, it may be worth re-testing whether
the pd5/pd6 errors shift on the BSP side as well.

Thanks — the EM3588 cross-reproduction is valuable: same pd5/pd6 pair on RK3588S single-head mode changes here and your multi-head hotplug there, so it's the atomic_disable path itself rather than anything board- or head-count-specific.

On your "domains stay latched for a few ms" telemetry — I think the BSP source explains that exactly. The driver's own comment on vop2_power_domain_off() says the power-down takes effect by vsync: it's a shadow write that latches at the next frame boundary, while power-domain on is immediate. vop2_power_domain_off_by_disabled_vp() runs its check before that latch lands, sees the domain still powered, and prints "unexpected power on" — benign, exactly as you observe. It also makes your few-ms figure predictable: the latched window should be roughly one refresh period. If your current-draw monitoring can compare mode changes at 60 Hz vs 120 Hz, the blip should shrink from ~16.7 ms toward ~8.3 ms — that would confirm the mechanism from telemetry alone, no kernel instrumentation needed.
 

For per-domain power: nothing on the Orange Pi 5B exposes per-domain rails, so the best I could contribute is an upper bound from total board draw during a mode-change storm. Your enclosure telemetry is better positioned for the real measurement.

Agreed on the Paunovic series — the commit_tail-ordering note is interesting precisely because PD-off rides the vsync latch: anything that reorders commits relative to frame boundaries could plausibly move these prints. Worth re-testing on the BSP side if/when it lands, as you say.