Am Donnerstag, dem 02.12.2021 um 10:54 -0800 schrieb Tim Harvey: > On Thu, Dec 2, 2021 at 4:29 AM Adam Ford <aford173@xxxxxxxxx> wrote: > > > > On Wed, Dec 1, 2021 at 10:17 PM Adam Ford <aford173@xxxxxxxxx> wrote: > > > > > > The i.MX8M has two Hantro video decoders, called G1 and G2 which appear > > > to be related to the video decoders used on the i.MX8MQ, but because of > > > how the Mini handles the power domains, the VPU driver does not need to > > > handle all the functions, so a new compatible flag is required. > > > > > > V3 is rebased from git://linuxtv.org/hverkuil/media_tree.git for-v5.17c > > > This branch has support for VP9. > > > > > > I set cma=512M, but this may not be enough memory as some tests appeard to run out of memory > > > > > > V3 of this series has several changes: > > > > > > Update imx8m_vpu_hw to add missing 'reg' reference names for G2 and include references to VP9 > > > Update device tree to remove IMX8MQ_VPU_RESET, remove some duplicate vpu clock parenting > > > Fix missing reg-names from vpu_g2 node. > > > Apply patch [1] to manage the power domains powering down. > > > [1] - https://lore.kernel.org/linux-arm-kernel/20211016210547.171717-1-marex@xxxxxxx/t/ > > > > > > With the above, the following Fluster scores are produced: > > > > > > G1: > > > ./fluster.py run -dGStreamer-H.264-V4L2SL-Gst1.0 > > > Ran 90/135 tests successfully in 74.406 secs > > > > > > ./fluster.py run -d GStreamer-VP8-V4L2SL-Gst1.0 > > > Ran 55/61 tests successfully in 8.080 secs > > > > > > G2: > > > ./fluster.py run -d GStreamer-VP9-V4L2SL-Gst1.0 > > > Ran 127/303 tests successfully in 203.873 secs > > > > > > Fluster and G-Streamer were both built from their respective git repos using their respective master/main branches. > > > > > > > I should note, that both interrupts appear to be triggering. > > > > # cat /proc/interrupts |grep codec > > 57: 13442 0 0 0 GICv3 39 Level > > 38300000.video-codec > > 58: 7815 0 0 0 GICv3 40 Level > > 38310000.video-codec > > > > Adam, > > On another thread you had let me know that you also removed the reset > from the pgc_vpumix power domain which does appear to resolve the > hang: > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi > b/arch/arm64/boot/dts/freescale/imx8mm.dtsi > index eb9dcd9d1a31..31710af544dc 100644 > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi > @@ -681,7 +681,6 @@ > clocks = <&clk > IMX8MM_CLK_VPU_DEC_ROOT>; > assigned-clocks = > <&clk IMX8MM_CLK_VPU_BUS>; > assigned-clock-parents > = <&clk IMX8MM_SYS_PLL1_800M>; > - resets = <&src > IMX8MQ_RESET_VPU_RESET>; > }; > > pgc_vpu_g1: power-domain@7 { > > That would make such a patch have a 'Fixes commit d39d4bb15310 > ("arm64: dts: imx8mm: add GPC node")' but of course that vpu domain > isn't active until your series so I'm not sure if we should send this > separate or squash it with "arm64: dts: imx8mm: Enable VPU-G1 and > VPU-G2". I'm also not clear if removing the reset requires some > further discussion with Lucas. > I'm fine with removing the reset when it fixes things. In normal operation the reset should already be triggered by the GPC itself via a hardware mechanism. We know that this doesn't work for the GPU reset on the i.MX8MM, so we have the ability for the driver to handle it by poking the SRC explicitly. Adding the reset to the VPU DT description wasn't done because I know that we need it, but more of a "I know that things are broken with the GPU domain, so better be safe than sorry with the VPU domain". My line of thought clearly was that it may not be needed, but it may prevent some issues in the long run. If it is _causing_ issues however, there is no need to discuss anything, just get rid of it. Regards, Lucas
