i.MX6 HDMI & CVBS Concurrent Output Problem

[ryanerb]

Hello,

HDMI and CVBS cannot run concurrently at the same time. As soon as you start one, the other goes blank.

We are testing in Yocto 1.5 with the 3.10.17 kernel.

We are using patches from Freescale for BT656 and ADV7393 here: https://community.freescale.com/docs/DOC-94019 and have ported those to the freescale 3.10.17_1.0.0_ga kernel and that we are using the yocto v1.5 BSP

We found that even if you re-order the mxcfb devices you get the same result. Note that on the board LVDS is IPU1_DISP0, HDMI is IPU1_DISP1 and ADV739x is IPU2_DISP0 so this doesn't seem to be an issue of 2 displays on one IPU.

To recreate the issue:

cat /proc/cmdline
console=ttymxc1,115200 root=ubi0:rootfs ubi.mtd=2 rootfstype=ubifs video=mxcfb1:dev=hdmi,1280x720M@60,if=RGB24 video=mxcfb2:dev=adv739x,BT656-NTSC,if=BT656,fbpix=RGB565 video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb3:off debug
echo "V:1920x1080p-60" > /sys/class/graphics/fb0/mode
gst-launch videotestsrc ! mfw_v4lsink device=/dev/video16 &
gst-launch videotestsrc ! mfw_v4lsink device=/dev/video18 &

if you force the HDMI output to 480p this issue is not present:

echo "D:640x480p-60" > /sys/class/graphics/fb0/mode gst-launch videotestsrc ! mfw_v4lsink device=/dev/video16 & gst-launch videotestsrc ! mfw_v4lsink device=/dev/video18 &

KevinWongarpan_chakravarty

[gusarambula]

Hello Ryan,

My apologies for the delay. Would you please tell me which board are you using? I’m asking to see if it would be possible for us to reproduce this issue on any of the Freescale Reference Boards.

[timharvey]

We are using a Gateworks Ventana GW5400 which is closely based on the SabreSD reference design.

Here are some specifics:

• fsl 3.10.17_1.0.0-ga kernel (with patches on top to support are board)
• yocto v1.6 userspace
• IMX6Q CPU
• ADV7393 connected to  DISP0 pinmuxed to IPU2_DISP0 using BT656 supported by Qiang Li's patches here: Patch to Support BT656 and BT1120 Output For i.MX6 BSP
• HDMI using IPU1_DISP1
• our devicetree sets mxcfb0 to HDMI@1080p and mxcfb1 to CVBS via the ADV7393

root@ventana:~# opkg list_installed | grep gst-fsl-plugin

gst-fsl-plugin - 3.0.11-r0

gst-fsl-plugin-gplay - 3.0.11-r0

root@ventana:~# cat /proc/cmdline

console=ttymxc1,115200 root=ubi0:rootfs ubi.mtd=2 rootfstype=ubifs debug

root@ventana:~# dmesg | grep mxc_sdc

[    0.650651] mxc_sdc_fb fb.31: registered mxc display driver hdmi IPU1_DISP1

[    0.685424] mxc_sdc_fb fb.32: registered mxc display driver adv739x IPU2_DISP0

[    0.695242] mxc_sdc_fb fb.33: registered mxc display driver ldb IPU1_DISP0

# fb0 is hdmi 2-layer-fb-bg and configured for 1080p

root@ventana:~# cat /sys/class/graphics/fb0/mode

D:1920x1080p-60

# fb2 is adv739x 2-layer-fb-bg and configured for 480i output

root@ventana:~# cat /sys/class/graphics/fb2/mode

D:720x480i-60

# launch a background test source output to hdmi

root@ventana:~# gst-launch videotestsrc ! mfw_v4lsink device=/dev/video16 &

[1] 775

root@ventana:~# MFW_GST_V4LSINK_PLUGIN 3.0.11 build on Jun 23 2014 14:43:24.

