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

[Ming Qian(OSS)]

Hi Lucas,

On 2/3/2026 5:04 PM, Lucas Stach wrote:
> Hi,
> 
> Am Dienstag, dem 03.02.2026 um 15:13 +0800 schrieb Ming Qian(OSS):
>> 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.
>>
>> 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
> 
> You are driving the SoC out of spec. The datasheet clearly states that
> you need a 1000mV typical voltage for 600MHz VPU clock.
> 
> If you drive the SoC outside of those ratings it squarely depends on
> the individual SoC if it will tolerate the too low voltage without
> errors. Some SoCs land on the better side of PVT curve and will run at
> the higher speed without issues, but some will not and will exhibit
> random issues outside of the datasheet provided specs.
> 
> There isn't much to discuss here. The upstream DT for the i.MX8MQ runs
> all the clocks at a rate to meet the nominal drive voltage specs. If
> some peripheral clock does violate this, this is a bug not a feature to
> replicate in new patches.
> 
> Regards,
> Lucas

I agree with you, it's meaningless that test vpu with overdriver clock
frequency and nominal drive voltage.
We should focus on the overdrive mode at a frequency of 600 MHz and a
voltage of 1.0 V.

It is my mistake that not to adjust the voltage in this patch.

Regards,
Ming