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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20602b86caa7166a5ac8eb75d38be07c7d7bb264.camel@pengutronix.de>
Date: Tue, 03 Feb 2026 10:04:25 +0100
From: Lucas Stach <l.stach@...gutronix.de>
To: "Ming Qian(OSS)" <ming.qian@....nxp.com>, 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,

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