| 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: <39e9729c-c4c2-48cd-9795-79ecb31b8560@oss.nxp.com> Date: Wed, 4 Feb 2026 10:13:07 +0800 From: "Ming Qian(OSS)" <ming.qian@....nxp.com> To: Nicolas Dufresne <nicolas@...fresne.ca>, Marco Felsch <m.felsch@...gutronix.de> Cc: 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 Nicolas, On 2/3/2026 11:40 PM, Nicolas Dufresne wrote: > Le mardi 03 février 2026 à 16:53 +0800, Ming Qian(OSS) a écrit : >> 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. > > After more testing, the fluster test is stable for NV12/NV15 tiled output for me > too. I'm running the tests with linear NV12/P010, which imply an extra set of > buffer. I will check if I can give you a easy way to test the linear formats. I > also have couple of streams that systematically breaks at specific spot (high > complexity scenes) with the provided patch. As most licensed content, this is > not sharable as-is. I will try and see if I can find a way to share something. > That would be very helpful. Thank you very much. >>>> >>>> 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. > > I do likely have slightly different bootchain, and of course all the HDMI > component are downstream, but I can't really isolate the dramatic issue of this > overclock without a display component of some sort. Its a huge differentiator in > the bandwidth consumption which is the main challenge on this SoC so far. 10bit > videos makes things a lot worse fwiw. > > We did review latest IMX vendor firmware package and can confirm we are running > the latest memory training blob and HDMI firmware. > > Nicolas Since the datasheet clearly states that the VPU G2 requires a voltage increase to 1.0V to run at 600MHz, (I thought it was already like this, but it actually wasn't.) I think we can align our test conditions to this. I will increase the G2 voltage in V2. Regards, Ming > >> 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