Patch to Support BT656 and BT1120 Output For i.MX6 BSP

cancel
Showing results for 
Search instead for 
Did you mean: 

Patch to Support BT656 and BT1120 Output For i.MX6 BSP

No ratings

Patch to Support BT656 and BT1120 Output For i.MX6 BSP

Here are two patches to support BT656 and BT1120 output for i.MX6 ipuv3. With this patch, the i.MX6 can support the CVBS output on TV encoder. It is useful for a TV box.

"L3.0.35_1.1.0_GA_bt656_output_patch.zip" is the patch for Freescale L3.0.35_1.1.0_GA_iMX6DQ BSP.

"r13.4.1_bt656_output_patch.zip" is the patch for Freescale Android R13.4.1 BSP.

1. Features supported:

    1) Support BT656(8 bits) and BT1120 (16 bits)interlaced output on display port.
    2) Support both RGB and YUV frame buffer for BT656/BT1120 output.
    3) Support PAL and NTSC mode.
    4) Support on the fly switch between PAL and NTSC mode.
    5) Support CVBS output based on adv7391 TV encoder.

2. Hardware link between iMX6 and adv7391 TV encoder chip.
    IPU1_DI0_DISP_CLK connected to adv7391 CLKIN pin.
    IPU1_DISP0_DAT_23~DISP0_DAT_16 connected to adv7391 P7~P0 pins.
    IPU1_DI0_PIN2 connected to adv7391 HSYNC pin. (option)
    IPU1_DI0_PIN4 connected to adv7391 VSYNC pin. (option)
 
- Android R13.4.1 kernel.


3. How to use

-- Copy the two patch files to kernel folder.
    $ git apply ./0001-Support-BT656-and-BT1120-output-for-iMX6-ipuv3.patch
    $ git apply ./0002-Support-adv739x-TV-encoder-for-BT656-output.patch

-- Select them in kernel config and build the new kernel image:
                    Device Drivers  --->
                      Graphics support  --->
                          [*]   MXC BT656 and BT1120 output
                          [*]   ADV7390/7391 TV Output Encoder

-- Uboot parameters for video mode
   Output BT656 NTSC data to display port with UVYV frame buffer mode:
      "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=UYVY16"

   Output BT656 NTSC data to display port with RGB565 frame buffer mode:
      "video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=RGB565"

   Output BT656 PAL data to display port with RGB24 frame buffer mode:
      "video=mxcfb0:dev=bt656,BT656-PAL,if=BT656,fbpix=RGB24"

   Output CVBS NTSC signal on adv7391 with UYVY frame buffer mode:
      "video=mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=UYVY16"

   Output CVBS PAL signal on adv7391 with RGB565 frame buffer mode:
      "video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565"

-- Switch between PAL and NTSC
   $ echo D:720x480i-60 > /sys/class/graphics/fb0/mode
   $ echo D:720x576i-50 > /sys/class/graphics/fb0/mode


4. Note
    1) For 8 bits BT656 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_16", it can also
       be any other continued display data pins, for example if "DISP0_DAT_7~DISP0_DAT_0" are used, the
       macro "BT656_IF_DI_MSB" in "kernel_imx/drivers/mxc/ipu3/ipu_disp.c" should be changed from "23"
       to "7".

    2) For 16 bits BT1120 interface, the default data pins are "DISP0_DAT_23~DISP0_DAT_8", it can also
       be any other continued display data pins, the macro "BT656_IF_DI_MSB" should be modified if the
       hardware pins are changed.

    3) When bt656 interface is the second display for each IPU,1-layer-fb (it can be checked with command
       "$ cat /sys/class/graphics/fbx/fsl_disp_propperty"), the frame buffer can only be YUV format. In this
       case, the IPU DC channel was used for BT656 display, it has no CSC function, so RGB frame buffer was
       not supported.

2013-08-09 updated:

The new release package "L3.0.35_1.1.0_GA_bt656_output_patch_2013-08-09.zip" had fixed the BT656 dual display issue on iMX6S/DL.

Removed the old release package.

2013-09-04 updated:

