[meta-freescale] BT656/1120 support and LCD display on Wandboard?

Joshua Kurland joshua.kurland at adtecdigital.net
Wed Jan 22 11:29:34 PST 2014

Does the Wandboard BSP on Yocto support the use of the TTL display port?  I
am using a fresh copy of Dora branch and building fsl-image test for my
wandboard with kernel 3.0.35_4.0.0.  I am changing the video settings
through u-boot.  From my understanding, the following setting should
already be available on the Wandboard kernel.  The exact command I am using

  editenv mmcargs
      mmcargs=setenv bootargs console=${console},${baudrate}
video=mxcfb0:dev=lcd,CLAA-WVGA,if=RGB666 root=${mmcroot}

I then save the settings and boot the kernel.  Using a scope I am measuring
the output of the pixel clock, hsync and vsync.  With the RGB666 format, I
would expect hsync and vsync to pulse high with the frame.  Instead they
appear inverted, where the signal starts high and goes low with each new
frame.  I see no reason for this to happen, the documentation for the
Wandboard does not show any inversion on the output signal.  I do not
believe the RGB666 format uses a pixel clock.  That said, the output of the
pclk is very odd.  It misses every third pulse, running at 50MHz.  Could
this issue be caused by something in the kernel or the BSP in general?

My primary goal is to be able to output 16-bit video using the BT.1120
standard using a patch provided by Freescale (
https://community.freescale.com/docs/DOC-94019).  This format should output
1080i video with a pixel clock of 74.25MHz.  I applied the patch from
Freescale and added support for the Wandboard (see Wandboard patch below).
 As before, I added video support to the mmcargs variable as so:


When I measure the pixel clock, I see a perfect 50MHz clock.  While it is
an improvement over the strange 'missing pulse' clock of RGB666, it is not
the 74.25 that I am looking for.  I see nothing at all on the hsync and
vsync lines, or on the data pins.  I have also tried the other display
settings associated with the BT656 and BT1120 formats.  Each of the BT656
settings resulted in a clock identical to what I had with the RGB666
setting.  The BT1120 clocks were all the same 50MHz.  The patch should be
compatible with all imx6 devices.  What can I do to confirm that it is
compatible with the Wandboard?

I should also mention that while the board is in u-boot, I do see a good
74.25MHz clock.  This is independent of the video settings and seems to be
a default value.

How can the wandboard be properly configured to use its TTL display port?
 How can I use the BT656/1120 patch on the Wandboard?

Thank you,
Josh Kurland

 arch/arm/mach-mx6/board-wand.c |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/mach-mx6/board-wand.c b/arch/arm/mach-mx6/board-wand.c
index d971dba..c60235f 100644
--- a/arch/arm/mach-mx6/board-wand.c
+++ b/arch/arm/mach-mx6/board-wand.c
@@ -714,6 +714,14 @@ static struct fsl_mxc_ldb_platform_data wand_ldb_data
= {

------------------------------------------------------------------------ */

+static struct fsl_mxc_lcd_platform_data wand_bt656_data = {
+ .ipu_id = 0,
+ .disp_id = 0,
+ .default_ifmt = IPU_PIX_FMT_BT656,
------------------------------------------------------------------------ */
 static struct ipuv3_fb_platform_data wand_lvds_fb[] = {
  .disp_dev = "ldb",
@@ -726,6 +734,7 @@ static struct ipuv3_fb_platform_data wand_lvds_fb[] = {

------------------------------------------------------------------------ */

 static void __init wand_init_lcd(void)
  /* TTL */
@@ -787,10 +796,18 @@ static void __init wand_init_lcd(void)


  imx6q_add_ipuv3fb(1, &wand_lvds_fb[0]);

------------------------------------------------------------------------ */
+static void __init wand_init_bt656(void)
+ imx6q_add_bt656(&wand_bt656_data);

@@ -1254,6 +1271,7 @@ static void __init wand_board_init(void)
+ wand_init_bt656();
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20140122/7fe41799/attachment-0001.html>

More information about the meta-freescale mailing list