[PATCH v6 2/2] arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588

[Nicolas Dufresne]

Le samedi 20 avril 2024 à 13:09 +0800, Jianfeng Liu a écrit :
> Hi Hugh,
> 
> Fri, 19 Apr 2024 18:28:01 +0100, Hugh Cole-Baker wrote:
> > The register range at 0xfdb50000 length 0x800 includes "VEPU121 core0" encoder
> > regs at offset 0 and "VDPU121" decoder regs at offset 0x400 (referring to the
> > TRM v1.0 Part 1, section 5.5.1). So I think the "rockchip,rk3588-vdpu121"
> > compatible isn't exactly correct to use for this entire device.
> 
> There are five vepu121 cores for jpeg encoding. And Emmanuel is doing work on
> them[1]. And at the moment the driver doesn’t yet support exposing these cores
> all as a single video node to userspace, so Emmanuel only exposes one single
> core.
> 
> > IMO "rockchip,rk3588-vpu121" would be more appropriate if including both the
> > decoder and encoder. It also raises the question of whether the decoder and
> > encoder should be modeled in DT as one device like on RK3399, or separate
> > devices. In the vendor DT [0] they are modeled as two devices but they share
> > clocks, resets, IOMMU, and a "rockchip,taskqueue-node" value.
> 
> Now we have 5 jpeg enc cores, one from 0xfdb50000 and other four from
> 0xfdba00000. I tried to add a decoding only core 0xfb50400, but that does not
> work. So the vpu should be defined as one node in devicetree for both encoder
> and decoder like rk3399.
> 
> This vpu121 should be exactly the same as the one in rk3399 which supports both
> encoding and decoding. But the current hantro driver has disabled h264 decoding

If its exactly the same combo as on rk3399, it have to be combined as they share
the same internal memory. You'll notice this strange thing about both being
60fps FHD seperately and 30fps FHD concurrently, this is why.

This leaves me with a feeling our understanding the of HW is far from perfect,
we should be extra careful and circle back to Rockchip (ping Kever, he'll
translate and CC the right person I suppose). Though, just exposing the decoder,
and ignoring the encoder seems fine in the short term. Userspace will miss-
behave though when we introduce the rkvdec2 decoder.

As we'd like to change from trivial time multiplexing to proper core scheduling
in the long term (for identical cores only), we have to keep in mind of the
possible grouping, which will need to be something deducible from DT. Please
keep that in mind when designing DT for this chip.

> since there is anthoer decoder rkvdec on rk3399. This vpu121 is the only
> decoder which supports h254 decoding on rk3588, so we can't just use the
> vpu_variant from rk3399. Maybe we can use rk3399_vpu_variant back when rkvdec2
> on rk3588 is supported by mainline kernel.
> 
> At the moment we can keep the compatible string same as the one from rk356x.
> Since there are already jpeg enc cores at 0xfdba0000, we can ignore the one at
> 0xfdb50000. When rkvdec2 is supported, I will change "rockchip,rk3588-vpu121"
> same as "rockchip,rk3399-vpu".
> 
> And I think changing "rockchip,rk3588-vdpu121" to "rockchip,rk3588-vpu121"
> should match the hardware correctly.
> 
> [1] https://lore.kernel.org/all/20240418141509.2485053-1-linkmauve@linkmauve.fr/
> 
> Best regards,
> Jianfeng