The new release package "r13.4.1_bt656_output_patch_2013-09-04.zip" had fixed the BT656 dual display issue on iMX6S/DL.

For default, the dual display was tested with HDMI + CVBS, HDMI is the main display and adv739x CVBS output is the second display.

For iMX6DQ which has two IPUs, please assign dual display to two IPUs, for example adv739x is on IPU1 DI0, it is fixed, because hardware pins used for it is fixed. Then we can assign HDMI or LVDS to another IPU (IPU2).

For iMX6S/DL which has only one IPU, since adv739x had used IPU1 DI0, another display should be IPU1 DI1.

2013-09-30 updated:

Added patch for L3.0.35_4.1.0_GA BSP, the file is "L3.0.35_4.1.0_GA_bt656_output_patch_2013-09-30.zip".

2014-07-21 updated:

Added patch for L3.10.17_1.0.0_GA BSP, the file is "L3.10.17_1.0.0_GA_bt656_output_patch_2014-07-21.zip".

2015-01-26 updated:

Updated the IPU microcode for 1080i50 and 1080i60 BT1120 output, the parameters "N" for command BMA is a 8 bits parameters, so its max value is 255, but for 1080i50 and 1080i60 output, it needs more blank data in each line, the "N" will be bigger than 255, the updated IPU microcode can fix this limitation.

The updated file is "IPU_Microcode_Update_for_BT1120_1080i_20150126.zip". You can update the macro "DC_MCODE_BT656_xxx"  and function _ipu_dc_setup_bt656_interlaced() to the old patch if you used BT1120 mode to support 1080i display.

The verified 1080i display mode is:

{

   /* 1080I60 Interlaced output */

  "BT1120-1080I60", 30, 1920, 1080, 13468,

  20, 3,

  20, 2,

  280, 1,

  FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,

  FB_VMODE_INTERLACED,

  FB_MODE_IS_DETAILED,},

{

  /* 1080I50 Interlaced output */

  "BT1120-1080I50", 25, 1920, 1080, 13468,

  20, 3,

  20, 2,

  720, 1,

  FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,

  FB_VMODE_INTERLACED,

  FB_MODE_IS_DETAILED,},

2016-01-28 updated:

Updated IPU microcode to align with BT656.4 specification for NTSC output. For other BSP version with NTSC format support, please reference to ipu_disp_update.c for the final microcode.

File "L3.0.35_4.1.0_GA_bt656_output_patch_20160128.zip"., Details, please reference to the readme.txt file in the package.

2016-06-24 update:

Added BT656 and BT1120 progressive mode support.

File "L3.0.35_4.1.0_GA_bt656_output_patch_20160624.zip". Details, please reference to the readme.txt file in the package.

The patch for 3.14.52 GA1.1.0 BSP will be released in next week.

2016-06-27 update:

Add BT656 and BT1120 display patch for 3.14.52 BSP. File "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27.zip", details, please reference to the readme.txt in the package.

2017-03-10 update:

Fixed a hard coding DC macro issue for progressive mode. Added patch "0008-Fixed-a-hard-coding-DC-macro-issue-for-progressive-m.patch" in L3.0.35_4.1.0_GA_bt656_output_patch_2017-03-10.zip.

The code in patch "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27" is correct.

Attachments
Comments

hi,qiang,

Thank you for your quick reply!

I have solved the problem.

the third display is closed,I must turn on it

Hi Qiang_FSL

Is it possible to move the bt656 output to fb4?

The use case is a 3 displays system. 2 displays will be rendering video, hence overlay framebuffer is needed for HMI content.

The display with bt656 is not intended for videoplayback so no overlay is needed.

Display 1 -->  fb0 (background)  fb1(overlay)

Display 2 -->  fb2 (background)  fb3(overlay)

Display 3 -->  fb4 (bt656)

Hi Qiang,

Is it possible to modify the microcode by user?

(If it can be modified, how is it possible to change microcode?)

In case of applying a changed microcode to BSP, is it possible to apply by replacing some file?

Best Regards,

Keita

