20:48 <Kwiboo> inode: for hantro testing in mainline staging you can use my ffmpeg branch at https://github.com/FFmpeg/FFmpeg/compare/master...Kwiboo:v4l2-request-hwaccel-master, it adds required bits for v4l2 request api decoding, it should work with mpv or kodi-gbm

20:49 <inode> cool, thanks Kwiboo

20:49 <Kwiboo> build ffmpeg with: --enable-v4l2-request --enable-libdrm --enable-libudev to enable the drm hwaccel

20:50 <Kwiboo> you may need one or two media-tree patch from 5.5 to build if you target 5.4.x

20:55 <inode> Kwiboo: thanks a lot. i realized since i asked yesterday that there is a bunch of rk322x specific initialization that i will need to borrow from develop-4.4's vpu-service first - although i was hopeful at first that riding on rk3288 support alone would have been enough

20:57 <Kwiboo> mainline should not use any vpu-service or mpp, I think it should be rather easy to add rk322x support to the hantro vpu driver, adding support for rk3328 was very easy

20:59 <Kwiboo> btw, if you are doing testing on rk322x, would you mind testing https://github.com/Kwiboo/linux-rockchip/compare/next-20200108...next-20200108-inno-hdmi-phy on a rk322x, it adds support for all supported HDMI modes and rates on rk3328, and should hopefully also help/imporve on rk322x

21:02 <Kwiboo> https://github.com/rockchip-linux/mpp/blob/release/osal/mpp_platform.cpp#L68 <<-- seems to indicate that rk322x share same vpu2 and rkvdec as rk3328 and rk3399, so it should be possible to piggy back on the rk3399 support in hantro driver

21:05 <anarsoul> Kwiboo: out of curiosity what's the status of ffmpeg patches? Are they close to being merged?

21:06 <Kwiboo> inode: for experimental h264 vpu2 support in hantro driver I have https://github.com/Kwiboo/linux-rockchip/compare/v4l2-5.4-from-5.5-v5.4...v4l2-5.4-work-in-progress-v5.4, it adds support for field encoded decoding and h264 vpu2 support

21:08 <Kwiboo> anarsoul: we are waiting on a stable uapi for the v4l2 controls needed by stateless decoing, they are all in private kernel headers at the moment (ffmpeg patchset contains a copy of these header files)

21:09 <anarsoul> so it's not stabilized yet? :(

21:14 <Kwiboo> not fully, the v4l2 request api is in stable uapi, but the controls for codec info is in private headers for now, the mpeg2 and h264 ctrls should be rather feature complete for cedrus and hantro needs

21:14 <anarsoul> why not to version it and mark as stable?

21:15 <anarsoul> that's what majority of gpu drivers do

21:15 <anarsoul> e.g. lima is currently at 1.0, but as soon as Qiang merges support for dynamic heap it'll be 1.1

21:16 <anarsoul> which is backwards compatible with 1.0

21:21 <Kwiboo> I do not think there is good support for versioning of v4l2 ctrls, https://lore.kernel.org/linux-media/311a152e-b773-76d6-a17e-86112b583179@xs4all.nl/ <<-- has some actions on what is needed to move drivers/controls out of staging

21:22 <inode> Kwiboo: sure no problem, these changes correspond to https://patchwork.kernel.org/project/linux-rockchip/list/?series=225649 ?

21:27 <Kwiboo> inode: correct, same patches, I am planning on spliting that series into two parts, phy and device-tree+drm, since there is no dependency between them

21:37 <Kwiboo> inode: for rk322x the vop clock rate may need to be raised similar to rk3328 for proper 4k scanout, and I also suspect something like https://github.com/rockchip-linux/kernel/commit/595ad3137e0b4a27fbc9f6a092d71e70a04a01a2 may be needed for some rk322x variants