Hi Piotr, Le mercredi 29 janvier 2025 à 15:48 +0100, Piotr Oniszczuk a écrit : > > > Wiadomość napisana przez Detlev Casanova <detlev.casanova@xxxxxxxxxxxxx> 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/files/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. > > 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…) Not sure where it is saved, but we have a mainline kernel with the MPP services driver up-levelled (you can probably do that yourself, its not that hard). You have to have the MPP library and probably the gstreamer plugins from rockchip installed. The general approach is to dump the register prior to every codec trigger, and compare. Appart from memory addresses, pretty much all register should be identical for decoders. If you happen to have a stream that fails on MPP, simply report that to them, they are generally fast on fixing their own stuff. And we can then used that knowledge to fix our implementation. As for most codec, when working with larger group of developpers, its better to start with getting the ITU conformance tests passing. Once we reach an excellant score then we can start looking at specific streams. The benefit is that ITU conformance can be run with fluster which removes a lot of possible human errors. Nicolas p.s. Jonas Karlman has been working on IOMMU fixes and resets that helps recover from faults that are sticky in the dedicated IOMMUs despite the HW self reset mechanism.