Yes, you can, for example (HDMI is IPU1 DI1 display, LVDS is IPU2 DI1 display):

video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb2:dev=adv739x,BT656-NTSC,if=BT656,fbpix=UYVY16

Note, in this case, since IPU DP had been used by another two layer display, the BT656 display's frame buffer must be YUV format, there is no on the fly CSC from RGB to YUV on BT656 display.

Yes, you can study and understand the code in ipu_disp.c, function _ipu_dc_setup_bt656_interlaced(), the related IPU microcode commands can be found from iMX6 reference manual: Table 37-26. DC template's commands description.

hi qiang,

now i can use CVBS+LVDS+HDMI the same time ,use this command:

setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb1:dev=ldb,LDB-SVGA,if=RGB24 ldb=sin0 video=mxcfb2:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565' 

that the CVBS is the fb0 device.

when i want the CVBS to the fb2 device,use this command:

setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb0:dev=ldb,LDB-SVGA,if=RGB24 ldb=sin0 video=mxcfb1:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb2:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565'

I start the board,it stop in the kernel,that's the log:

..................................

.................................

JFFS2 version 2.2. (NAND)  2001-2006 Red Hat, Inc.
msgmni has been set to 2822
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
mxc_sdc_fb mxc_sdc_fb.0: register mxc display driver ldb
_regulator_get: get() with no identifier
mxc_ldb mxc_ldb: change IPU DI1 to IPU DI0 for LDB channel0.
imx-ipuv3 imx-ipuv3.1: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7)
Console: switching to colour frame buffer device 128x48
mxc_sdc_fb mxc_sdc_fb.1: register mxc display driver hdmi
mxc_hdmi mxc_hdmi: Detected HDMI controller 0x13:0xa:0xa0:0xc1
fbcvt: 1920x1080@60: CVT Name - 2.073M9
mxc_sdc_fb mxc_sdc_fb.2: register mxc display driver adv739x  (stop here and not continue)

what 's the problem?

Can you give me some advice?

Hi Qiang,

I appreciate for your great support.

Let me clarify my understanding about "r13.4.1_bt656_output_patch_2013-09-04.zip".

My customer attached this patch and modify the code to apply their custom board with i.MX6DQ.

But, the frame buffer for overlay was not created with the influence of the custom modification.

As the result. It wasn't possible to work.

Is it necessary the frame buffer for overlay to output BT.656?

(They tried to create the frame buffer, It could work correctly. So, we think that it is needed.)

[read me.txt in "r13.4.1_bt656_output_patch_2013-09-04.zip"]

>    4) In iMX6S/DL Android, there is only one IPU, in this case, the BT656 output should be the second display,

>       the 0003-Enhance-dual-display-support-for-BT656-output.patch will assign IPU DC channel to main display,

>       and BT656 will use IPU DP as fb2, the overlay will be fb1.

Best Regards,

Keita

For iMX6DQ, since there are two IPUs, you can assign BT656 and other display to two IPUs. There is no such limitation for dual display case.

Dear Qiang,

Thank you for your reply.

My customer tried to change the other IPU from current IPU for LVDS out.

Their code was skipped the "ret = mxcfb_setup_overlay(pdev, fbi, res);" at the changing to "ipu_id = 1".

They added the frame buffer creation, LVDS out could change the another IPU and output to display.

Best Regards,

Keita

hi

I use imx6sx and L3.10.53_1.1.0-ga Yocto.

I am patching to support BT656. but I have problem.

In mxc_ipuv3_fb.c, I add these in mxcfb_set_par func. ( static int mxcfb_set_par(struct fb_info *fbi)  )

        if ((mxc_fbi->ipu_di_pix_fmt == IPU_PIX_FMT_BT656) || (mxc_fbi->ipu_di_pix_fmt == IPU_PIX_FMT_BT1120)) {

                 if (mxc_fbi->dispdrv && mxc_fbi->dispdrv->drv->disable)

                         mxc_fbi->dispdrv->drv->disable(mxc_fbi->dispdrv);

        }

result of compile:

