IMX6Q DRM - Framebuffer update rate with LVDS

[Lucas Stach]

Hi Chris,

Am Mittwoch, dem 15.12.2021 um 16:33 +0000 schrieb Chris Pringle:
> Hi,
>  
> 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.

Regards,
Luacs