RE: – EXTERNAL:Re: IMX6Q DRM - Framebuffer update rate with LVDS

[Chris Pringle]

From: Lucas Stach <l.stach at pengutronix.de>
Sent: 15 December 2021 16:46
> Am Mittwoch, dem 15.12.2021 um 16:33 +0000 schrieb Chris Pringle:
> > I’m looking for some advice/guidance on an issue I’ve run into with
> > the IMX DRM implementation with LVDS. I’m using an imx6q with an 1080p
> > LVDS display on kernel 5.10.73-rt. When running Qt applications
> > (EGLFS) with this platform, I’ve run into a strange issue where the
> > framebuffer flip rate (as observed in libdrm) seems to be fixed at
> > either ~14fps or ~28fps. This changes from ~14fps to ~28fps when I
> > increase the pixel clock rate for the display above ~75.5Mhz.
> >
> > Our render times are well below 35mS – usually around 28-30mS. With a
> > pixel clock of 74Mhz, the frame buffer refreshes every 70mS, blocking
> > the app waiting for the next page flip. Increasing the pixel clock to
> > 75.5Mhz causes the frame buffer to flip every 35mS. Increasing the
> > pixel clock further to around 140MHz makes no difference – the frame
> > buffer still flips every 35mS. It appears as if the clock governing
> > the frame buffer is not scaling with the display pixel clock and is
> > running asynchronously – I’m unclear if this is by design or if this
> > is down to platform misconfiguration.
> >
> > The pixel clock for the LVDS display is set in the DTS file and is
> > being correctly picked up – I can see the display refresh rate
> > reflected in the Qt library logs and the pixel clock rate reflected in
> > the debug kernel logs for the imx-ipuv3 driver.
> >
> > Does anyone have any thoughts on what might be causing this behaviour?
> > I’d like to understand why the framebuffer refresh rate is not
> > changing proportionally with the pixel clock rate, and why the
> > duration between flips suddenly jumps from 35mS to 70mS when the pixel
> > clock drops below ~75.5Mhz.
> 
> This sounds like the LDB is using a system clock source and thus can not
> correctly match the rate of the display. Userspace gets to see what the panel
> wants as a pixel clock, but the rate matching may be very poor when not
> being sourced from the video PLL.
> 
> If you don't need to drive any other display on the system, the best option is
> to use the video PLL as it can provide almost perfect rate matching. See the
> clks node in arch/arm/boot/dts/imx6qdl-zii-rdu2.dtsi
> for an example on how to switch the LDB to use the video PLL as its clock
> source.
> 

Thanks, Lucas, for the instant response! That's solved the issue for me and explains the behaviour I was seeing.

Cheers,
Chris