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

From: Simon Wright <simon@symple.nz>
To: Nicolas Dufresne <nicolas@ndufresne.ca>,
	Detlev Casanova <detlev.casanova@collabora.com>,
	linux-media@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Subject: Re: [BUG] rkvdec-vdpu383-h264: wrong pixels at horizontal de-blocking edges y=4 and y=12
Date: Tue, 9 Jun 2026 20:33:38 +1200	[thread overview]
Message-ID: <34662f2d-cdf9-4ce8-a618-12a0f64cd03a@symple.nz> (raw)
In-Reply-To: <25a232dca0236788c75231c43ee8a01741148c37.camel@ndufresne.ca>

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

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip