i.MX6Q BT.1120 SAV/EAV issue

[joshkurland]

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.

[hongchao0680]

Hello Qiang Li  and Josh Kurland ;

please help me

I use GS2972 with patch:

https://community.nxp.com/docs/DOC-100657

the SDI display out;but the  color not right ;how to fix this

https://community.nxp.com/message/1074084?commentID=1074084#comment-1074084 

waitting your answer....

[joshkurland]

Hello Qiang_FSL,

I am having diffuclty setting the full horizontal blanking period of BT1120-1080i into the IPU.  For BT1120-1080i, the horizontal blanking requires 2 bytes.  It appears that only the lower byte is getting set.  For example, 1080i60 horizontal blanking is 280 (0x118).  I only read 0x18 on my encoder chip, the upper byte is missing.  Likewise for 1080i50 the value is 720 (0x2D0) but I only get 0xD0.  Both NTSC and PAL only require a single byte to hold the blanking period, which would explain why those modes work and HD does not.

Can you tell me the address to the register that is holding the horizontal blanking period?  Is the register large enough to hold 2 bytes of data?

Thank you,

Josh K.

[qiang_li-mpu_se]

Hi Josh,

Where did you set the blanking data? In ipu_disp.c, function _ipu_dc_setup_bt656_interlaced(), the blanking data will be sent on 16 bits data lines, and they are fixed 0x1080:

if(is_bt1120) {
  _ipu_dc_write_tmpl(ipu, microcode_addr, WRG, (0x1080 << (di_msb - 15)), 0, 0, 0, DI_BT656_SYNC_BASECLK, 0, 0, 0);
} else {
  //wait ipp_clk, send 0x80
  //First 8 bit word in blanking
  _ipu_dc_write_tmpl(ipu, microcode_addr, WRG, (0x80 << (di_msb - 7)), 0, 0, 0, DI_BT656_SYNC_BASECLK, 0, 0, 0);
  microcode_addr ++;

  //wait ipp_clk, send 0x10
  _ipu_dc_write_tmpl(ipu, microcode_addr, WRG, (0x10 << (di_msb - 7)), 0, 0, 0, DI_BT656_SYNC_BASECLK, 0, 0, 0);
}

[joshkurland]

Forgive my inexperience, but what is the significance of the value 0x1080?

[qiang_li-mpu_se]

You can reference to the BT656 line data format, that 0x1080 is the Blanking Video data. For 8 bits BT656 interface, it needs 4 clocks for each pixel; but for 16 bits BT1120 interface, it needs 2 clocks for each pixel.

[joshkurland]

Thank you for that information.  It is helpful, but I do not think it addresses the actual problem.  It appears that the issue is not with the blanking data, but the blanking timing loop_N_times.  In the function _ipu_dc_setup_bt656_interlaced, the horizontal blanking period is getting passed in to loop_N_times. Then loop_N_times is getting passed to _ipu_dc_write_tmpl case BMA.  Inside case BMA, loop_N_times is shifted left by five then written into a register.  What is the physical address that loop_N_times is getting written into?  I am concerned that the second byte is sitting on an illegal boundary, and is therefore getting corrupted/lost.

case BMA:  

   reg = sync;

   reg |= (operand << 5);

    _ipu_dc_tmpl_write(ipu, reg, word*8);

For 1080i60, I expect to see 2200 - 280 = 1920.  What I am instead seeing is 2200 - 24 = 2176.  The correct horizontal blanking period of 280 (0x118) is loosing its most significant byte, which results in 24 (0x18) being sent to my encoder chip.  The same is true for 1080i50, where 720 (0x2D0) becomes 208 (0xD0).  Neither NTSC or PAL require a second byte to set the correct value, and they do work correctly on my hardware.   Am I on the right track here, or am I way off base?

I understand that you do not have the hardware to completely test 1080i on the 16-bit interface. However, have you heard of any Freescale iMX6 customers who have successfully implemented 1080i displays?  If possible I would like to be put in contact with them to try to get an open source solution.

Thank you,

Josh K.

[qiang_li-mpu_se]

Hi Josh, the issue should be caused by the BMA command, the N "loop_N_times" parameter is a 8 bits value, bit 5~12, so its MAX value is 255.

I will update the IPU microcode to fix this issue. Thanks for your loading to find it.

[joshkurland]

Great, thank you!  Do you have an estimate of when a patch fix will be released?

[qiang_li-mpu_se · Accepted solution]

Hi Josh, I had the BT656/BT1120 IPU microcode for fix this BMA parameter "N" limitation, it is 8 bits, so max value is 255.

You can updated the attached code into your BSP, both the macro and function.

[joelg]

Hello Qiang Li,

now that there is more support for pixel clock of 74.25/1.001 with 1080i what changes should be made in 3.10.17 kernel to allow output of 23.976fps in 1080p?  This frequency also requires a similar 1.001 adjustment.

