| 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
| ||
|
Message-ID: <cd07dc6e-1f19-4a59-8ee5-81a36d51bf1c@oss.nxp.com> Date: Tue, 3 Feb 2026 16:53:24 +0800 From: "Ming Qian(OSS)" <ming.qian@....nxp.com> To: Marco Felsch <m.felsch@...gutronix.de> Cc: Nicolas Dufresne <nicolas@...fresne.ca>, linux-media@...r.kernel.org, imx@...ts.linux.dev, ulf.hansson@...aro.org, Frank.li@....com, peng.fan@....com, festevam@...il.com, robh@...nel.org, benjamin.gaignard@...labora.com, sebastian.fricke@...labora.com, linux-imx@....com, devicetree@...r.kernel.org, conor+dt@...nel.org, p.zabel@...gutronix.de, linux-pm@...r.kernel.org, s.hauer@...gutronix.de, mchehab@...nel.org, linux-arm-kernel@...ts.infradead.org, eagle.zhou@....com, linux-kernel@...r.kernel.org, kernel@...gutronix.de, hverkuil-cisco@...all.nl, krzk+dt@...nel.org, shawnguo@...nel.org, l.stach@...gutronix.de Subject: Re: [PATCH] arm64: dts: imx8mq: Restore VPU G2 clock to 600MHz for 4K60fps decoding Hi Marco, On 2/3/2026 4:31 PM, Marco Felsch wrote: > [You don't often get email from m.felsch@...gutronix.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 |
Powered by blists - more mailing lists