Message-ID: <8541055.T7Z3S40VBb@trenzalore>
Date: Wed, 29 Jan 2025 11:50:43 -0500
From: Detlev Casanova <detlev.casanova@...labora.com>
To: Piotr Oniszczuk <piotr.oniszczuk@...il.com>
Cc: linux-kernel@...r.kernel.org, Diederik de Haas <didi.debian@...ow.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Heiko Stuebner <heiko@...ech.de>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Dragan Simic <dsimic@...jaro.org>, Alexey Charkov <alchark@...il.com>,
 Cristian Ciocaltea <cristian.ciocaltea@...labora.com>,
 Andy Yan <andy.yan@...k-chips.com>, linux-media@...r.kernel.org,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-staging@...ts.linux.dev
Subject: Re: [PATCH 1/3] media: rockchip: Introduce the rkvdec2 driver

Hi Piotr,

On Wednesday, 29 January 2025 09:48:51 EST Piotr Oniszczuk wrote:
> > Wiadomość napisana przez Detlev Casanova <detlev.casanova@...labora.com> w
> > dniu 15 cze 2024, o godz. 21:44:
> > 
> > 
> > 
> > 
> > Yes, the vdpu34x decoder on rk356x socs should be supported by this driver
> > but I don't have boards to test that unfortunately.
> 
> Detlev,
> 
> Just FYI:
> 
> I done some tests of rkvdec2 on 6.12.11 on 3588, 3568 and 3566
> 
> For enabling rkvdec2 on 356x i:
> -add 356x compatible in rkvdec2.c
> -add dtsi nodes like this:
> https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.12/fi
> les/1078-arm64-dtsi-rockchip-rk356x-add-rkvdec2-video-decoder-nodes.patch
> 
> With this i can say:
> -on rk3588 i have some hevc 4k decoding perfectly but some others are
> failing -on rk3566/3568 only subset of 3588’s samples is decoded well. (but
> is works then works perfectly fine) -when not failing on 3588 sample fails
> on 356x - is see errors like:
> 
> [   95.666669] iova: 0x00000000f2e80000 already mapped to 0x0000000037378000
> cannot remap to phys: 0x000000002f8c0000 prot: 0x3 [   95.745082] iova:
> 0x00000000f2f46000 already mapped to 0x00000000372b6000 cannot remap to
> phys: 0x000000003a403000 prot: 0x3 [   95.822012] iova: 0x00000000f2ee6000
> already mapped to 0x0000000037126000 cannot remap to phys:
> 0x000000003a803000 prot: 0x3 [   95.896802] iova: 0x00000000f2ec6000
> already mapped to 0x0000000029fe6000 cannot remap to phys:
> 0x000000003a403000 prot: 0x3 turning-off iommu makes above errors disappear
> - but sample still fails.

I suppose you tested with my hevc branch, which is not really ready yet (Some 
ref frames will work but usually, it won't) Can you confirm which branch/commit 
you based your tests on ?

For the iommu, do you see those errors like that only on 356x or also on 3588 
? The hevc branch should have the iommu patches to fix that kind of things. 
(but note that hevc support is really new, so it may have bugs with buffer 
allocations)

> If anybody hints me for way/tool to analyse of playing/failing samples to
> catch: what encoding specifics makes given sample failing to decode  on
> rkvdec2 - i'll be more that happy to provide details… (doing simple
> mediainfo <file> shows no differences for me…)

Few features are supported for HEVC as of now:
 - No scanlist support (only default 16x16 blocks will work)
 - Long term reference frames are also not configured yet.
 - hevc 10 bits is also not supported yet

These are specific to the encoding and mediainfo won't really give you 
information on that, except maybe on the 10 bits format.

You can also checkout YUView (https://github.com/IENT/YUView) to get 
information on media files structure, but I have had issues with HEVC support 
lately.

Regards,

Detlev.

Powered by blists - more mailing lists