Thank you.

[joshkurland]

Hi Qiang Li,

So far so good!  I am playing 1080i50 and 1080i60 video with no reported errors.  Thank you very much for the help.

[hongchao0680]

I see you selove the problem; can you hellp me?

I have a custom i.MX6Q board running  fsl4.1.15_2;   I need to send 1080i video through the parallel display port to a Semtech  GS2972  20-bit HD-SDI serializer.  Please anyone can tell me  how to fix the display and uboot  to support 

 1080I60  1080P60  720P@50 display ?

thanks a lot .

[qiang_li-mpu_se]

Hi Hongchao,

You can reference to this link: https://community.nxp.com/docs/DOC-100657

[qiang_li-mpu_se]

Hi Josh, I planed to fix this issue before 1/23.

[joshkurland]

I have managed to make a little progress using BT1120-NTSC and BT1120-PAL modes.  Both of these modes can now be recognized by the SDI serializer and displayed to a monitor.  Interestingly enough, the field alignment on both modes is inverted, so the display is very poor.  I attempted to correct this by adding 'FB_VMODE_ODD_FLD_FIRST' to the sync field of fb_videomode, but saw no change.  Also, when I provide the serializer with BT1120-PAL, the image is blown up and the monitor reports that it is still detecting NTSC.

That aside, what I really need is to display HD video.  After validating the BT1120 NTSC and PAL modes, I moved on to BT1120-1080I50 and 1080I60.  My uboot setting looks like the following

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

I made certain that pll5 is set as the video clock for 74.25MHz.  Also, I am setting BT656_IF_DI_MSB to 15 in order to use the lower 16 data bits.  Depending on whether I do 1080I50 or 1080I60, the output of /sys/class/graphics/fb0/mode is D:1920x1080i-60 or D:1920x1080i-50.  The SDI chip will lock onto the pixel clock, but is still reporting SAV/EAV timing errors embedded within the stream.  In order to be certain that my hardware is functioning correctly, I need to know if the BT1120-1080I modes have been validated by Freescale with the 3.10.17 kernel.

Thank you,

Josh K.

[joshkurland]

I think the hsync_len for BT1120-NTSC and BT1120-PAL are incorrect in mxc_lcdif.c.  For BT1120-NTSC, shouldn't the value be (4 + 67*4 + 4)/2 instead of 4 + 67*2 + 4?  Otherwise an extra SAV/EAV timing signal will be sent.  BT1120-PAL should follow the same logic.  After I made those changes, the status register of my SDI chip reports the expected values.

I am still having trouble with HD BT1120-1080I60 and BT1120-1080I50.  By looking at the status registers of my SDI chip, I see that the active words per line are way out of spec.  Where I expect to see 1920 active words/line, I instead get 2176 for 1080I60 and 2432 for 1080I50.  The other fields (lines/frame, words/line, and active lines/field) all report as expected.  I am unsure if this is do to a hardware issue or configuration error on my part.  How can I validate that the BT1120-1080I/50/60 modes work correctly?

Thank you,

Josh K.

[joshkurland]

This is a table of the four video modes, the expected values, and the actual values reported by the sdi chip.  I adjusted the hsync for ntsc and pal as noted in the previous post, and recorded the results in the 'adjusted' field.

Format		Lines/frame	Words/line	Active words/line	Active lines/field
BT1120-NTSC	(expected)	525	1716	1440	244
	Freescale	525	1724	1440	240
	Adjusted	525	1716	1440	240
BT1120-PAL	(expected)	625	1728	1440	288
	Freescale	625	1736	1440	288
	Adjusted	625	1728	1440	288
BT1120-1080I60	(expected)	1125	2200	1920	540
	test	1125	2200	2176	540
	Adjusted	???	???	???	???
BT1120-1080I50	(expected)	1125	2640	1920	540
	test	1125	2640	2432	540
	Adjusted	???	???	???	???

# fbset -fb /dev/fb2

mode "720x480-30"

  # D: 13.500 MHz, H: 15.341 kHz, V: 30.438 Hz

  geometry 720 480 720 480 16

  timings 74074 19 3 20 3 138 1

  accel false

  rgba 5/11,6/5,5/0,0/0

endmode

mode "720x576-25"

  # D: 13.500 MHz, H: 15.203 kHz, V: 25.254 Hz

  geometry 720 576 720 576 16

  timings 74074 22 2 23 2 144 1

  accel false

  rgba 5/11,6/5,5/0,0/0

endmode

mode "1920x1080-25"

  # D: 74.250 MHz, H: 27.882 kHz, V: 25.278 Hz

  geometry 1920 1080 1920 1080 16

  timings 13468 20 3 20 2 720 1

  accel false

  rgba 5/11,6/5,5/0,0/0

endmode

