From: Lucas Stach <l.stach@xxxxxxxxxxxxxx> 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
