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

["Ming Qian(OSS)" <ming.qian@oss.nxp.com>]

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@pengutronix.de. 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    |