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

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

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.
>>
>> 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.

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    |