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

[Simon Wright]

Hi Nicolas,

(Replying to both your notes.)

On the cleaner implementation:

> on the first frame after resume, we'd prepend the workaround decode
> operation to the TBL [...] cleared on the workaround decode IRQ

That's nicer than what I have. For reference, the warmup here already runs as a
minimal link/CCU submit (its own descriptor + register set on the link bank,
separate from the single-shot decode path), which I currently poll. I tried just
arming the link IRQ on that standalone submit, and it never fires - the warmup
only raises the status register, no interrupt - so it does look like it needs to
ride a real link-table task, as you suggest, to be reaped by IRQ. Happy to test
any version on the RK3576 boards here.

On whether it's really a HW bug:

> we know from past mpp workaround that they don't always imply a HW bug

Fair. I did try to rule out the most likely "masking a simpler issue"
candidate - the filterd RCB (slot 6) data state, per your other note - and it's
content-independent:

- Dumping slot 6 after each decode: its content - including the meaningful
  deblock-context head, not just an uninitialised tail - is non-deterministic
  run to run even across byte-identical good decodes. So there's no stable
  "working" RCB state to compare a bad run against; good and bad runs both span
  unrelated contents with no shared signature.
- Zero-initialising slot 6 before every decode doesn't change the failure rate
  (the allocator already zalloc-zeroes it); a 0xAA sentinel is overwritten by
  the HW rather than read into the output.

So it points to the HW racing on its own deblock-context handling rather than
reading stale buffer data. I couldn't reduce it to a register / RCB / clock /
gating difference vs MPP either, which is what pushed me to the power-up priming. 
I can't claim it isn't masking something deeper, but it isn't the RCB-data case.

Regards,
Simon