[BUG] rkvdec-vdpu383-h264: wrong pixels at horizontal de-blocking edges y=4 and y=12

[Simon Wright]

Hi Piotr,

Short version: the in-tree port didn't actually have the warmup running (it needs a
probe-time buffer alloc + a pm_runtime_resume hook, not just the decode code). Rather
than pick that apart, here's a clean patch that wires it properly - and I've now
validated it on hardware.

The patch is self-contained and needs no devicetree change (mainline already maps the
"link" register bank it uses); git apply-clean on 7.0 and 7.1-rc7:

    https://github.com/SympleNZ/rkvdec-vdpu383-h264-bug/tree/master/fix

    git apply fix/0001-media-rkvdec-prime-VDPU383-deblock-warmup-rk3576.patch

It adds one file (rkvdec-rk3576-workaround.c) plus a probe + pm_runtime_resume hook,
scoped to the RK3576/VDPU383 variant. Confirm it's actually active before judging it:

    dmesg | grep -i "deblock-priming"
    # expect: "RK3576 H.264 deblock-priming workaround enabled"

I validated it on the two RK3576 boards here: on a NanoPi R76S the warmup takes BBB
from ~18% of decodes corrupt to 0/40; on an ArmSoM Sige5 the unpatched HW decode is
100% corrupt, and the corruption looks exactly like the photo you shared. Before/after
captures:

    https://github.com/SympleNZ/rkvdec-vdpu383-h264-bug#what-it-looks-like

Your board spread (nanopi M5/R76S, rock4d 20-40%) and ours (R76S 18%, Sige5 100%) are the
same timing-marginal race the priming settles, so I'd expect it to clear on your
boards once it's firing.

If you get it built, a quick "builds + the line shows up", and a Tested-by across your
devices, would strengthen this for upstream - multi-board confirmation on a hardware
workaround is exactly what the maintainers want.

Regards,
Simon