mode "1920x1080-30"

  # D: 74.178 MHz, H: 33.369 kHz, V: 30.253 Hz

  geometry 1920 1080 1920 1080 16

  timings 13481 20 3 20 2 280 1

  accel false

  rgba 5/11,6/5,5/0,0/0

endmode

[joshkurland]

Is it possible I am missing a configuration for HD?

u-boot:

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

device-tree:

   mxcfb3: fb@2 {

      compatible = "fsl,mxc_sdc_fb";

      disp_dev = "lcd";

      interface_pix_fmt = "RGB565";

      mode_str ="CLAA-WVGA";

      default_bpp = <16>;

      int_clk = <0>;

      late_init = <0>;

      status = "disabled";

   };

...

   lcd@0 {

      compatible = "fsl,lcd";

      ipu_id = <0>;

      disp_id = <0>;

      default_ifmt = "RGB565";

      pinctrl-names = "default";

      pinctrl-0 = <&pinctrl_ipu1_1>;

      status = "okay";

};

kconfig:

   CONFIG_FB_MXC_MIPI_DSI = y

   CONFIG_FB_MXC_TRULY_WVGA_SYNC_PANEL = y

   CONFIG_FB_MXC_EDID = y

   CONFIG_FB_MXC_SYNC_PANEL = y

   CONFIG_FB_MXC_EINK_PANEL = y

   CONFIG_FB_MXS_SII902X = y

   CONFIG_HANNSTAR_CABC = y

   CONFIG_FB_MXC_HDMI = y

uname -a:

   Linux test-imx6 3.10.17-1.0.0-wandboard #121 SMP PREEMPT Wed Oct 8 14:35:06 EDT 2014 armv7l GNU/Linux

/arch/arm/mach-imx/clk-imx6q.c:

   - clk_set_parent(clk[ipu1_di0_pre_sel], clk[pll3_pfd1_540m]);  /* For CVBS 27MHz clock */

   + clk_set_parent(clk[ipu1_di0_pre_sel], clk[pll5_video_div]);   /* For 74.25MHz clock */

/drivers/mxc/ipu3/ipu_disp.c:

   - #define BT656_IF_DI_MSB    23

  + #define BT656_IF_DI_MSB    15

echo 0 > /sys/class/graphics/fb0/blank

cat /sys/class/graphics/fb0/mode:  D:1920x1080i-60

dmesg:

  mxc_sdc_fb fb.26: 1920x1080 h_sync,r,l: 280,3,20  v_sync,l,u: 1,2,20 pixclock=74178000 Hz

  No warnings

IMX6 Disp -> SDI Chip pinout:

For the record, I have BT1120-PAL working flawlessly, and BT1120-NTSC functions but is distorted.  When I switch to 1080I50 and 60, the pixel clock adjusts correctly and the sdi chip can lock to it, but the data received is incorrect.  I am unable to determine if the issue is with the bt1120 patch, a configuration of the imx6, configuration of the sdi chip or a hardware problem.

Any help would be greatly appreciated,

Josh K.

[qiang_li-mpu_se]

  * hsync_len: EAV Code + Blanking Video + SAV Code (in pixel clock count)

  *     For BT656 NTSC, it is 4 + 67*4 + 4 = 276.

  *     For BT1120 NTSC, it is 4 + 67*2 + 4 = 142.

  *     For BT656 PAL, it is 4 + 70*4 + 4 = 288.

  *     For BT1120 PAL, it is 4 + 70*2 + 4 = 148.

You can reference above setting to tune your output by modifying the hsync_len setting, in current setting, for EAV and SAV code, they will cost 4 pixel clocks. For BT1120 mode, the EAV/SAV code will only be sent on high 8 bits. The blank video 0x1080 will be sent in one pixel clock.

I think your "pixclock=74178000" should be wrong, it should be a correct 74.25MHz clock.

By the way, I only have the hardware for BT656 interface.

[joshkurland]

Hi Qiang_FSL

Thank you for your response.  If possible, could you explain how you calculated the left/right and upper/lower margins of the BT1120 interface for NTSC, PAL, 1080I60 and 1080I50?  From my understanding, the calculation should be:

  (Xres+left margin+right margin+hsync)*(Yres+upper margin+lower margin+vsync)*refresh rate = pixel clock frequency

Please correct me if I am wrong, but using this equation the result does not equal the precise pixel clock.  For instance, using BT1120-NTSC 720x480i at 59.94Hz with the margins 19,3,20,3, hsync 142 and vsync 1, the pixel clock is equal to 13.35MHz.  In reality, the pixel clock should be 13.50MHz.  Using the same equation, I get BT1120-PAL at 13.42, BT1120-1080I60 at 73.62 and BT1120-1080I50 at 73.50.  Can you explain how to adjust the margins to better match the BT1120 standard?

Also, my hardware requires the 16bit BT1120 interface and does not support BT656.  Everything that I have referenced has been in BT1120.

Thank you,

Josh K.