[meta-freescale] 1080p split-mode LVDS on imx6dp

[Olivier Bourgois]

Dear All,

We have ported linux-fslc-kernel to a custom board with a 1080p fullHD LVDS running in split-mode.  We seem to be running into some IPU issues on the imx6dp.

SRCBRANCH = "4.1-2.0.x-imx"
SRCREV = "ee67fc7e072df596577e3a4e4fce7b51816d4b0a"

We have two versions of our board, one with an imx6d and one with an imx6dp for comparison.  Other than that both boards are identical  All tests running at 1080p LVDS output

1) imxqd port
    - This board works ok with Qt Cinematic experience running at ~31fps 1080p
    - the graphics pipeline is able to run in overlay mode ( echo 0 > /sys/class/graphics/fb1/blank and putting an image in it with 'cat') with moving image sources such as a qt eglfs app in /dev/fb1 and a gstreamer video in /dev/fb0. The idea is of eventually using color keying to combine the two framebuffers, but it's a little slow on this platform.

2) imxqdp port
    - This board reaches ~60fps 1080p when running Qt Cinematic experience but there appears to be some missing scanline data (end of some scanlines black, especially towards the bottom of the screen) This seems to be only when "prefetch" is enabled on the framebuffer in the dtb
    - strangely enough the scanline miss-out effect is reduced if we increase the GPU processing load upstream in another qt application which applies a egl based shader effect to the entire screen
    - when /dev/fb1 is unblanked, the system works ok with static images (50% alpha blending of both buffers)  however with moving images the IPU crashes and sometimes the CPU as well.  The LVDS screen fades out and dies.

    Messages:
    imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_10 = 0x00080000
    imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_5 = 0x08800000
    mxc_sdc_fb fb at 0: timeout when waiting for flip irq
    ...

It kind of looks like the IPU can't cope with the faster data being fed to it by the plus processor. Unfortunately I don't think we can do an LVDS channel split between IPU1 and IPU2 to balance the load.  Has anyone else encountered similar issues?  Any hints would be greatly apreciated.

Please find attached our device tree files.

Regards,

Olivier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20170616/0098ae02/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtb_files.zip
Type: application/x-zip-compressed
Size: 5056 bytes
Desc: dtb_files.zip
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20170616/0098ae02/attachment.bin>