Setting pipeline to PAUSED ...

Pipeline is PREROLLING ...

>>V4L_SINK: Actually buffer status:

        hardware buffer : 12

        software buffer : 0

Pipeline is PREROLLED ...

Setting pipeline to PLAYING ...

full screen size:1920x1080

[V4L Update Display]: left=0, top=0, width=1920, height=1080

set v4l display crop sucessfully

New clock: GstSystemClock

# launch a background test source output to mxcfb1 cvbs (as soon as this is done, mxcfb0 hdmi fb0's display goes black)

root@ventana:~# gst-launch videotestsrc ! mfw_v4lsink device=/dev/video18 &

[2] 779

root@ventana:~# MFW_GST_V4LSINK_PLUGIN 3.0.11 build on Jun 23 2014 14:43:24.

Setting pipeline to PAUSED ...

Pipeline is PREROLLING ...

>>V4L_SINK: Actually buffer status:

        hardware buffer : 12

        software buffer : 0

Pipeline is PREROLLED ...

Setting pipeline to PLAYING ...

full screen size:1920x1080

[V4L Update Display]: left=0, top=0, width=1920, height=1080

set v4l display crop sucessfully

New clock: GstSystemClock

if you reverse the order above and start the CVBS stream first (/dev/video18) it will blank as soon as you start the HDMI stream (/dev/video16). Note that the display blanking (/sys/class/fb*/blank) is not the issue - I've tried unblanking them. I believe the issue here is that mfw_v4lsink is getting the resolution from the wrong framebuffer (see above Gstreamer shows width/height of 1920x1080 for /dev/video18's stream which is not proper) so I'm assuming this is possibly a bug in gst-fsl-plugin. Also note that if you force the HDMI display resolution to match the CVBS the issue will not occur:

root@ventana:~# cat /sys/class/graphics/fb0/modes

V:640x480p-60

D:1920x1080p-60

V:640x480p-60

root@ventana:~# echo "V:640x480p-60" > /sys/class/graphics/fb0/mode

root@ventana:~# gst-launch videotestsrc ! mfw_v4lsink device=/dev/video16 &

[1] 795

root@ventana:~# MFW_GST_V4LSINK_PLUGIN 3.0.11 build on Jun 23 2014 14:43:24.

Setting pipeline to PAUSED ...

Pipeline is PREROLLING ...

>>V4L_SINK: Actually buffer status:

        hardware buffer : 12

        software buffer : 0

Pipeline is PREROLLED ...

Setting pipeline to PLAYING ...

full screen size:640x480

[V4L Update Display]: left=0, top=0, width=640, height=480

set v4l display crop sucessfully

New clock: GstSystemClock

root@ventana:~# gst-launch videotestsrc ! mfw_v4lsink device=/dev/video18 &

[2] 799

root@ventana:~# MFW_GST_V4LSINK_PLUGIN 3.0.11 build on Jun 23 2014 14:43:24.

Setting pipeline to PAUSED ...

Pipeline is PREROLLING ...

>>V4L_SINK: Actually buffer status:

        hardware buffer : 12

        software buffer : 0

Pipeline is PREROLLED ...

Setting pipeline to PLAYING ...

full screen size:640x480

[V4L Update Display]: left=0, top=0, width=640, height=480

set v4l display crop sucessfully

New clock GstSystemClock

Regards,

Tim

[timharvey]

This issue has been resolved

Basically, the issue is that the same ipu<n>_di<n> clock cannot be used by CVBS (which needs a 27MHz clock) and HDMI (which needs a clock dependent on its selected resolution). The fix is to make sure they have clock sources that don't conflict with each other.  See Distorted Video i.MX6 gStreamer for the full discussion and updated patches.

[gusarambula]

Thank you for updating this thread! I'm sure the solution will help other users of the communities.

[jamesbone]

Hello Ryan,

We are already reviewing your issue, next week will try to provide a response.