FBIO_WAITFORVSYNC on i.MX28

[niclasanderberg]

We need to use the FBIO_WAITFORVSYNC ioctl on Linux using the i.MX28 EVK (with the lcd_43wvf1g.c LCD driver of the addon LCD) to reduce tearing in our application. We saw a couple of issues, and attached is a simple app which helps show these issues:

Issue 1 – Vertical refresh rate of the LCD panel

The ‘fbset’ command executed on the target gets us some basic parameters of the setup. This suggests a vertical refresh rate of ~92Hz.

root@freescale ~$ fbset

mode "800x480-92"

        # D: 50.000 MHz, H: 50.403 kHz, V: 92.314 Hz

        geometry 800 480 800 960 32

timings 20000 64 64 32 32 64 2

accel false

rgba 8/16,8/8,8/0,0/0

endmode

The attached vsync.c application simply waits for vsync and records the time between events. Execute it without command line arguments and you will see output like:

Frame time 23188 us

Frame time 23156 us

Frame time 23156 us

…

This suggests a refresh rate around 43.5Hz, as opposed to the “documented” 92Hz. What is the actual refresh rate of the panel?

Issue 2 – FBIO_WAITFORVSYNC not holding for next vsync

The expected behavior of FBIO_WAITFORVSYNC is for wait for the next vertical sync interrupt.

If you execute the attached test app with “vsync 1 30000” you will be simulating a 30ms load on each frame. This is more than the ~23ms budget, and should cause a frame skip, which means I would expect to see frame times of ~46ms (2 x 23ms). Instead I get:

Frame time 30313 us

Frame time 30281 us

Frame time 30281 us

…

This likely means that the vsync IRQ flag is already set when FBIO_WAITFORVSYNC is called, immediately unblocking the ioctl call. Instead the IRQ bit should be cleared when entering FBIO_WAITFORVSYNC and waiting for the next vsync interrupt. Otherwise you will tear if you exceed your frame budget.

The version of the SDK we use is L2.6.35_10.12.01. Does anyone know if the FBIO_WAITFORVSYNC is working properly, or if there is a fix available for it?

Original Attachment has been moved to: vsync.c.txt.zip