AnsweredAssumed Answered

i.MX6Q BT.1120 SAV/EAV issue

Question asked by Josh Kurland on Sep 22, 2014
Latest reply on Mar 25, 2016 by wilson chen
Branched to a new discussion

I have a custom i.MX6Q board running 3.10.17_1.0.0-ga.  I need to send 1080i video through the parallel display port to a Semtech GS1672 20-bit HD-SDI serializer.  I am using the latest BT.1120 patch by Qiang Li to set the video mode to 1080I60 (https://community.freescale.com/docs/DOC-100657).

 

I am able to get the correct pixel clock of 74.25 MHz for 1080I50 after changing the video clock to pll5_video_div in clk-imx6q.c.  For 1080I60, the required pixel clock is 74.25/1.001, which can be set in mxc_lcdif.c by changing the pixel clock field for 1080I60 from 13468 to 13481.  I found this new pixel clock value from 10^12/(7425/1.001).  My hardware interface design also required me to change the definition in ipu_disp.c to use the lower 16bits of the display register.  I have used an oscilloscope to measure the pixel clock rates, and have confirmed that data is being sent through the correct lines.  My u-boot settings look like the following:

    video=mxcfb0:dev=lcd,BT1120-1080I60,if=BT1120,fbpix=UYVY16  fbmem=64M vmalloc=400M consoleblank=0

 

The SDI chip is detecting the correct pixel clock, and appears to be seeing some form of video data.  However, it is also reporting TRS errors in the SAV/EAV timing.  Have the SAV/EAV codes for BT.1120 1080I60 been tested on the 3.10.17 kernel?  Is this something that can be modified easily, or will it require me to dig through the microcode fix?  Is it possible to use the hsync and vsync signals instead of the embedded TRS? 


Also, where do the values for the margins in mxc_lcdif.c come from?  Are these generic positions or are they part of the BT.1120 standard?


Thank you,

Josh K.

Outcomes