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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ac798f2a-b47e-4d8b-b09e-7377951f6df7@oss.nxp.com>
Date: Tue, 3 Feb 2026 17:33:24 +0800
From: "Ming Qian(OSS)" <ming.qian@....nxp.com>
To: Lucas Stach <l.stach@...gutronix.de>,
 Nicolas Dufresne <nicolas@...fresne.ca>, linux-media@...r.kernel.org
Cc: mchehab@...nel.org, hverkuil-cisco@...all.nl,
 benjamin.gaignard@...labora.com, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, p.zabel@...gutronix.de, sebastian.fricke@...labora.com,
 shawnguo@...nel.org, ulf.hansson@...aro.org, s.hauer@...gutronix.de,
 kernel@...gutronix.de, festevam@...il.com, linux-imx@....com,
 Frank.li@....com, peng.fan@....com, eagle.zhou@....com,
 devicetree@...r.kernel.org, imx@...ts.linux.dev, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] arm64: dts: imx8mq: Restore VPU G2 clock to 600MHz for
 4K60fps decoding

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