drivers/video/mxc/mxc_ipuv3_fb.c:510:4: error: too few arguments to function 'mxc_fbi->dispdrv->drv->disable'

    mxc_fbi->dispdrv->drv->disable(mxc_fbi->dispdrv);

    ^

make[3]: *** [drivers/video/mxc/mxc_ipuv3_fb.o] Error 1

so, I found "disable func " in mxc_dsipdrv.h

33 struct mxc_dispdrv_driver {

34         const char *name;

35         int (*init) (struct mxc_dispdrv_handle *, struct mxc_dispdrv_setting *);

36         void (*deinit) (struct mxc_dispdrv_handle *);

37         /* display driver enable function for extension */

38         int (*enable) (struct mxc_dispdrv_handle *, struct fb_info *);

39         /* display driver disable function, called at early part of fb_blank */

40         void (*disable) (struct mxc_dispdrv_handle *, struct fb_info *);

41         /* display driver setup function, called at early part of fb_set_par */

42         int (*setup) (struct mxc_dispdrv_handle *, struct fb_info *fbi);

43 };

disable's function pionter has two arg. but  In patch, has one arg.

How do I resolve that?

Um... Is it right that I revise  below ?

       if ((mxc_fbi->ipu_di_pix_fmt == IPU_PIX_FMT_BT656) || (mxc_fbi->ipu_di_pix_fmt == IPU_PIX_FMT_BT1120)) {

                 if (mxc_fbi->dispdrv && mxc_fbi->dispdrv->drv->disable)

                         mxc_fbi->dispdrv->drv->disable(mxc_fbi->dispdrv, fbi );

Thank you for reading.

Hi moowon, you can't use this patch, because iMX6SX has no IPU hardware.

thank you for your response !!

Dear Qiang,

     I use imx6q and L3.14.28 Yocto.

    Do you have patches to support BT656 and BT1120  based on adv7391 TV encoder?

    Best Regards!

I think you need porting it, but the IPU microcode can be re-used directly, it is not kernel version related.

Dear Qiang Li,

We have applied your patch to jb4.2.2_1.1.0.

So, I think that the color space is converted from RGB to BT.656 in CSC function.

Refer to 37.4.9.5 Color Space Conversion unit - CSC in IMX6DQRM (Rev.2).

Could you tell me the conversion coefficient value of the color space (CSC_A0~A8, CSC_B0~B2, CSC_S0~2)?

(We couldn't dump the register by debugger.)

Best Regards,

Keita

You can find it in drivers/mxc/ipu3/ipu_disp.c

/*     Y = R *  1.200 + G *  2.343 + B *  .453 + 0.250;

       U = R * -.672 + G * -1.328 + B *  2.000 + 512.250.;

       V = R *  2.000 + G * -1.672 + B * -.328 + 512.250.;*/

static const int rgb2ycbcr_coeff[5][3] = {

{0x4D, 0x96, 0x1D},

{-0x2B, -0x55, 0x80},

{0x80, -0x6B, -0x15},

{0x0000, 0x0200, 0x0200}, /* B0, B1, B2 */

{0x2, 0x2, 0x2}, /* S0, S1, S2 */

};

Dear Qiang Li,

Thank you very much!

Keita

Hi Li Qiang:

     After I applied this patch , CVBS can display OK, but screen blink (blink on the top of screen) when white color in the right of the screen.

test case :  gst-launch-1.0 videotestsrc horizontal-speed=-3 ! imxv4l2sink

And other case is the same issue (play a video file use gplay and gst-play) when white color in the right of the screen.

Any idea to solve this problem ?

Thanks !

Please make sure the function _ipu_dc_setup_bt656_interlaced() had been updated to last version L3.0.35_4.1.0_GA_bt656_output_patch_20160128

By the way, I haven't seen such issue.

hi qiang,

   I use a YUV LCD (the interface is YUV) TFTMD030011 , 8bit BT656 NTSC mode.  the patch is 27MHZ , but the LCD must be 54MHZ  :

QQ图片20160325164915.png

I found the https://community.freescale.com/message/443002#comment-443002  ,you said :

For 8 bits BT656 interface, NTSC mode, the pixel clock is 27MHz.

    For each line, calculated in pixel clock count: Total 1716 clocks = EAV code(4) + Blanking Video(67*4) + SAV code(4) + Active Video(720*2) = 276 + 1440, in NTSC mode, there are total 525 lines (19+240+3+20+240+3) for each frame, and frame rate is 30Hz, so the pixel clock frequency = 525 * 1716 * 30 =  27.027MHz.

Now,I want to configure the refresh to 60HZ, so the pixel clock frequency will be 525 * 1716 * 60 =  54.054MHz.

how should i configure the bsp bt656 code ?

Hi Wilson, your LCD is BT656 progressive mode, it can't be supported by this patch, you'd better use VSYNC/HSYNC mode for that panel.

hi,qiang,

Can you give me some advice to let the imx6 to support BT656 progressive mode ?

Or what's the means about " use VSYNC/HSYNC mode for that panel." ?

I must use this LCD.please some help

To support BT656 progressive mode, you need create an IPU microcode like _ipu_dc_setup_bt656_interlaced() which can create embeded EAV/SAV code into data line for BT656 progressive mode.

For VSYNC/HSYNC mode, it means there no EAV/SAV data on data line, only video data are sent on data line, all timing signals are sent on VSYNC and HSYNC pins.

hi qiang,

"create an IPU microcode like _ipu_dc_setup_bt656_interlaced()" is to hard for me.

do you help the plan to support the BT656 progressive mode?

We have a joint project with D-Chip...need a progressive mode instead of a interlace mode..I checked the Reference Manual v4..it mentioned on section 37.4.6.2.1, progressive mode is supported by hardware. My question is, would you please confirm, hardware is OK for this, but firmware can not support this mode yet?

If we want to make a patch for this target, do you have some suggestions, or some instruction sheet to change it?

My contact is, abelcao2012us@gmail.com

Thanks a lot..

Abel

Progressive mode IPU mocricode is under development now, it will be ready at about July.

Thanks for your efforts!

Very expect

Hi Qiang,

I apologize if this is a dumb question, but why do I not see any patches for the adv739x driver for the 3.14.52 kernel?

Thanks!

Hi Qiang,

     Whether  iMX6S/DL support double  adv739x simultaneous?

Gordon Lin

iMX6S/DL can't support two BT656 output. For each BT656 output, the IPU need use 142 DC words logic to generate the signal. But on each IPU, there are total 256 DC words, so it is not enough to generate two BT656 signal.

Dear Qiang Li,

Hi, I have a question about PAL-NTSC mode switching of the imx6 board. When we set uboot first for let's say BT656-NTSC (so adv outputs NTSC), can we change the mode to BT656-PAL without changing uboot parameters and rebooting ? I think ADV7391 has different i2c settings for different timing doesn't it ?

Thanks

Anuradha

Hi, is this on-the fly switching possible to perform between two lcd entries defined in mxc_lcdif.c ? i.e. switching between PAL and NTSC timing modeS ?

Yes, it is supported.

List all supported modes:

# cat /sys/class/graphics/fb0/modes

Switch the mode:

# echo D:720x480i-60 > /sys/class/graphics/fb0/mode

Thanks for your reply Qiang ! I have two questions. Now when running RGB signals with TV encoder (let's assume this is assigned to fb0), can we use vivante acceleration to this frame buffer ? i.e (fb0 is for RGB and fb2 for HDMI) :

Section "Device"
      Identifier "i.MX Accelerated Framebuffer Device"
      Driver "vivante"
      Option "fbdev" "/dev/fb0"
      Option "vivante_fbdev" "/dev/fb0"
      Option "HWcursor" "false"
EndSection

Section "Device"
      Identifier "Framebuffer Device2"
      Driver "fbdev"
      Option "fbdev" "/dev/fb2"
      Option "HWcursor" "false"
EndSection

When I set like this, the pixel clock of the encoder gets a different value. Which means I cannot use accelerated frame buffer for the encoder ?

Thanks in Advance

Did you check if the xserver had set display mode to the fb0? If so, maybe the mode is not correct which caused BT656 display fail to work.

And in xserver code, such as xserver-xorg-video-imx-viv-3.10.53-1.1.0\EXA\src\vivante_fbdev\imx_display.c

For default, it doesn't support interlaced display mode, you need remove that code as followed:

ModeStatus
imxDisplayValidMode(VALID_MODE_DECL)
{
#ifndef XF86_SCRN_INTERFACE
 ScrnInfoPtr pScrn = xf86Screens[arg];
#else
 ScrnInfoPtr pScrn = arg;
#endif

- if (mode->Flags & V_INTERLACE) {
-  if (verbose) {
-   xf86DrvMsg(pScrn->scrnIndex, X_PROBED,
-       "Removing interlaced mode \"%s\"\n",
-       mode->name);
-  }
-  return MODE_BAD;
- }
 return MODE_OK;
}

Dear Qiang, 

I can run pipelines with imxg2dvideosink and autovidiosinks on encoder output. When running imxeglvivsink, the display doesn't come up. When debug mode is on in the pipeline, I get the message, 'cannot open X window'. 

Since g2d and auto work, i guess Xserver setup for encoder display should be okay right ? In which directory we can access above source code ? If it has to be changes, then do we need to compile X11 vivante drivers from scratch ?

Thanks in Advance

Hi Aneradha, not sure for autovideosinks, but the g2d sink has no depends to Xserver.

If you need Xserver for interlaced display, that modification is needed. You can also switch the framebuffer to BT656 progressive to try and double confirm it.

Can you please kindly tell me in which location I can find this source code ?  Thanks

If you are using Yocto, the package can be found at "downloads/xserver-xorg-video-imx-viv-xxxxxx.tar.gz"

Hi, you were right about g2dsink, it does not require X11 support. I made the changes you suggested at imx_display.c ! but I am getting following error when running gst test patterns with imxeglvivsink !

0:00:00.139761000 492 0x1b6cda0 ERROR imxeglplatform_x11 egl_platform_x11.c:90:gst_imx_egl_viv_sink_egl_platform_create: could not open X display

My TV only supports interlaced PAL and NTSC. What else can cause this issue ?

Anuradha

As I mentioned, you need modify the code in downloads/xserver-xorg-video-imx-viv-xxxxxx.tar.gz to make X11 support interlaced display.

Hi Qiang, now I am getting the following output on TV display. I already mentioned that I had modified xorg files in my previous comment :smileyhappy:

pastedImage_3.jpg

The horizontal lines shown on the upper side of the LCD are from imxeglvivsink. So now the pipeline works with imxeglvivsink, no errors of X11. But why the video is corrupted ? I'm wondering whether I have missed something, apart from what you mentioned. I can run test sources with imxg2dsink and imxipuvideosink without any distortion ! 

Btw could you please kindly share your xorg.conf file settings ? 

Thanks 

for xrandr -q, I only get following modes and info :

Screen 0: minimum 240 x 240, current 800 x 600, maximum 8192 x 8192
DISP3 BG connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
U:800x600p-60 60.00*
U:480x800p-57 80.32
U:800x480p-57 57.00
U:800x480p-60 60.00 60.00
U:480x800p-60 60.00
U:720x480p-60 60.00
U:640x480p-60 85.67
U:1280x120p-60 123.84

So I used following settings :

export DISPLAY=:0.0
xrandr --newmode "1440x480i-60" 27 1440 1403 1459 1716 480 481 483 500 interlace +hsync +vsync
xrandr --addmode "DISP3 BG" 1440x480i-60
xrandr --output "DISP3 BG" --mode 1440x480i-60

And then :

echo U:1440x480i-60 > /sys/class/graphics/fb0/mode

Can you please verify whether my xrandr settings look okay ? I have no issue running this without X11 acceleration. So i assume this must be an issue of xrandr settings ! Any insight would be appreciated !

Thanks 

Dear Qiang,

I solved the issue by setting correct xrandr display timings for DISP3 BG, and now lcd works fine. But I still have a question.

Using this xrandr commands, I was able to set the interlace mode settings for TV encoder without introducing an interlace mode in mxc_lcdif ! Does mxc_lcdif mode only affects frame buffer devices ? When mode is set through x11, no need to introduce modes ?

Thanks in Advance

Anuradha

Dear Qiang,

    How to increase VSYNC wave width in BT656 interlace mode?

VSYNC and HSYNC signals are not supported.

How to support external HSYNC and VSYNC for BT656?

The followed is an example code to generate VSYNC and HSYNC signals for BT656 progressive mode. The HSYNC width is 20 pixel clocks, and the VSYNC width is 10 HSYNC width. For BT656 interlaced mode, since it has two fields, it is difficult to support VSYNC and HSYNC signals.

diff --git a/drivers/mxc/ipu3/ipu_disp.c b/drivers/mxc/ipu3/ipu_disp.c
index 4dfb194..1d71447 100644
--- a/drivers/mxc/ipu3/ipu_disp.c
+++ b/drivers/mxc/ipu3/ipu_disp.c
@@ -3123,11 +3123,11 @@ int32_t ipu_init_sync_panel(struct ipu_soc *ipu, int disp, uint32_t pixel_clk,
   _ipu_di_sync_config(ipu,
     disp,   /* display */
     DI_BT656_SYNC_HSYNC,   /* counter */
     h_total - 1,  /* run count */
     DI_SYNC_CLK, /* run_resolution */
     0,   /* offset */
      DI_SYNC_NONE,  /* offset resolution */
      0,   /* repeat count */
      DI_SYNC_NONE,  /* CNT_CLR_SEL */
-     0,   /* CNT_POLARITY_GEN_EN */
+     1,   /* CNT_POLARITY_GEN_EN */
      DI_SYNC_NONE,  /* CNT_POLARITY_CLR_SEL */
-     DI_SYNC_NONE,  /* CNT_POLARITY_TRIGGER_SEL */
+     DI_BT656_SYNC_BASECLK,  /* CNT_POLARITY_TRIGGER_SEL */
      0,   /* COUNT UP */
-     0  /* COUNT DOWN */
+     2*20  /* COUNT DOWN */
      );
 
    vsync_cnt = DI_BT656_SYNC_IVSYNC;

   /* COUNTER_3: VSYNC for each frame */
   _ipu_di_sync_config(ipu,
     disp,   /* display */
     DI_BT656_SYNC_IVSYNC,   /* counter */
     v_total - 1,  /* run count */
     DI_BT656_SYNC_HSYNC, /* run_resolution */
     0,    /* offset */
      DI_SYNC_NONE,  /* offset resolution */
      0,   /* repeat count */
      DI_SYNC_NONE,  /* CNT_CLR_SEL */
-     0,   /* CNT_POLARITY_GEN_EN */
+     1,   /* CNT_POLARITY_GEN_EN */
      DI_SYNC_NONE,  /* CNT_POLARITY_CLR_SEL */
-     DI_SYNC_NONE,  /* CNT_POLARITY_TRIGGER_SEL */
+     DI_BT656_SYNC_HSYNC,  /* CNT_POLARITY_TRIGGER_SEL */
      0,   /* COUNT UP */
-     0  /* COUNT DOWN */
+     2*10  /* COUNT DOWN */
      );
 
    /* COUNTER_5: first active line */

I have three questions below:

       1. As you reply before, this patch can't support progressive well, if other change or patch are necessary?

       2. After we use this patch, and test BT656 PAL interlace mode, we can measure external HSYNC on DI0_PIN2, and external VSYNC on DI0_PIN4, and the frequency is right, but pulse width is too small(only 1 pixel clock).

       3. Our backend need the VSYNC can keep one or two HSYNC period, not only some pixel period. How to config?  

1. The progressive patch had been added here at 2016-06-24.

2. Sample code to adjust pulse width had been given. I haven't tuned the BT656 interlaced mode VSYNC and HSYNC signals, you can try it by yourself.

3. I had shown you the sample code.

Version history
Revision #:
1 of 1
Last update:
‎02-01-2013 12:22 AM
Updated by: