Patch for iMX6 BSP to support interlaced display on HDMI and LCD interface

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Patch for iMX6 BSP to support interlaced display on HDMI and LCD interface

No ratings

Patch for iMX6 BSP to support interlaced display on HDMI and LCD interface

1. Description

    1) Support HDMI interlaced display mode, the followed format had been verified.
        CEA format 5: 1920x1080i @60Hz
        CEA format 6&7: 720(1440)x480i @60Hz
        CEA format 20: 1920x1080i @50Hz
        CEA format 21&22: 720(1440)x576i @50Hz

    2) Support LCD interface for interlaced display mode, 1920x1080i @50Hz(CEA format 20)
       had been verified.


2. File List
-- 0001-IPUv3-support-interlaced-display-mode.patch
   Patch to support interlaced display output for iMX6 ipuv3.

-- 0002-iMX6-HDMI-support-interlaced-display-mode.patch
   Patch to support interlaced display mode for iMX6 HDMI driver.

-- 0003-iMX6-LCD-interface-supports-1920x1080i50-mode.patch
   Patch to support interlaced display mode for iMX6 LCD interface driver.
  
-- readme.txt
   this file, please refer to it before use the patches


3. Requirement

- iMX6 SabreSD board.

- L3.0.35_4.1.0_GA_iMX6DQ kernel.


4. How to use

-- Copy the patch files to kernel folder.
    $ cd ~/ltib/rpm/BUILD/linux-3.0.35/
    $ git apply ./0001-IPUv3-support-interlaced-display-mode.patch
    $ git apply ./0002-iMX6-HDMI-support-interlaced-display-mode.patch
    $ git apply ./0003-iMX6-LCD-interface-supports-1920x1080i50-mode.patch

-- Build the new kernel image:
    $ cd ~/ltib/rpm/BUILD/linux-3.0.35
    $ export CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/bin/arm-fsl-linux-gnueabi-
    $ export ARCH=arm
    $ make imx6_defconfig
    $ make uImage

-- Uboot parameters for video mode
   Output 1080i50 display mode on HDMI:
      "video=mxcfb0:dev=hdmi,1920x1080Mi@25,if=RGB24,bpp=32"

   Output 1080i60 display mode on HDMI:
      "video=mxcfb0:dev=hdmi,1920x1080Mi@30,if=RGB24,bpp=32"

   Output 576i50 display mode on HDMI:
      "video=mxcfb0:dev=hdmi,1440x576Mi@25,if=RGB24,bpp=32"

   Output 480i60 display mode on HDMI:
      "video=mxcfb0:dev=hdmi,1440x480Mi@30,if=RGB24,bpp=32"

   Output 1080i50 display mode on LCD interface:
      "video=mxcfb0:dev=lcd,LCD-1080I50,if=RGB565,bpp=32"
     
-- Switch HDMI interlaced mode
   $ echo S:1920x1080i-50 > /sys/class/graphics/fb0/mode
   $ echo S:1920x1080i-60 > /sys/class/graphics/fb0/mode
   $ echo S:1440x480i-50 > /sys/class/graphics/fb0/mode
   $ echo S:1440x576i-60 > /sys/class/graphics/fb0/mode


5. Know issue
    1) When the interlaced display and another display work on same IPU,
       blank and unblank the interlaced display will get the followed IPU
       warning, but the display still works due to IPU can revover from the error.
    imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_5 = 0x00800000
    imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00080000

2015-05-13 update:

Replace the fourth patch to make interlace display mode follow CEA-861-specification

The patch "0004-IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch" was fine tuned for CEA-861-D specification on interlaced mode display. Please use this patch to replace the old 0004 patch.

2016-05-20 Update:

For 3.0.35 BSP, add patch

0005-IPU-update-interlaced-video-mode-parameters-to-align.patch

     Align the interlaced video mode parameters to progressive mode.

0006-IPU-update-IDMAC-setting-for-interlaced-display-mode.patch

     Udate the IDMAC setting for interlaced display mode, output odd field data from memory first, it aligns with IPU DI timing, odd field first.

For 3.14.52 BSP, created the new patch L3.14.52_1.1.0_GA_HDMI_Interlaced_Mode_Patch_2016_05_20.zip.

Attachments
Comments

I add the pach for imx6 but HDMI interlace display not normal. 576i and 480i video display with bad quality.

Video showed with a ripple phenomenon. I didn't find a way to solve the problem.  Do you have any suggestions? Thanks

In this patch, we haven't used double clocked mode to generate the 576i and 480i output, it used the 1440*576 and 1440*480 framebuffer. This maybe will cause some video quality issue.

Then how to use double clocked mode to generate the 576i and 480i output?

