Re: [PATCH] arm64: dts: imx8mq: Restore VPU G2 clock to 600MHz for 4K60fps decoding

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 :

quoted

quoted

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.

I'm not sure what caused the differences between us.

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