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

[Nicolas Dufresne]

Hey,

Le mercredi 28 octobre 2026 à 17:02 -0400, Nicolas Dufresne a écrit :
> Hi,
> 
> Le mardi 27 octobre 2026 à 16:20 +0100, valery bokov a écrit :
> > Questions:
> > 
> > - Does anyone know what 0x618 is? It’s outside the documented function
> > register range; I’d guess a cache, prefetch or bus-interface enable.
> > Does the BSP (mpp_rkvdec2 / rk3576 init) program it at power-up?
> > - Your FIX.md notes mainline throughput is well below the BSP’s (“4K
> > is ~30 fps vs the BSP’s ~112 fps”). Some of that gap may be this bit:
> > on our board, runs that come up with it clear are ~3x slower.
> > 
> > A fix would presumably set bit 1 of 0x618 in rkvdec_runtime_resume,
> > next to the priming. That needs the register mapped, either by
> > extending the “function” reg range in the DT or with a separate
> > mapping. I haven’t written that patch; I’d rather first hear whether
> > the bit is known and whether other bits in that area need setting too.
> 
> As you probably guessed by now, neither myself or Detlev have tested suspend
> yet. I did some search, as I don't have detailed registers description for this
> SoC, only the MPP code as reference.
> 
> You can certainly attempt some initial fix. The register block in question is
> [0] Vdpu383RegLlp_t, and the register is called SWREG6_LINK_MODE_EN. That makes
> it quite surprising it did read the link table at all with such name, but this
> is what I found.

As you mention off-list, I wasn't checking the right offsets.

			reg = <0x0 0x27b00000 0x0 0x100>,
			      <0x0 0x27b00100 0x0 0x500>,
			      <0x0 0x27b00600 0x0 0x100>;
			reg-names = "link", "function", "cache";

With 0x27b00618 falling into the cache registers (already described), which
totally make sense why performance are affected. Assuming a static cache
configuration is working well, I would configure it properly probe and then do
save / restore in suspend / resume. I would avoid doing just the one bit thing,
as it can bite later again.

Nicolas

> 
> So I think we should map the LLP completely, even if its mostly for future
> implementation. I was also checking the LLP driver downstream [1], and we seem 
> to be missing a lot in fact. It seems like starting from RK3576, the LLP
> capabilities have got much close to a command buffer.
> 
> regards,
> Nicolas
> 
> [0] https://github.com/rockchip-linux/mpp/blob/develop/mpp/hal/rkdec/inc/vdpu383_com.h
> [1] https://github.com/rockchip-linux/kernel/blob/develop-6.1/drivers/video/rockchip/mpp/mpp_rkvdec2_link.h
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20261029/8e4b132d/attachment.sig>