[PATCH] arm64: dts: imx8mq: Restore VPU G2 clock to 600MHz for 4K60fps decoding
Nicolas Dufresne
nicolas at ndufresne.ca
Mon Feb 2 10:44:28 PST 2026
Le lundi 02 février 2026 à 15:44 +0800, Ming Qian(OSS) a écrit :
> 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?
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).
>
> > >
> > > 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";
> };
> };
> };
Its not:
$> cat /sys/kernel/debug/regulator/regulator_summary | grep SW1C
SW1C 1 1 0 unknown 900mV 0mA 825mV 1100
Before I gave up on 60Hz on this SoC, I did test raising it to 1v with this
patch (hopefully there is a way to do that in DT, would be more elegant):
diff --git a/drivers/pmdomain/imx/gpcv2.c b/drivers/pmdomain/imx/gpcv2.c
index 4b828d74a606..2f2b85ca6fd2 100644
--- a/drivers/pmdomain/imx/gpcv2.c
+++ b/drivers/pmdomain/imx/gpcv2.c
@@ -639,6 +639,7 @@ static const struct imx_pgc_domain imx8m_pgc_domains[] = {
},
.pgc = BIT(IMX8M_PGC_VPU),
.keep_clocks = true,
+ .voltage = 1000000,
},
[IMX8M_POWER_DOMAIN_DISP] = {
I would also like to remind you your own erratas, in the errata document you
state that DRAM QoS is broken, and all transactions are treated with the same
priority. If you overload the bandwidth, it becomes fatal for the display
controller. We tried to workaround with changing the NoC configuration, but it
did not work. It feels like that NoC granularity is not enough to prevent
underrun of the display controller (where the QoS would work, since its done at
transaction level, not by measuring bandwidth).
Nicolas
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260202/2d6b7eba/attachment.sig>
More information about the linux-arm-kernel
mailing list