The double clocked mode can be implemented by modified as followed, the original code will send out one pixel data for each pixel clock, with the followed code update, it can send out one pixel data for each two pixel clock, of cource you should use 720*480 frame buffer and update other display timing parameters too, and the pixel clock should keep at 27MHz:

    /* Active Pixel */

    _ipu_di_sync_config(ipu,

      disp,   /* display */

      DI_SYNC_APIXEL,   /* counter */

      0,   /* run count  */

      DI_SYNC_CLK, /* run_resolution */

      h_start_width + h_sync_width,  /* offset  */

      DI_SYNC_CLK,  /* offset resolution */

      width,   /* repeat count  */

      DI_SYNC_ALINE,   /* CNT_CLR_SEL  */

      0,   /* CNT_POLARITY_GEN_EN  */

      DI_SYNC_NONE,  /* CNT_POLARITY_CLR_SEL */

      DI_SYNC_NONE,  /* CNT_POLARITY_TRIGGER_SEL  */

      0,   /* COUNT UP  */

      0  /* COUNT DOWN */

      );

To

    /* Active Pixel */

    _ipu_di_sync_config(ipu,

      disp,   /* display */

      DI_SYNC_APIXEL,   /* counter */

      0,   /* run count  */

      DI_SYNC_CLK * 2, /* run_resolution */

      h_start_width + h_sync_width,  /* offset  */

      DI_SYNC_CLK,  /* offset resolution */

      width,   /* repeat count  */

      DI_SYNC_ALINE,   /* CNT_CLR_SEL  */

      0,   /* CNT_POLARITY_GEN_EN  */

      DI_SYNC_NONE,  /* CNT_POLARITY_CLR_SEL */

      DI_SYNC_NONE,  /* CNT_POLARITY_TRIGGER_SEL  */

      0,   /* COUNT UP  */

      0  /* COUNT DOWN */

      );

Do you think so - about the doubling the clock?

You say that

      DI_SYNC_CLK * 2, /* run_resolution */

will double the clock but

DI_SYNC_NONE = -1,
DI_SYNC_CLK = 0,
DI_SYNC_INT_HSYNC = 1,
+DI_SYNC_COUNT_1 = 1,
DI_SYNC_HSYNC = 2,
DI_SYNC_VSYNC = 3,
-DI_SYNC_DE = 5,
+DI_SYNC_AFIELD = 4,
+DI_SYNC_ALINE = 5,
+DI_SYNC_APIXEL = 6,
+DI_SYNC_COUNT_7 = 7,
+DI_SYNC_COUNT_8 = 8,
+DI_SYNC_COUNT_9 = 9,

so finally no change is applied after multiplying DI_SYNC_CLK*2 :-/

Currently I am fighting with having two CLK cycles (@27MHz) for one pixel. Still no luck. Did you get any luck on your side?

Best regards!

Sorry, I don't have ready code for double pixel clock mode. But from IPU point of view, I think it can be supported.

Last days I've been trying to make it working but didn't succeed nor found any traces of such support in PDF :/ Maybe I am just a weak in getting such details from PDFs...
Please let us know if you make it working :smileywink:
Best regards!

Hello,

After applying the interlaced patches I encountered issues while trying to perform HDMI compliance testing for interlaced modes. The first issue appears to be with the 4th patch. With the 4th patch applied the HDMI output will generate an invalid field every other field. It appears that one of the lines is cut short at the end of the field. Once this patch is reverted the remaining issue appears to be that the H to V offset is invalid. When operating in 1080i@60 we get an H to V value of 1001 and 1 depending on the field. These should be 1000 and 0 since the VSYNC should happen during the same clock cycle as the HSYNC. I've tried manipulating various parameters of the IPU timing generation signals but havent found a way to correct the H to V offset. Any ideas?

Thanks,

Jon

Small correction to my previous post. The H/V values we're seeing are 1101/1 and they should be 1100/0.

Hi honchaps, the issue had been fixed with new "0004-Update-IPU-DI-for-active-field-signal-in-interlace-d.patch". Please check it.

Hello Qiang Li,


Unfortunately there still appears to be an issue. This patch doesn’t have the same issues the previous “patch 4” had, but it still has a problem where the VSYNC signal is offset by one pixel clock from where it should be. The CEA-861 specification states that the VSYNC should be perfectly aligned with the HSYNC signal plus or minus zero pixel clocks for field 1. For field 2 the VSYNC should be Htotal/2 pixel clocks from the leading edge of the HSYNC signal plus or minus zero pixel clocks. In both cases the VSYNC is 1 pixel clock too late.


Thanks,

Jon

Hi Jon, please try the "0004-IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch", from my measurement, the signal is same as CEA-861-D specification.

Hello,

I am trying this set of patches on 3.14.52 kernel. it seems to work ok apart for the fact that HDMI device (TV) each ~2-3s reports loss of a signal. Turns off. Then immediately finds the signal and turns back on.

On a couple different HDMI displays I've tried it works ok. Only this one 1 TV out of 3 behaves in such a way. I would have thought that it is a problem of TV but at the same time the same TV works with other interlaced video source devices without any problems.

This behaviour happens with all three interlaced modes I've tried: 1080i@50, 576i, 480i. Progressive modes do not cause isses.

Any ideas what can be wrong here and what parameters can I try to change?

For HDMI, maybe some interlaced information should also be updated in the AV frame header, but I don't have detail information for it.

I add the Linux3.0.35 patch for imx6, but HDMI interlace display(1080I50) shaking. How do I make it normal?

Version history
Last update:
‎04-23-2014 08:19 PM
Updated by: