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

[Ming Qian(OSS)]

Hi Nicolas,

On 1/30/2026 10:47 PM, Nicolas Dufresne wrote:
> Hi,
> 
> Le vendredi 30 janvier 2026 à 16:41 +0800, ming.qian at oss.nxp.com a écrit :
>> From: Ming Qian <ming.qian at oss.nxp.com>
>>
>> The VPU G2 clock was reduced from 600MHz to 300MHz in commit
>> b27bfc5103c7 ("arm64: dts: freescale: Fix VPU G2 clock") to address
>> pixel errors with high-resolution HEVC postprocessor output.
>>
>> However, testing shows the 300MHz clock rate is insufficient for
>> 4K60fps decoding and the original pixel errors no longer occur at
>> 600MHz with current drivers.
> 
> Tested on EVK, with the downstream DCSS driver, and this change triggers DCSS
> underrun (which is related to the DRAM QoS erratas on this SoC). It also
> sometimes trigger the "not all macroblock decoded" warning I added recently, and
> we can empty IRQs, but these are handled now.
> 

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?

>>
>> Test results with 3840x2160 at 60fps HEVC stream decoded to NV12
>> (the same scenario that exhibited pixel errors previously):
>>
>> 300MHz performance:
>> - Severe frame dropping throughout playback
>> - Only 336 frames rendered in 11:53 (0.471 fps)
>> - Continuous "A lot of buffers are being dropped" warnings
>> - Completely unusable for 4K video
>>
>> 600MHz performance:
>> - Smooth playback with only 1 frame dropped at startup
>> - 37981 frames rendered in 10:34 (59.857 fps)
>> - Achieves target 60fps performance
>> - No pixel errors or artifacts observed
> 
> That probably only true with the upstream DCSS + a small resolution embedded
> panel ? Can you clarify this setup, because the display drivers mainline are
> very minimal. Would be nice to show you average DDR read/write bandwidth
> utilization during this run for comparision.

My display is hdmi, I'll try the DCSS.
And the DDR bandwidth results measured by perf are as follows:

  Performance counter stats for 'system wide':

       113303664278      imx8_ddr0/read-cycles/
        82457075530      imx8_ddr0/write-cycles/

      634.892101865 seconds time elapsed

> 
> Another information that bugs me, in the BSP code, the G2 voltage is increased
> too, which you didn't do here. They also use the thermal 2 zone to kick it down
> to 300 until it cools down.
> 

In our internal code, whenever the frequency of either g1 or g2 reaches
600MHz, the voltage is adjusted to 1.0V. Since g1 is already set to 600
MHz in the upstream DTS, I believe the default version is already 1.0v.

And do you mean vpu-thermal? But it doesn't define the cooling-map, I'm
not sure how it works.

		vpu-thermal {
			polling-delay-passive = <250>;
			polling-delay = <2000>;
			thermal-sensors = <&tmu 2>;

			trips {
				vpu-crit {
					temperature = <90000>;
					hysteresis = <2000>;
					type = "critical";
				};
			};
		};

Regards,
Ming

> Nicolas
> 
>>
>> Restore the clock to 600MHz to enable proper 4K60fps decoding
>> capability while maintaining stability.
>>
>> Test pipeline:
>>    gst-launch-1.0 filesrc location=<4K60_HEVC.mkv> ! \
>>      video/x-matroska ! aiurdemux ! h265parse ! \
>>      v4l2slh265dec ! video/x-raw,format=NV12 ! \
>>      queue ! waylandsink
>>
>> Fixes: b27bfc5103c7 ("arm64: dts: freescale: Fix VPU G2 clock")
>> Signed-off-by: Ming Qian <ming.qian at oss.nxp.com>
>> ---
>>   arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
>> b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
>> index 607962f807be..731142176625 100644
>> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
>> @@ -960,7 +960,7 @@ pgc_vpu: power-domain at 6 {
>>   									
>> <&clk IMX8MQ_SYS1_PLL_800M>,
>>   									
>> <&clk IMX8MQ_VPU_PLL>;
>>   						assigned-clock-rates =
>> <600000000>,
>> -								
>> <300000000>,
>> +								
>> <600000000>,
>>   								
>> <800000000>,
>>   								       <0>;
>>   					};
>>
>> base-commit: c824345288d11e269ce41b36c105715bc2286050
>> prerequisite-patch-id: 0000000000000000000000000000000000000000