Re: [PATCH] arm64: dts: imx8mq: Restore VPU G2 clock to 600MHz for 4K60fps decoding
From: Ming Qian(OSS)
Date: Tue Feb 03 2026 - 21:13:30 EST
Hi Nicolas,
On 2/3/2026 11:40 PM, Nicolas Dufresne wrote:
Le mardi 03 février 2026 à 16:53 +0800, Ming Qian(OSS) a écrit :
Hi Marco,
On 2/3/2026 4:31 PM, Marco Felsch wrote:
[You don't often get email from m.felsch@xxxxxxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Hi,
sorry for jumping in.
On 26-02-03, Ming Qian(OSS) wrote:
Hi Nicolas,
On 2/3/2026 3:12 AM, Nicolas Dufresne wrote:
Hi,
Le lundi 02 février 2026 à 13:44 -0500, Nicolas Dufresne a écrit :
This doesn't sound like just a VPU issue; it's related to the display or
DDR.
If not displayed, do the fluster test cases yield different results at
600MHz and 300MHz?
Didn't you run these tests before sending ? I can try again, but in my
internal
notes, I wrote:
> Tested that, and everything becomes unstable
That was before I figure-out the IRQ handler didn't handle exception bits that
didn't stop the decoder (or dry IRQ, which strangely is common from the G2).
Ran some fluster tests now. With this patch the results is not consistent
anymore. Then I ran it with weston being started, and in the middle of the test
the display turned black. Matches my past observation. We did reproduce this on
BSP kernel too. When the display goes black, the recent hantro drivers reports:
[ 827.581586] hantro-vpu 38310000.video-codec: frame decode timed out.
[ 827.720201] hantro-vpu 38310000.video-codec: not all macroblocks were
decoded.
I have local patches to reduce the cascade of errors, so it likely survived
longer then last time. I will send these patches soon. The "not all macroblocks
were decoded." is triggered by a bit in the status register that is not
documented in NXP TRM. I found that bit in some VC8000D documentation (the
sucessor of G2). I concluded it was the same meaning after looking at the failed
buffer visually, it is indeed missing couple of macroblocks near th end. Each
time we see this error, the DCSS gives up and turn either black, or sometimes
other color. The second case has been tracked to a DCSS Scaler underrun, the
first we don't know.
Fluster command ran (two threads, never completes):
./fluster.py run -d GStreamer-H.265-V4L2SL-Gst1.0 -ts JCT-VC-HEVC_V1 -j2 -t90
Nicolas
My test results for fluster differ from yours.
On my end, the results for JCT-VC-HEVC_V1 are consistent at both 300MHz and
600MHz.
And results remained unchanged after multiple tests.
After more testing, the fluster test is stable for NV12/NV15 tiled output for me
too. I'm running the tests with linear NV12/P010, which imply an extra set of
buffer. I will check if I can give you a easy way to test the linear formats. I
also have couple of streams that systematically breaks at specific spot (high
complexity scenes) with the provided patch. As most licensed content, this is
not sharable as-is. I will try and see if I can find a way to share something.
That would be very helpful. Thank you very much.
I'm not sure what caused the differences between us.
Once it comes to system stability, you need to ensure that your
bootstack is aligned e.g. same TF-A version and sometimes same
bootloader since there might be workarounds/erratum applied by the boot
firmware.
Regards,
Marco
Thanks for the reminder, and I agree.
I think we need to align our board environment first.
I do likely have slightly different bootchain, and of course all the HDMI
component are downstream, but I can't really isolate the dramatic issue of this
overclock without a display component of some sort. Its a huge differentiator in
the bandwidth consumption which is the main challenge on this SoC so far. 10bit
videos makes things a lot worse fwiw.
We did review latest IMX vendor firmware package and can confirm we are running
the latest memory training blob and HDMI firmware.
Nicolas
Since the datasheet clearly states that the VPU G2 requires a voltage
increase to 1.0V to run at 600MHz, (I thought it was already like this,
but it actually wasn't.)
I think we can align our test conditions to this.
I will increase the G2 voltage in V2.
Regards,
Ming
Regards,
Ming
Below are my test results:
600Mhz, 0.9v
cat /sys/kernel/debug/regulator/regulator_summary |grep SW1C
SW1C 0 1 0 unknown 900mV 0mA
825mV 1100mV
cat /sys/kernel/debug/clk/vpu_g2/clk_rate
600000000
./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2SL-Gst1.0 -j2 -t
90
****************************************************************************************************
Running test suite JCT-VC-HEVC_V1 with decoder
GStreamer-H.265-V4L2SL-Gst1.0
Using 2 parallel job(s)
****************************************************************************************************
Ran 139/147 tests successfully in 505.434 secs
Ran 139/147 tests successfully in 505.350 secs
Ran 139/147 tests successfully in 507.540 secs
600Mhz, 1.0v
cat /sys/kernel/debug/regulator/regulator_summary |grep SW1C
SW1C 0 1 0 unknown 1000mV 0mA
825mV 1100mV
cat /sys/kernel/debug/clk/vpu_g2/clk_rate
600000000
./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2SL-Gst1.0 -j2 -t
90
Ran 139/147 tests successfully in 506.901 secs
300Mhz, 0.9v
cat /sys/kernel/debug/regulator/regulator_summary |grep SW1C
SW1C 0 1 0 unknown 900mV 0mA
825mV 1100mV
cat /sys/kernel/debug/clk/vpu_g2/clk_rate
300000000
./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2SL-Gst1.0 -j2 -t
90
Ran 139/147 tests successfully in 506.063 secs
Downstream v4l2 driver
cat /sys/kernel/debug/regulator/regulator_summary |grep SW1C
SW1C 0 2 0 unknown 1000mV 0mA
825mV 1100mV
cat /sys/kernel/debug/clk/vpu_g2/clk_rate
600000000
./fluster.py run -ts JCT-VC-HEVC_V1 -d GStreamer-H.265-V4L2-Gst1.0 -j2 -t
90
Ran 136/147 tests successfully in 460.435 secs
Regards,
Ming
--
#gernperDu
#CallMeByMyFirstName
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |