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.
You can remove the other displays from device tree:
&mxcfb3 {
status = "disabled";
};
&mxcfb4 {
status = "disabled";
};
No patch is needed, if you are using iMX6DQ, which has two IPU, you just need assign the two BT656 displays to two IPUs. Then in kernel command line, add two video mode for them:
video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=RGB32 video=mxcfb1:dev=bt656,BT656-NTSC,if=BT656,fbpix=RGB32
If it is iMX6S/DL which has only one IPU, it can't support such use case, because there is no enough space in CPMEM to run two BT656 microcode in one IPU.
Qiang_FSL Dear Qiang，do we have a patch to support dual BT656 display?
Hi,
Somebody already ported the patch to kernel 4.9.123?
I tried to port this but got stuck. At boot I got a kernel panic saying "Failed set parent clk"
After comparing the source I found out there are some things changed to the clk initialization in the new kernel, compared to 4.1.15.
Clint
If you need HDMI to support different resolutions, then it has to use PLL5 alone. If your HDMI just need support some special resolution, then you can set PLL5 to a fixed frequency, and let BT1120 and HDMI to generate pixel clock from it. For example, if PLL5 is 594MHz, it can support 1080P HDMI (148.5MHz pixel clock) + BT1120 (74.25MHz pixel clock) together.
Except the programable PLL5, the IPU_DI clock source can be followed:
mmdc_ch0_axi 528MHz
pll3_usb_otg 480MHz
pll2_pfd0_352m
pll2_pfd2_396m
pll3_pfd1_540m
Hi yan zhang
The I2C interface is the only interface iMX6 will read from adv7391, so I think you need check the I2C signal in -40 degree case, maybe the drive stregth for the I2C pins need be increased.
yes, I think so, if you need to use mxcfb1, thy to set in the uboot command. for restriction, ipu can support up to 240M. for pixel clock set, you can refer to the patch and source code in the bsp cleanmaster.
Hi Qiang ,
Where can I get the patch for the IPU output the parallel video format YUV422 8bit with Hsync Vsync DE Pclk signals ?
Hello All,
I too need this patch for L4.1.15.
Has anybody got this?
Ian
Hello everyone.
I would like to try this patch.
Where can I obtain the original source file to which patches can be applied?
I tried two source files, but I get an error.
https://github.com/embeddedarm/linux-3.0.35-imx6-android
https://github.com/ADVANTECH-Corp/linux-imx6
Thank you for your support.
Any news on the availability of the patch for L4.1.15?
If I have to port it on my own, what would be the best starting point? L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27.zip?
Best regards
Martin
We also use 4.1.15 and need the patch for this version.
Hi, Qiang
We're using Linux 4.1.15 on IMX6Q platform, and do you have patch for Linux 4.1.15?
Or some patch here for Linux 3.x can also be used for Linux 4.1.15?
Thanks for your help.
For that interlaced display patch, you can use such kind of double clock mode.
I had tested on parallel LCD, for a 800*480 display, I can set the framebuffer to 400*480, and use that kind of double clock mode, the display can work fine.
Mm.... strange, if you check the link you gave me,
Patch for iMX6 BSP to support interlaced display on HDMI and LCD interface
in 4th comment you've mentioned DI_SYNC_CLK * 2, /* run_resolution */ should work. That's why I asked about it.
Anuradha
For BT656 mode, it is already two pixel clock to send out one pixel data. And this patch will not work with your "DI_SYNC_CLK * 2, /* run_resolution */" modification.
Hi, what is your idea about dual clock mode. Can I achieve this using DI_SYNC_CLK * 2, /* run_resolution */ ?
Thanks
Just simply doing this, can we get 2 clocks per pixel :
/* 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 */
);
Hello Qiang,
So in this TV encoder, 16-bit mode requires 2 clock cycles per pixel. Is it available under BT1120 mode in ipu_disp.c ? How to set the number of clock cycles required for pixel in ipu files ?
Thanks
Anuradha
Display interface and framebuffer format can be different, just like the BT656 output, on display interface, it is 8 bits UYVY data, but in framebuffer, it can be RGB565, RGB32 ... ...
Hi thanks for your reply. Can fbpix be RGB in UYVY16 interface mode ? I noticed in mxc_ipuv3_fb.c, always the fb pixel format is YUYV or UYVY for UYVY16 interface !!
Hi Anuradha,
For 16-bit YCbCr with HSYNC and HSYNC, you can reference to this patch:
https://community.nxp.com/docs/DOC-100657
video=mxcfb0:dev=lcd,LCD-1080i50,if=UYVY16,fbpix=RGB32
"if=UYVY16" means 16-bit YCbCr with HSYNC and HSYNC output mode. You can add your own timing mode to replace the "LCD-1080i50" mode, the default BSP can't support UYVY16 mode output, it is enabled in that patch.
For "RGB pixel format for BT656 8-bit mode", it can be supported too, you can use the DC for display, then no CSC, and the RGB data in framebuffer can be sent to 8 bit LCD interface directly.
Hi Qiang-Li,
I use ADV7342 chip as a TV encoder which can also accept 16 bit pixel bus (16-bit YCbCr input). Anyway it does not support EAV/SAV, so I plan to use external VSYNC and HSYNC for that. Can I use BT1120 mode for this ? If yes what would be the pixel format for the frame buffer ?
fb_lcd{
if_fmt = BT1120;
if_pixel_fmt = ?
}
Moreover can we use an RGB pixel format for BT656 8-bit mode ?
Thanks in Advance
You can use the BT656 progressive mode to output the 720P display, then use the followed patch to generate VSYNC on DI_PIN3 and HSYNC on DI_PIN2.
In the patch, the VSYNC width is hardcoding as 10 HSYNC (2*10 /* COUNT DOWN */), and the HSYNC width is hardcoding as 80 pixel clocks (2*80 /* COUNT DOWN */), you can modify them as you wanted:
diff --git a/arch/arm/mach-mx6/clock.c b/arch/arm/mach-mx6/clock.c
index 2d5b497..d2d9556 100644
--- a/arch/arm/mach-mx6/clock.c
+++ b/arch/arm/mach-mx6/clock.c
@@ -5556,7 +5556,8 @@ int __init mx6_clocks_init(unsigned long ckil, unsigned long osc,
clk_set_rate(&pll4_audio_main_clk, 176000000);
clk_set_rate(&pll5_video_main_clk, 650000000);
- clk_set_parent(&ipu1_di_clk[0], &pll3_pfd_540M); /* For CVBS 27MHz clock */
+// clk_set_parent(&ipu1_di_clk[0], &pll3_pfd_540M); /* For CVBS 27MHz clock */
+ clk_set_parent(&ipu1_di_clk[0], &pll5_video_main_clk);
clk_set_parent(&ipu1_di_clk[1], &pll5_video_main_clk);
clk_set_parent(&ipu2_di_clk[0], &pll5_video_main_clk);
clk_set_parent(&ipu2_di_clk[1], &pll5_video_main_clk);
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
@@ -2600,13 +2600,13 @@ int32_t ipu_init_sync_panel(struct ipu_soc *ipu, int disp, uint32_t pixel_clk,
} else if ((pixel_fmt == IPU_PIX_FMT_BT656) || (pixel_fmt == IPU_PIX_FMT_BT1120)) {
pixel_clk = pixel_clk / 10000;
pixel_clk = pixel_clk * 10000;
- if (pixel_clk < 74000000) {
- rounded_pixel_clk = 108000000; /* For PAL and NTSC */
-
- clk_set_rate(di_parent, 540000000);
- clk_set_rate(ipu->di_clk[disp], rounded_pixel_clk);
- clk_set_parent(&ipu->pixel_clk[disp], ipu->di_clk[disp]);
- } else {
+// if (pixel_clk < 74000000) {
+// rounded_pixel_clk = 108000000; /* For PAL and NTSC */
+//
+// clk_set_rate(di_parent, 540000000);
+// clk_set_rate(ipu->di_clk[disp], rounded_pixel_clk);
+// clk_set_parent(&ipu->pixel_clk[disp], ipu->di_clk[disp]);
+// } else {
rounded_pixel_clk = pixel_clk * 2;
rounded_parent_clk = clk_round_rate(di_parent,
rounded_pixel_clk);
@@ -2622,7 +2622,7 @@ int32_t ipu_init_sync_panel(struct ipu_soc *ipu, int disp, uint32_t pixel_clk,
clk_round_rate(ipu->di_clk[disp], pixel_clk);
clk_set_rate(ipu->di_clk[disp], rounded_pixel_clk);
clk_set_parent(&ipu->pixel_clk[disp], ipu->di_clk[disp]);
- }
+// }
} else {
/* try ipu clk first*/
dev_dbg(ipu->dev, "try ipu internal clk\n");
@@ -3123,11 +3123,11 @@ int32_t ipu_init_sync_panel(struct ipu_soc *ipu, int disp, uint32_t pixel_clk,
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*80 /* COUNT DOWN */
);
vsync_cnt = DI_BT656_SYNC_IVSYNC;
@@ -3142,11 +3142,11 @@ int32_t ipu_init_sync_panel(struct ipu_soc *ipu, int disp, uint32_t pixel_clk,
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 */
diff --git a/drivers/video/mxc/mxc_bt656if.c b/drivers/video/mxc/mxc_bt656if.c
index 0ad5dee..800ac42 100644
--- a/drivers/video/mxc/mxc_bt656if.c
+++ b/drivers/video/mxc/mxc_bt656if.c
@@ -44,6 +44,7 @@ struct mxc_bt656if_data {
* vsync_len: not used, set to 1
*/
static struct fb_videomode bt656if_modedb[] = {
+#if 0
{
/* NTSC Interlaced output */
"BT656-4-NTSC", 60, 720, 487, 37037,
@@ -161,6 +162,52 @@ static struct fb_videomode bt656if_modedb[] = {
FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
FB_VMODE_NONINTERLACED,
FB_MODE_IS_DETAILED,},
+#endif
+ {
+ /* NTSC Progressive output */
+ "BT656-480P", 60, 720, 480, 20833,
+ 36, 9,
+ 0, 0,
+ 276, 1,
+ 0,
+ FB_VMODE_NONINTERLACED,
+ FB_MODE_IS_DETAILED,},
+ {
+ /* PAL Progressive output */
+ "BT656-576P", 50, 720, 576, 20833,
+ 44, 5,
+ 0, 0,
+ 288, 1,
+ 0,
+ FB_VMODE_NONINTERLACED,
+ FB_MODE_IS_DETAILED,},
+ {
+ /* 1280x720 Progressive output */
+ "BT656-720P", 60, 1280, 720, 20833,
+ 25, 5,
+ 0, 0,
+ 732, 1,
+ 0,
+ FB_VMODE_NONINTERLACED,
+ FB_MODE_IS_DETAILED,},
};
static int bt656if_modedb_sz = ARRAY_SIZE(bt656if_modedb);
嗨，Hi Qiang
感谢你的工作，我们按照这个文章打了L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27这个补丁，BT656交错模式下工作正常。
目前我们有新的需求，想通过8位数据线+CLK+VSYNC+HSYNC输出720P的UYVY数据，拟使用引脚如下：
pinctrl_ipu1_bt656: ipu1grp-3 {
fsl,pins = <
MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15 0x10
MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x10
MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x10
MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04 0x80000000
MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x10
MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17 0x10
MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18 0x10
MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19 0x10
MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20 0x10
MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21 0x10
MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22 0x10
MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23 0x10
>;
};
我们的疑问是，在本文补丁下，是否可以支持这么操作，我们该如何配置相关资源？可以给出一些指导意见，谢谢！
Yes, it can.
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".
Dear Sir,
customer ask about hardware connect pads between i.MX6 and ADV7391.
Could use IPU1_DISP0_DAT_23~DISP0_DAT_16 connected to adv7391 P7~P0 pins?
Please help confirm it.
Thanks a lot,
We checked NXP TV box reference design .i.MX6 OTT TVBox HW/SW Reference Design Release (ICS4.0.4_1.0.0-alpha)
P7~P0 pins of ADV7390 is connect i.MX6 IPU_DISP_Data0~7.
We checked the patch in https://community.nxp.com/docs/DOC-94019
Meanwhile find some code about setting DISP_DAT23 ~ DISP_DAT16 or DISP_DAT7 ~ DISP_DAT0 to output “8 bits BT656”
Hi all,
Did anyone try to get PAL out of an ADV7393 chip? NTSC works perfectly, thanks for the effort.
However, PAL seems to be harder on me. I modified the kernel video= boot argument to show PAL. When starting gstreamer test pattern generator, i do get graphics on my PAL monitor. It does, however, seem confused wjth tining somehow. The image seems to flicker, sometimes some grey raster seems to be under the color bars and from the second half, i get the impression that a new frame starts overlapping. The behavior is equally unstable but presents itself somewhat differently on another PAL television I have.
Would this ring a bell for someone?
Thanks a lot
Hi llinguo, you can apply the patch "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27", then porting the adv739x driver from L3.0.35_4.1.0.
Hi Qiang
Our BSP version is 3.4.52.I want to download the patch "L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27",but i don't find the driver of adv7393.
Can I download the patch "L3.0.35_4.1.0_GA_bt656_output_patch_2017-03-10",then add this patch in the BSP 3.14.52?
Dear @qiang Li,
I have a question on xserver settings, for the below mode :
/* NTSC Interlaced output */
+ "BT656-NTSC", 60, 720, 480, 37037,
+ 19, 3,
+ 20, 3,
+ 276, 1,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+ FB_VMODE_INTERLACED,
+ FB_MODE_IS_DETAILED,},
what should be the correct xserver mode settings ? The issue is I cannot get the accelerated frame buffer output to fb0 !!!
The 20833 is just a reference setting for pixel clock, you can adjust it.
With the 20833, pixel clock frequency = 10^12 / 20833 = 48MHz, for 60fps setting, the pixel clock should be 148.5MHz, so 20833 should be 6734.
How many pixel clocks for one frame: (1280*2 + 732) * (720 + 25 + 5) = 2469000; so the display refresh rate = 148.5M / 2469000 = 60fps.
Dear Qiang,
How to calculate the pclk in 720p mode?
10^12 /((1280*2+25+5+732)*(720+0+0+1)) is not equal 20833
Thanks a lot! I will try it.
diff --git a/drivers/video/mxc/mxc_bt656if.c b/drivers/video/mxc/mxc_bt656if.c
index 0ad5dee..800ac42 100644
--- a/drivers/video/mxc/mxc_bt656if.c
+++ b/drivers/video/mxc/mxc_bt656if.c
@@ -44,6 +44,7 @@ struct mxc_bt656if_data {
* vsync_len: not used, set to 1
*/
static struct fb_videomode bt656if_modedb[] = {
+ {
+ /* 1280x720 Progressive output */
+ "BT656-720P", 60, 1280, 720, 20833,
+ 25, 5,
+ 0, 0,
+ 732, 1,
+ 0,
+ FB_VMODE_NONINTERLACED,
+ FB_MODE_IS_DETAILED,},
};
static int bt656if_modedb_sz = ARRAY_SIZE(bt656if_modedb);
Dear Qiang,
Thank you very much!
I have one question at last, how to add a config for 720p(1280x720) output?
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.
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?
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 */
How to support external HSYNC and VSYNC for BT656?
VSYNC and HSYNC signals are not supported.
Dear Qiang,
How to increase VSYNC wave width in BT656 interlace mode?
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
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
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 
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
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, 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
If you are using Yocto, the package can be found at "downloads/xserver-xorg-video-imx-viv-xxxxxx.tar.gz"
Can you please kindly tell me in which location I can find this source code ? Thanks
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.
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
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;
}
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
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
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 ?
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
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.
Hi Qiang,
Whether iMX6S/DL support double adv739x simultaneous?
Gordon Lin
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!
Thanks for your efforts！
Very expect
Progressive mode IPU mocricode is under development now, it will be ready at about July.
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, [email protected]
Thanks a lot..
Abel
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?
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,
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
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,
I use a YUV LCD (the interface is YUV) TFTMD030011 , 8bit BT656 NTSC mode. the patch is 27MHZ , but the LCD must be 54MHZ :
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 ?
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 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 !
Dear Qiang Li,
Thank you very much!
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,
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
I think you need porting it, but the IPU microcode can be re-used directly, it is not kernel version related.
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!
thank you for your response !!
Hi moowon, you can't use this patch, because iMX6SX has no IPU hardware.
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.
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
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.
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
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?
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.
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.
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
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,
Thank you for your quick reply!
I have solved the problem.
the third display is closed,I must turn on it
For multi display resoure assignment, except the clock, the board file should also be checked. You can reference to How to config four-screen display -blog archive
Each IPU can support two display device with three frame buffer, fb1 is the overlay.
I search the arch/arm/mach-mx6/clock.c
I found :
int __init mx6_clocks_init(unsigned long ckil, unsigned long osc,
| clk_set_parent(&ipu1_di_clk[0], &pll3_pfd_540M); /* For CVBS 27MHz clock */ | |
| clk_set_parent(&ipu1_di_clk[1], &pll5_video_main_clk); | |
| clk_set_parent(&ipu2_di_clk[0], &pll5_video_main_clk); | |
clk_set_parent(&ipu2_di_clk[1], &pll5_video_main_clk); clk_set_parent(&ldb_di0_clk,&pll2_pfd_352M); clk_set_parent(&ldb_di1_clk,&pll2_pfd_352M); |
BT656 on IPU1 DI0, HDMI on IPU2 DI0,LVDS on IPU2 DI1。
above is ok?
i also found other problem:
when i use:
setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565 video=mxcfb1:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb2:dev=ldb,LDB-SVGA,if=RGB24 ldb=sin0'
if i want to draw green colors to the hdmi,i must use" ./fb_green /dev/fb2 " ,but not the " ./fb_green /dev/fb1".
why?
I search the arch/arm/mach-mx6/clock.c
I found :
int __init mx6_clocks_init(unsigned long ckil, unsigned long osc,
| clk_set_parent(&ipu1_di_clk[0], &pll3_pfd_540M); /* For CVBS 27MHz clock */ | |
| clk_set_parent(&ipu1_di_clk[1], &pll5_video_main_clk); | |
| clk_set_parent(&ipu2_di_clk[0], &pll5_video_main_clk); | |
clk_set_parent(&ipu2_di_clk[1], &pll5_video_main_clk); clk_set_parent(&ldb_di0_clk,&pll2_pfd_352M); clk_set_parent(&ldb_di1_clk,&pll2_pfd_352M); |
BT656 on IPU1 DI0, HDMI on IPU2 DI0,LVDS on IPU2 DI1。
above is ok?
i also found other problem:
when i use:
setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565 video=mxcfb1:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb2:dev=ldb,LDB-SVGA,if=RGB24 ldb=sin0'
if i want to draw green colors to the hdmi,i must use" ./fb_green /dev/fb2 " ,but not the " ./fb_green /dev/fb1".
why?
You should pay attention to clock source and IPU DI port assignment:
For example:
BT656 on IPU1 DI0, clock source pll3_pfd_540M.
HDMI on IPU2 DI0, clock source pll5_video_main_clk.
LVDS on IPU2 DI1, clock source pll2_pfd_352M.
hi,qiang,
I use the linux rootfs.
when I use the command:
setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565 video=mxcfb1:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb2:dev=ldb,LDB-SVGA,if=RGB24 ldb=sin0'
I can draw something to the CVBS and HDMI ,this is work. but the lvds cannot,when I draw something to it's frame buffer ,nothing can see .
also when I use this command:
setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565 video=mxcfb2:dev=ldb,LDB-SVGA,if=RGB24 ldb=sin0 video=mxcfb1:dev=hdmi,1920x1080M@60,if=RGB24 '
I can draw something to the CVBS and LVDS display.but the hdmi cannot.
what's the problem.
You need draw something to third display's frame buffer and unblank it. If you are using Android, the android framework supports two displays default.
HI,Qiang.
I want to use CVBS+HDMI+LVDS, but only when CVBS+HDMI or CVBS+LVDS could work,the thirth display cannot display anything.
how can I do?
Hi Qiang,
We found the violation of BT.656 specification about F bit(field1/field2), V bit, H bit(SAV/EAV).
I send you the result of analysis about violation of BT.656 specification by e-mail.
[Q1]
Is it possible to fix the patch to comply BT.656?
(I want your answer asap.)
[Q2]
If Q1 yes, when will you release the fixed patch?
Best Regards,
Keita
I send you the result of analysis about violation of BT.656 specification.
Yes, the SAV and EAV is same as BT656 specification.
Hi Qiang,
Thank you for your quick reply!
I have one more question.
Does this patch support the Video timing reference code [F bit(field1/field2), V bit, H bit(SAV/EAV)] of BT.656?
Best Regards,
Keita
Hi Keita, I think HIZ should be OK for your use case. You can also try on your current board to check if there is still BT656 signal output after HIZ setting.
Hi Qiang,
Now, our system can work the BT.656 output correctly in jb4.2.2_1.1.0 by your patch.
And, we are considering the dual output source to single display for next product model.
(i.e we would like to change the video source i.MX6 or HDMI Rx.)
Refer to below system image.
[Question]
Q1.
By the setting of DSE=Hi-z, is it possible to cut the bus of i.MX6 and HDMI Rx?
(We would like to judge the whether or not external bus switcher is necessary.)
Q2.
Is the any special processing necessary except for DSE setting?
Best Regards,
Keita
It causes some flickering and distortions in the display output for time to time (once every few seconds). We think the PLL in the display module fails to derive the input clock and gets out of sync when it receives many consecutive zeros which happens during vertical blanking and this causes the flickering and sudden "jumps" in the display output.
Yes, you are right, for that blanking, we just let the data line keep in last data state. Will this impact your display?
Hi Qiang,
I am getting sudden "jumps" in the output video.
Using an FGPA to probe the display output, it seems the data during vertical blanking is not valid. Here is a screenshot: http://i.imgur.com/3wvuZFB.png
Note the 000 and 2AC values during vertical blanking. I think it should be 200 and 040 respectively.
The configuration I am using is BT1120-1080I50.
HI Qiang,
I'm running kernel 3.10.17 on iMX6Q with ADV7391.
unzip "L3.10.17_1.0.0_GA_bt656_output_patch_2014-07-21.zip"
but only get "0001-Support-BT656-and-BT1120-output-for-iMX6-ipuv3.patch"
Should i use ADV7391 patch? Where i can find the patch?
Can i use old version "0002-Support-adv739x-TV-encoder-for-BT656-output.patch" of "L3.0.35_1.1.0_GA_bt656_output_patch_2013-08-09.zip" ?
Thanks,
Darren
For iMX6Q, I think it can support two BT656 output, each IPU run one BT656 output. But I haven't tried such use case.
Hi,
is it possible to have 2 separate BT.656 video outputs for SD PAL CVBS video (clk + 8 data lines, EAV/SAV, ADV7391)?
No other video outputs are required.
We are using Yocto with freescale kernel 3.10 on i.MX6Q automotive.
Which pins should we connect the 2 ADV7391 to?
Which patch or driver should we use?
Regards,
Mario
HI Qiang
Can you answer me a question about Nand flash?
Hi Qiang, I have this setup -
ipu1 disp0 = lcd
ipu1 disp1 = Not used
ipu2 disp0 = hdmi
ipu2 disp1 = Mipi Display
After applying the patch the contents of the Mipi display is corrupted when I start playback on the HDMI output. LCD not used in this test scenario. Any ideas on what it could be ? I'm using L3.10.17_1.0.0_GA
Any hints would be appreciated
Thanks,
/Otto
Hi Qiang Li,
Thanks for this patch. I couldn't apply it to my kernel automatically (Bluechip Technology's Yocto Layer) so made the changes by hand. It works nicely using mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=RGB24 and running mxc_v4l2_tvin.out set with an NTSC camera. But with PAL settings there is a flickering almost like the interlace order is wrong. I've also had the occasional IPU errors:
imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_5 = 0x00000001
imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00080000
Once difference I've noticed between PAL and NTSC is in mxcfb_adv739x.c, adv739x_modedb has FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT set for NTSC and not PAL. Is this correct?
Thanks in advance
Jamie Whitham
HI Qiang:
when do you update BT656 and BT1120 progressive support?
The manual without obvious setting BT1120 progressive mode,I try to understand your patch, but I don't understand why you are so set the DC and DI register,Can you give me some advice and how to set up BT1120 progressive ?
How to understand Microcode ？
Hi Isaac, there is no such plan, for progressive mode, another IPU microcode was needed, like the function _ipu_dc_setup_bt656_interlaced(), it is not a easy task, based on my experience, it needs about 6 weeks to implement such a code.
So if you need it, I think you can check with Freescale marketing people wether it can be supported in software service way.
Hi Qiang,
Any update on BT656/BT1120 progressive mode?
We also have a tight deadline. If there isn't a schedule for the patch yet, can you provide some general description on what should be done in this patch?
Hi Casper, you can port it from the current Linux patch, it is very simple since they are based on the same kernel version.
Hi Qiang,
Where I can find ADV7393 or BT656 patch for android-4.4.2_r1 ?
Thanks,
For 1, no BT656 and BT1120 progressive support.
For 2, yes.
For 3, the default BSP doesn't support YUV output, you can reference to "https://community.freescale.com/docs/DOC-100657" to add UYVY16 output on LCDIF, that patch was tested on 16bits LCD interface with UYVY16 1080i output in VSYNC and HSYNC mode.
HI Qiang:
1.Do you update this patch to the BT1120 1080p now?
2.I have to use the HSYNC, VSYNC for the 1080p,because this patch don't support BT1120 1080p.I use the mxc_lcdif.c for my driver, is right?
3.if I use the mxc_lcdif.c for my driver, dose it support YUYV16? Or just support RGB?
4.Please help me to answer this question is"IPU DI LCD HDMI LVDS".
please,thanks !
Is there any plan to port to u-boot to support splash screen?
hi,Qiang,
There is two question for you,my env is as follow:
platform: imx6q
linux : linux3.0.35
1.I want to use ipu1 for lvds in split mode(1080p) and use ipu2's DI0 for HDMI,and use ipu2's DI1 for BT656. Does the imx6q suport it?
2. what's the relation between mxcfb0/maxcfb1/mxcfb2(dev=mxcfb0/mxcfb1/mxcfb2 in bootarg) and ipu1/ipu2?
Best Regards.
wangzg
Hello Qiang,
May we know more detail about "default LCD interface driver"?
Yes.
Hi Qiang,
Thank you for your reply. Let me clarify my understanding.
>so for 720P output, please use VSYNC/HSYNC output mode.
Is this meaning the default RGB data output with clock, HSYNC, VSYNC (not BT.656 and BT.1120)?
Best Regards,
Keita
Hi Keita, IPU microcode for progressive mode hasn't been implemented in this patch, so for 720P output, please use VSYNC/HSYNC output mode.
Hi Qiang,
Is it possible to output the below dual display (BT.656 and BT.1120 simultaneously)?
- IPU2 DI0 --> BT.656 w/1280 x 720p@30fps
- IPU1 DI1 --> BT.1120 w/1280 x 720p@60fps
BR,
Keita
Hi Qiang,
I'm finding the i.MX6Q code to capture the BT656 progressive mode 720P from Camera Input.
I found your patch, but I knew the patch was just for the interlaced mode not for progressive mode and just for video output.
Do you have any update for progressive mode of IPU CSI?
Best Regards,
Eric.
good
Hi Qiang Li
I use the BSP of LTIB to develop our project.The kernel release is L3.0.35_4.1.0.But it dose not have the driver of BT1120.Does the patch of L3.0.35_4.1.0_GA_bt656_output_patch can use for LTIB.
Thank you.
Hi Qiang_FSL, There is an issue reported here Distorted Video i.MX6 gStreamer
after this patchset is applied.
The issue is that, if the movie being played has exactly the same resolution from the display, the playback is corrupted.
I was not able to reproduce the same issue when using the 3.10.17-ga release. So it seems that this is caused by some patch from this patchset.
Can you, please, help me on this?
Two limitations for the patch:
1. The android can only support RGB frame buffer, so "fbpix=UYVY16" can't be used in Android.
2. For single IPU system, only DP channel can support CSC from RGB frame buffer to YUV BT656 interface, so in the default patch, the BT656 was designed as second display, when frame buffer driver initializing, DC channel will be assigned to fb0, and DP channel will be assigned to fb1.
So if the customer used BT656 as fb0, they need recover the modification in function mxcfb_probe(), and use "fbpix=BGR32" for BT656 output.
if (((mxcfbi->ipu_di_pix_fmt == IPU_PIX_FMT_BT656) || (mxcfbi->ipu_di_pix_fmt == IPU_PIX_FMT_BT1120)) && (mxcfbi->ipu_id == 0) && cpu_is_mx6dl())
{
/* first user uses DC */
Change to
if (0)
{
/* first user uses DC */
Is it okay to modify drivers/video/mxc/mxc_ipuv3_fb.c as below for i.MX6 Solo?
Original
if (((mxcfbi->ipu_di_pix_fmt == IPU_PIX_FMT_BT656) || (mxcfbi->ipu_di_pix_fmt == IPU_PIX_FMT_BT1120)) && (mxcfbi->ipu_id == 0) && cpu_is_mx6dl())
Modified
if (((mxcfbi->ipu_di_pix_fmt == IPU_PIX_FMT_BT656) || (mxcfbi->ipu_di_pix_fmt == IPU_PIX_FMT_BT1120)) && (mxcfbi->ipu_id == 0) && !(cpu_is_mx6dl()))
Customer found the screen will turn green if run on i.MX6 Solo with below kernel parameter. Is there anything we need to check?
bootargs=console=ttymxc3,115200 init=/init nosmp no_console_suspend video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=UYVY16 video=mxcfb1:off video=mxcfb2:off gpumem=96M fbmem=10M vmalloc=400M androidboot.console=ttymxc3 androidboot.hardware=freescale
Hi Qiang,
Is there any patch available for supporting 1080p output from MX6Q LCD port?
Or do you know any in-progress work about it?
No, only interlaced mode was supported, for progressive mode, you can use the default LCD interface driver with VSYNC and HSYNC.
Does it support 480P?
Thank you very much.
I'll try MXCFB_SET_FBFMT
After applied the patch to Linux BSP, the frame buffer can support YUV format, but if application only set bpp 16 to framebuffer driver, there will be problem, the driver can't know it is RGB565 or UYVY16, both of them are 16 bpp. In this case, you should use ioctl "MXCFB_SET_FBFMT" to set the framebuffer format.
By the way, if you are using iMX6Q which has two IPUs, then you don't need support the YUV format frame buffer, because you can assgn the second IPU's DP channel to BT656/BT1120 display, it can support RGB frame buffer to YUV BT656/BT1120 display converting. In this case, you can un-mask the followed line in mxc_ipuv3_fb.c, function mxcfb_set_par(), then fbset will work as normal:
// mxc_fbi->fb_pix_fmt = bpp_to_pixfmt(fbi->var.bits_per_pixel); // If the OS(such as Android) can only support RGB framebuffer, un-mask this line.
The limitation only happens on iMX6S/6DL which has only one IPU, and you need support dual display, in this case, if BT656/BT1120 was assigned as second display, then IPU DC channel will be assigned to it, for this IPU DC channel, it can't support RGB frame buffer to YUV BT656/BT1120 converting, so the frame buffer must be YUV format. Then the fbset will not work. It should be replaced with MXCFB_SET_FBFMT.
Hi Li
My English is not good enough to explain the question I want to ask。
I guess you are Chinese from your name. I'll use Chinese to explain the question.
If you don't know Chinese. I'll try my best to explain it in English.
现状:
正常在使用过程中，如果想更改fb0的格式，可以直接使用fbset -g 1024 768 1024 768 32的命令来完成。
我做了两套环境，A.使用patch之前，B.使用patch之后。
在这两个环境中，我做这些操作，启动实机当前fb0为16位，启动某UI程序，关闭UI程序，fbset更改为32位，再次启动UI程序。
A环境中，通过fbset更改fb0格式前后，启动的UI程序，显示都正常。
B环境中，通过fbset更改fb0格式前，显示正常，更改后，显示不正常。将更改后的fb0的数据通过cat语句dump到文件中，
在PC上查看，显示为正常的32位数据，实机画面显示效果为宽度拉伸了2倍的效果。
如果通过uboot启动参数中，bpp=32来设置fb0，启动后32位显示正常，但是fbset更改16位以后，16位显示不正常。
总结的问题为，无法在实机启动以后，去更改fb0格式。
分析：
查看了一部分patch的代码，发现启动有对实机启动以后，更改fb格式的代码。如果uboot参数中，没有定义一些变量，那么无法更改fb格式。
但是具体更改哪些变量，我不太清楚。
问题：
1 这个现象在你的环境中是否存在？
2 如果想在实机启动后更改fb格式，如何进行？
3 如果无法在实机启动后更改fb格式，是否为bug，如何解决？
多谢Li Qiang。
Hi Li
Thanks for your hearful answer.
以上です、どうも宜しくお願い致します。
The internal SYNC and external SYNC are just the name, if we don't ouput these signals from IPU DI pins, they are just internal signal, if we enabled output from IPU DI PINs for them, they will be external signal too.
Hi Li
Sorry for disturbing you again.
As the question just like I took above.
I can see thes two comments
1, /* COUNTER_2: HSYNC for each line */
2, /* COUNTER_3: internal VSYNC for each frame */
My apologies, I am a newer about BT.656 and IPU.
Could you please tell me, HSYNC/VSYNC which set by function ipu_init_sync_panel（）. are internal SYNC or External SYNC?
The patch was verified on iMX6S board too, the use case without external HSYNC/VSYNC is the only workable case for this patch, external VSYNC and HSYNC mode hasn't been fine tuned.
I think you should check your hardware for which data pins are used for the BT656 interface, and add the IOMUX setting for these pins.
Hi Li
Thanks for your such useful patch to the iMX6 about BT656 functions.
But here I have a problem about the patch into iMX6S customer board with AK8817 encoder chip.
1, Using no external HSYNC/VSYNC, just with BT656 itself . iMX6S can not send correct BT656 signal to AK8817
source like bellow
//-----------------------------------------------------------------------------------
/driver/video/mxc/mxc_bt656if.c
static struct fb_videomode bt656if_modedb[] = {
{
/* NTSC Interlaced output */
"BT656-NTSC", 60, 720, 480, 37037,
19, 3,
20, 3,
276, 1,
FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
FB_VMODE_INTERLACED,
FB_MODE_IS_DETAILED,},
......
......
};
//------------------------------------------------------------------------------------
/drivers/mxc/ipu3/ipu_disp.c
/* COUNTER_2: HSYNC for each line */
/* COUNTER_2: HSYNC for each line */
_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 */
DI_SYNC_NONE, /* CNT_POLARITY_CLR_SEL */
DI_SYNC_NONE, /* CNT_POLARITY_TRIGGER_SEL */
0, /* COUNT UP */
2*div /* COUNT DOWN */
);
/* COUNTER_3: internal 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 */
DI_SYNC_NONE, /* CNT_POLARITY_CLR_SEL */
DI_SYNC_NONE, /* CNT_POLARITY_TRIGGER_SEL */
0, /* COUNT UP */
0 /* COUNT DOWN */
);
2, Using external HSYNC/VSYNC, just with BT656 itself . iMX6S can send correct BT656 signal to AK8817
//-----------------------------------------------------------------------------------
/driver/video/mxc/mxc_bt656if.c
static struct fb_videomode bt656if_modedb[] = {
{
/* NTSC Interlaced output */
"BT656-NTSC", 60, 720, 480, 37037,
19, 3,
20, 3,
276, 1,
0,
FB_VMODE_INTERLACED,
FB_MODE_IS_DETAILED,},
......
......
};
//------------------------------------------------------------------------------------
/drivers/mxc/ipu3/ipu_disp.c
/* COUNTER_2: HSYNC for each line */
/* COUNTER_2: HSYNC for each line */
_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 */
DI_SYNC_NONE, /* CNT_POLARITY_CLR_SEL */
DI_SYNC_NONE, /* CNT_POLARITY_TRIGGER_SEL */
0, /* COUNT UP */
20*div /* COUNT DOWN */
);
/* COUNTER_3: internal 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 */
DI_SYNC_NONE, /* CNT_POLARITY_CLR_SEL */
DI_SYNC_NONE, /* CNT_POLARITY_TRIGGER_SEL */
0, /* COUNT UP */
2*div /* COUNT DOWN */
);
Could you please tell me, how to make correct BT656 signals from iMX6 to AK8817 without external HSYNC/VSYNC ?
When use patch on iMX6 Sabre board, there is no such problem.
Hi Qiang,
I've been using this patch for some time with 3.0.35 and am now updating to the 3.10.17_1.0.0_beta kernel. Are you planning on creating a patch for that kernel? Why is this support not part of the Freescale BSP?
Thanks,
Tim
PLL5 clock has been changed, clk_set_rate(&pll5_video_main_clk, 297000000);. I get the same results. I also tried to run the clock using PLL3 at 27MHz, just to see what would happen. This also gave me 50MHz. Is it possible that something is overriding the clock definitions?
Hi Josh, you can set pll5 to 297MHz for 74.25MHz pixel clock.
I am setting clk_set_parent(&ipu1_di_clk[0], &pll5_video_main_clk); In the line directly above this one I am setting the clock rate as clk_set_rate(&pll5_video_main_clk, 650000000); (line 5458). Is this the correct value to set PLL5 in order to achieve a 74.25MHz clock? I have also uploaded my kernel dmesg log to pastebin.com: imx6 dmesg for BT.1120 - Pastebin.com. I do not see anything directly defining any video settings. Could you tell me what I should be looking for? Lastly, should I move this question to a new thread? It is starting to become long. Thank you.
The google drive can't be accessed from China, I had tried your video mode on my SabreSD board, it can get the 74.25MHz pixel clock correctly. Of cource, ipu1_di0 clock should be sourced from PLL5.
By kernel boot log do you mean dmesg? This is a link to dmesg when BT1120-1080I60 is set: https://drive.google.com/file/d/0B1-NpS0YmbqNZEJJeDFvNFNwTGs/edit?usp=sharing
I am also attaching a file named /var/log/boot: https://drive.google.com/file/d/0B1-NpS0YmbqNZXJRbW90X054c28/edit?usp=sharing
Can you attach your kernel boot log?
With BT1120-1080I60 set using the recommended u-boot parameters, the output of /sys/class/graphics/fb0/mode is D:1920x1080i-30. I believe this is the correct setting, but the clock is still running at 50MHz. For BT1120-1080I50 I get D:1920x1080i-25. I am running this on a SabreLite and a Wandboard quad; I do not have a SabreSD board. I made the necessary additions to the board-xxx.c and defconfig files. Can this patch be applied to ALL imx6 boards, or is it specific to the SabreSD?
I think you should check if the correct mode had been used or not?
$ cat /sys/class/graphics/fb0/mode
Thanks for the response. I copied the 1080i modes to the bottom of struct fb_videomode bt656if_modedb[] in mxc_bt656if.c and modified the u-boot parameters, but I am not getting the correct clock. Before I load the kernel (still in uboot) the pixel clock is good at 74.25MHz. After I load the kernel,the pixel clock is stuck at 50MHz. Also I do not see anything on the HSYNC and VSYNC pins. Is that supposed to happen or is that a sign something else is wrong? In arch\arm\mach-mx6\clock.c I have clk_set_parent(&ipu1_di_clk[0], &pll5_video_main_clk);. Is their anything else I have to set? I back-ported the patch to run on kernel 3.0.35_4.0.0. Are you aware of any conflicts that might occur with this?
Thank you,
Josh Kurland
If you just need iMX6 generate BT1120 signal, you can just add the 1080i video mode in file mxc_bt656if.c.
The uboot parameters can be "video=mxcfb0:dev=bt656,BT1120-1080I60,if=BT1120,fbpix=UYVY16" or "video=mxcfb0:dev=bt656,BT1120-1080I60,if=BT1120,fbpix=RGB565". There is no 1080P support for BT1120 mode yet, but you can use VSYNC/HSYNC mode to support 1080P.
I am also interested in BT.1120 1080 capability. Could you explain how to include this support into the kernel a little further? I am using Yocto with kernel 3.0.35_4.0.0.
I have already changed the clock source back to 75MHz, but I do not know where to add the BT1120 parameters. Should it be placed in drivers/video/mxc/mxc_bt656if.c? I imagine the boot parameters would look something like mentioned above (video=mxcfb0:dev=bt656,BT1120-PAL-1080i,if=BT1120,fbpix=UYVY16). Is this correct? Lastly, is their any support for 1080p?
Thank you,
Josh Kurland
Checked with BT1120-8 protocol, I think you can try the followed parameter for 1080I60 and 1080I50:
{
/* 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,},
HI li :
i change the clock source on clock.c . and use :setenv bootargs console=ttymxc0,115200 init=/init rw video=mxcfb0:dev=bt656,BT1120-PAL-1080i,if=BT1120,fbpix=RGB565 . but my screen ids no signal. you have said the margin data:
{
/* PAL Interlaced output */
"BT1120-PAL-1080i", 25, 1920,1080, 13468,
148, 484,
36, 4,
88, 5,
FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
FB_VMODE_INTERLACED,
FB_MODE_IS_DETAILED,},
i guess is this parameter is error. The patch code is no 1080i format, thoes code about 1080i may be wrong,can your provide a 1080i parameter for me。
Thanks
kai
In clock.c, the current clock setting is for 27MHz NTSC and PAL mode, for 1080i, you need the 74.25MHz clock, so you should change the clock source in clock.c.
From
clk_set_parent(&ipu1_di_clk[0], &pll3_pfd_540M); //for CVBS 27MHz clock
To
clk_set_parent(&ipu1_di_clk[0], &pll5_video_main_clk);
By the way, audio data is not transfered on BT1120 interface, so the audio issue should be the TV chip's issue, non business with BT1120 driver. No matter what, you should not change the margin data in the video mode, those data is for BT656/BT1120 protocol.
Hi li :
Thanks for your reply, that is a previous questions：i need sabresd board output parallel yuv4:2:2 display, thanks for your help ,720P format display is OK . but you konw the interlaced is not support,
i communitcte with the TV encoder fae，the chip is support the bt1120 mode,i used your patch ,the 576i format is display ok(but not audio, chip is not support well on bt1120 mode). this TV chip fae let me test 1080i format ,may be have audio，so i added the above code ,but the 1080i is not well,the screen is black. my screen have nothing and then ask for your help. i guess the parameter is error.
and i always think the left_margin right_margin etc through SAV and EAV in display data is not well. and maybe because of this protocol data the audio can not insert the display data( on this chip the audio is insert on display data gaps). But anything is to project.
so can you support the parameter about 1080i， mxc_bt656if.c is only have 576i parameter.
Beat Regard
kai
Hi sun, that driver can only support BT1120 mode 1080i, and the left_margin, right_margin, up_margin, down_margin in video mode is protocol data, they can't be changed.
You also need make sure your TV encoder chip can support BT1120 input.
Dear li:
how to achieve 1080i? i add some code on mxc_bt656.c .but my screen not display.
add some code like it:
{
/* PAL Interlaced output */
"BT1120-PAL-1080i", 25, 1920,1080, 13468,
148, 484,
36, 4,
88, 5,
FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
FB_VMODE_INTERLACED,
FB_MODE_IS_DETAILED,},
does some parameter is error?
Beat Regards
kai
The HSYNC and VSYNC pins are already enabled by the patch, they will output from DI0_PIN2 and DI0_PIN4.
Since BT656 mode doesn't need VSYNC and HSYNC, these signals haven't been checked, just reserved.
The followed DI config code are for them:
/* COUNTER_2: HSYNC for each line */
_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 */
DI_SYNC_NONE, /* CNT_POLARITY_CLR_SEL */
DI_SYNC_NONE, /* CNT_POLARITY_TRIGGER_SEL */
0, /* COUNT UP */
2*div /* COUNT DOWN */
);
/* COUNTER_4: VSYNC for field1 only */
_ipu_di_sync_config(ipu,
disp, /* display */
DI_BT656_SYNC_VSYNC, /* counter */
0, /* run count */
DI_BT656_SYNC_HSYNC, /* run_resolution */
bt656_v_start_width_field0 + height / 2 + bt656_v_end_width_field0, /* offset */
DI_BT656_SYNC_HSYNC, /* offset resolution */
1, /* repeat count */
DI_BT656_SYNC_IVSYNC, /* 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 */
2*div /* COUNT DOWN */
);
Dear li:
I add your patch,and use uboot parameters : video=mxcfb0:dev=bt656,BT1120-PAL,if=UYVY16,fbpix=RGB565, but the vsync is error.it is not rule.
and other question is how to change this pin:
IPU1_DI0_PIN2 connected to adv7391 HSYNC pin. (option)
IPU1_DI0_PIN4 connected to adv7391 VSYNC pin. (option)
Thanks
kai
Hi Qiang,
I create a thread to discuss my question, could you please leave your advice there, thanks.
For Android, the frame buffer must be RGB format, so for BY656 output, before sending the frame buffer data to DI port, the IPU DP will be used to convert the RGB frame buffer to YUV422 format.
If you use LCD as main display, the "0003-Enhance-dual-display-support-for-BT656-output.patch" will assign IPU DC for LCD, which has no hardware CSC and assign IPU DP to adv7391 which can support hardware CSC.
From my test, video playback has no issue in Android on the two displays.
Hi Qiang:
i'm using imx6 dual lite ,android 4.2.2 1.1.0 BSP.and using this patch
this patch fix rear monitor cvbs output to TV_BOX 's SYNC error, and it realy woks.
but during blank opertion, your patch do retry by checking INT_STATE register, till there's no sync error.
this may cost a lot of time , and during this period, front monitor(main lcd display) is ALSO be freezed.
it's terrible. T_T
so, if any suggest or new patch, please notice us, thks.
Hi Qiang,
Since ADV7391 only support YUV 4:2:2 input, no matter what kind of frame buffer data format, the BT656 interface output should be YUV 4:2:2 with EAV/SAV embedded, I believe BT656 driver is implemented to do so.
So, if I feel like to output Android desktop to ADV7391, what kind of data format will be filled in frame buffer? RGB,YUV or I cat assign the data format? Do I have to convert the data in frame buffer to fit YUV 4:2:2 output to ADV7391 by myself?
Furthermore, you said "I can try to paly video on it"! If I set LCD panel as main display, how to play video on ADV7391? I can't find gstream built in Android kernel, may I copy an Ubuntu version into Android kernel or any APK can achieve this?
Thanks for your kindly help.
Hi Oliver,
If you had set "fbpix=UYVY16", that means the frame buffer is in YUV format, you should draw it in YUV format. You can try to play video on it, the video playback is OK to support YUV frame buffer.
If you draw the YUV frame buffer with RGB data, there will be color issue.
Hi Qiang,
After change clock setting as you mentioned, I can see output from ADV7391 but the display color is grotesque.
Since ADV7391 uses DISP1_DAT0~7 and these pins are also shared for boot setting, there is a 10k ohm resistor pull to ground.
Would this affects ADV7391 data input accurate? Any suggestion for the hardware connection?
Really thanks for your great support.
Best regards,
Oliver
There is no confirmed schedule yet.
Address: 0x02400000 + 0x002000000 + 0x00180000: it is the IPU DC Template Memory, you can reference to reference manual "37.4.7 DC - Display Control"
Dear Qiang Lin,
When will you be able to provide it?
If you need a long time to provide the patch for progressive output, we have to create it by ourselves because our schedule is very tight.
In the case, we need a additional information about the register on the following address, because reference manual (IMX6DQRM Rev.1) doesn't provide the information about it even though the released patch access the address.
Address: 0x02400000+0x00200000+0x00180000
Could you let us know the register information?
Regards,
Satoshi
Can you check if the adv7391 IPU framebuffer driver is ready with the followed commands:
# cat /sys/class/graphics/fb0/fsl_disp_dev_property
By the way, since you are using BT656 interface on DI1 port, the arch\arm\mach-mx6\clock.c should also be adjusted:
clk_set_parent(&ipu1_di_clk[0], &pll3_pfd_540M); //for CVBS 27MHz clock
clk_set_parent(&ipu1_di_clk[1], &pll5_video_main_clk);
should be changed to:
clk_set_parent(&ipu1_di_clk[0], &pll5_video_main_clk);
clk_set_parent(&ipu1_di_clk[1], &pll3_pfd_540M); //for CVBS 27MHz clock
Hi Qiang,
After apply 3 patches in "r13.4.1_bt656_output_patch_2013-09-04.zip", I still can't make adv7391 work properly on our custom board.
We use LCD as primary display which connect to IPU1 DI0 (DISP0) and ADV7391 connect to IPU1 DI1.
I can't find DISP1's pads definition from user manual; refer to IOMUX tool and iomux-mx6dl.h we connect ADV7391 to the pads as below.
I make ADV7391 as main display to make sure it work properly, boot environment set "video=mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=UYVY16"; however no output from ADV7391 and lots of message "mxc_sdc_fb mxc_sdc_fb.0: timeout when waiting for flip irq" posted on console.
I can't measure clock output on IPU1_DI1_DISP_CLK, only 3.3V output.
ADV7391 setting:
static struct fsl_mxc_lcd_platform_data adv739x_data = {
.ipu_id = 0,
.disp_id = 1,
.default_ifmt = IPU_PIX_FMT_BT656,
};
ADV7391 IOMUX:
| /* ipu1 di1 :: CVBS out */ | |||||||
| MX6DL_PAD_GPIO_18__GPIO_7_13, | /* CVBS_OUT_RST */ | ||||||
| MX6DL_PAD_EIM_A16__IPU1_DI1_DISP_CLK, | |||||||
| //MX6DL_PAD_EIM_D29__IPU1_DI1_PIN15, | |||||||
| //MX6DL_PAD_EIM_EB3__IPU1_DI1_PIN3, | |||||||
| MX6DL_PAD_EIM_DA9__IPU1_DISP1_DAT_0, | |||||||
| MX6DL_PAD_EIM_DA8__IPU1_DISP1_DAT_1, | |||||||
| MX6DL_PAD_EIM_DA7__IPU1_DISP1_DAT_2, | |||||||
| MX6DL_PAD_EIM_DA6__IPU1_DISP1_DAT_3, | |||||||
| MX6DL_PAD_EIM_DA5__IPU1_DISP1_DAT_4, | |||||||
| MX6DL_PAD_EIM_DA4__IPU1_DISP1_DAT_5, | |||||||
| MX6DL_PAD_EIM_DA3__IPU1_DISP1_DAT_6, | |||||||
| MX6DL_PAD_EIM_DA2__IPU1_DISP1_DAT_7, |
Our target is to make LCD as primary display and ADV7391 as secondary output.
Do you have any suggestion?
Thanks for your kindly help.
Oliver
For BT656/BT1120 progressive mode, a new IPU microcode was needed, it is not ready yet.
Hi Qiang,
Do you have a similar patch for MCIMX6Q-SDP with L3.0.35_4.0.0_130424_source BSP to output "progressive" BT656/1120?
Regards,
Satoshi
In "https://community.freescale.com/thread/295157", there is some kernel code modification in V4L2 capture driver to support BT1120 capture,
although it is for iMX53 BSP, the same modification can also be applied on iMX6 BSP.
Is there a similar patch to support BT1120 for CAPTURE on imx6s?
The old patch had used pll5 as clock source for both CVBS and other display (such as lcd and hdmi), so when use dual display mode for lcd+cvbs and hdmi+cvbs, then when the second display was enabled, the first display will be impacted, because pll5 frequency will be changed by second display.
We need select different clock source for dual display. The new patch had added such code modification in arch\arm\mach-mx6\clock.c.
LVDS + CVBS output had no such isssue, because lvds clock source is not pll5.
Hi Qiang,
How about the status of dual display with BT656 output on iMX6 Solo for Android build r13.4.1?
I notice you have updated the package of Linux build on 2013-08-09, will you update Android build as well or I have to dig the patch and revise r13.4.1 accordingly by myself?
BTW, we use LCD device as primary display and ADV7391 be second, after I apply r13.4.1 patch, LCD display becomes crushing, is it caused by dual display issue you mentioned on 2013-04-15?
ADV7391 IOMUX setting:
MX6DL_PAD_EIM_A16__IPU1_DI1_DISP_CLK, MX6DL_PAD_EIM_D29__IPU1_DI1_PIN15, MX6DL_PAD_EIM_EB3__IPU1_DI1_PIN3, MX6DL_PAD_EIM_DA9__IPU1_DISP1_DAT_0, MX6DL_PAD_EIM_DA8__IPU1_DISP1_DAT_1, MX6DL_PAD_EIM_DA7__IPU1_DISP1_DAT_2, MX6DL_PAD_EIM_DA6__IPU1_DISP1_DAT_3, MX6DL_PAD_EIM_DA5__IPU1_DISP1_DAT_4, MX6DL_PAD_EIM_DA4__IPU1_DISP1_DAT_5, MX6DL_PAD_EIM_DA3__IPU1_DISP1_DAT_6, MX6DL_PAD_EIM_DA2__IPU1_DISP1_DAT_7,
Thanks,
Oliver
Hi Qiang,
We are working on an automotive project using the iMX.6 DL & iMX.6 Solo SOC with the Android 4.2 BSP.
Is it possible to use ldb as the primary display and bt656 as a second one?
I'm not using Freescale Android R13.4.1 BSP but Freescale L3.0.35_1.1.0_GA_iMX6DQ BSP....
If you are using iMX6Q which had two IPU, the BT656 is OK for dual display, you can reference to the OTT TVBox reference design, it is OK for HDMI + BT656 on IMX6Q. https://community.freescale.com/docs/DOC-94561
For iMX6S/DL, there is still some issue to enable the dual display with BT656 support, this update will be released at the end of July.
You mean that this patch still not working? I'm using this on a sabrelite board with iMX6Quad...I forgot to tell you....
I planned to release the updated code for dual display support on BT656 at the end of July.
Hi Qiang,
I'm using your the patch and the output to adv7391 is good. Now I want to use both HDMI and BT656 to adv7391 and I did the things you told in Update but I can see always BT656 not HDMI.
The uboot paramaters remain the same?
I put also video=mxcfb2:dev=hdmi,1920x1080M@50,if=RGB24 after your uboot params but I can see working only the ADV.
Any suggestion??
Thank you
I planned to make dual display with BT656 work on iMX6S/DL before the end of June.
Hi Qiang,
I want the patch of dual display mode with BT656 ouput support.
When do you plan to release updated patch?
Yes, it can also work on iMX6S and iMX6DL. But there is issue for dual display mode with BT656 ouput support, I planed to give an update in this month to fix it. Currently single BT656/BT1120 output on iMX6S/DL is OK.
Hi Qiang,
Could I use this patch for iMX6dl board ?
嗨，Qiang
Thank you for your patient reply, now we understand how to implement it, thank you again!
Hello. We use the L3.14.28 kernel and i.mx6q CPU. After manually applying the above L3.14.52_1.1.0_GA_bt656_output_patch_2016-06-27, if the clock configuration in arch/arm/mach-imx/clk-imx6q.c remains the original
imx_clk_set_parent(clk[IMX6QDL_CLK_IPU1_DI0_PRE_SEL],clk[IMX6QDL_CLK_PLL5_VIDEO_DIV]);
Then the BT1120 data can be output normally, the format is 1280*720@25, the clock frequency is 74.25MHz, but it cannot be dual-displayed with HDMI at this time;
If the above configuration is changed to the patch
mx_clk_set_parent(clk[IMX6QDL_CLK_IPU1_DI0_PRE_SEL], clk[IMX6QDL_CLK_PLL3_PFD1_540M]);
Then BT1120 cannot output.
Unfortunately, our current application must use dual display. If the clock source of IPU1_DI0 is selected as PLL3_PFD1_540M, is there any other configuration required to make BT1120 output correctly? Or if this clock source cannot achieve this frequency, is there any other way? Looking forward to your reply, thank you.
There is too much Blank data in each row, which exceeds the maximum value supported by the register. You need to find a way to reduce the Blank data, such as lowering the pixel clock frequency.
Hello, our board uses the imx6q automotive-grade chip, which is used for security monitoring. The hardware of our board is modified by referring to the Inbet Sabrelite development board.
The kernel version uses linux-3.0.35 version, and the board has two interfaces: CVBS output and HDMI output. The CVBS output uses the adv7391 chip. The temperature range of the ADV7391 chip is -40℃~85℃.
I downloaded the L3.0.35_4.1.0_GA_bt656_output_patch_2017-03-10.zip version you released, followed the instructions in the patch, and applied the patch successfully. After the patch was applied, I modified the board-mx6q_sabrelite.c file and added support for adv7391 Support for IIC devices. Also initialize the pins. The pin initialization code is as follows:
/* New code for DISPLAY RGB */
/*New Code for Board
The original development board Sabrelite interface uses MX6_PAD_DISP0_DAT0~MX6_PAD_DISP0_DAT23 24 bits
The new board DIS0 is connected to ADV7391BCPZ and uses 8 -bit bus */
MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK, /*DISP0_CLK*/
//MX6Q_PAD_DI0_PIN15__IPU1_DI0_PIN15, /* DE */
MX6Q_PAD_DI0_PIN2__IPU1_DI0_PIN2, /* DISP0_HSYNC */
MX6Q_PAD_DI0_PIN3__IPU1_DI0_PIN3, /* DISP0_VSYNC */
MX6Q_PAD_DI0_PIN4__IPU1_DI0_PIN4,
MX6Q_PAD_DI0_PIN4__GPIO_4_20, /* CVBS_nRST */
MX6Q_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0,
MX6Q_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1,
MX6Q_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2,
MX6Q_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3,
MX6Q_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4,
MX6Q_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5,
MX6Q_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6,
MX6Q_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7,
Modify line 62 of file linux3.0.35/drivers/mxc/ipu3/ipu_disp.c
Change macro definition 23 to 7
#define BT656_IF_DI_MSB 7// 23
/* For 8 bits BT656: 23 for DISP_DAT23 ~ DISP_DAT16; 7 for DISP_DAT7 ~ DISP_DAT0 */
/* For 16 bits BT1120: 23 for DISP_DAT23 ~ DISP_DAT8; 15 for DISP_DAT15 ~ DISP_DAT0 */
Here is my personal patch record:
linux@ubuntu:~/workspace/mx6q/linux-3.0.35$ patch -p1 < 0001-Support-BT656-and-BT1120-output-for-iMX6-ipuv3.patch
patching file arch/arm/configs/imx6_defconfig
patching file arch/arm/mach-mx6/board-mx6q_sabresd.c
patching file arch/arm/mach-mx6/devices-imx6q.h
patching file arch/arm/plat-mxc/include/mach/ipu-v3.h
patching file drivers/media/video/mxc/output/mxc_vout.c
patching file drivers/mxc/ipu3/ipu_common.c
patching file drivers/mxc/ipu3/ipu_device.c
patching file drivers/mxc/ipu3/ipu_disp.c
patching file drivers/mxc/ipu3/ipu_regs.h
patching file drivers/video/mxc/Kconfig
patching file drivers/video/mxc/Makefile
patching file drivers/video/mxc/mxc_bt656if.c
patching file drivers/video/mxc/mxc_ipuv3_fb.c
patching file include/linux/ipu.h
patching file include/linux/mxcfb.h
linux@ubuntu:~/workspace/mx6q/linux-3.0.35$ patch -p1 < 0002-Support-adv739x-TV-encoder-for-BT656-output.patch
patching file arch/arm/mach-mx6/board-mx6q_sabresd.c
patching file drivers/video/mxc/Kconfig
patching file drivers/video/mxc/Makefile
patching file drivers/video/mxc/mxcfb_adv739x.c
linux@ubuntu:~/workspace/mx6q/linux-3.0.35$ patch -p1 < 0003-Enhance-dual-display-support-for-BT656-output.patch
patching file arch/arm/mach-mx6/board-mx6q_sabresd.c
patching file arch/arm/mach-mx6/clock.c
patching file arch/arm/plat-mxc/include/mach/ipu-v3.h
patching file drivers/media/video/mxc/capture/ipu_bg_overlay_sdc.c
patching file drivers/media/video/mxc/capture/ipu_csi_enc.c
patching file drivers/media/video/mxc/capture/ipu_fg_overlay_sdc.c
patching file drivers/media/video/mxc/capture/ipu_prp_enc.c
patching file drivers/media/video/mxc/capture/ipu_prp_vf_sdc.c
patching file drivers/media/video/mxc/capture/ipu_prp_vf_sdc_bg.c
patching file drivers/media/video/mxc/capture/ipu_still.c
patching file drivers/mxc/ipu3/ipu_common.c
patching file drivers/mxc/ipu3/ipu_device.c
patching file drivers/mxc/ipu3/ipu_disp.c
patching file drivers/mxc/ipu3/ipu_prv.h
patching file drivers/video/mxc/mxc_ipuv3_fb.c
linux@ubuntu:~/workspace/mx6q/linux-3.0.35$ patch -p1 < 0004-BT656-Display-updated-for-BT1120-1080i-support.patch
patching file drivers/mxc/ipu3/ipu_disp.c
patching file drivers/video/mxc/mxc_bt656if.c
linux@ubuntu:~/workspace/mx6q/linux-3.0.35$ patch -p1 < 0005-Update-IPU-microcode-to-align-with-BT656.4-specifica.patch
patching file drivers/mxc/ipu3/ipu_disp.c
patching file drivers/video/mxc/mxc_bt656if.c
patching file drivers/video/mxc/mxcfb_adv739x.c
linux@ubuntu:~/workspace/mx6q/linux-3.0.35$ patch -p1 < 0006-Set-Y-range-16-235-U-V-range-16-240-for-BT656-displa.patch
patching file drivers/mxc/ipu3/ipu_disp.c
linux@ubuntu:~/workspace/mx6q/linux-3.0.35$ patch -p1 < 0007-Add-progressive-mode-support-for-BT656-and-BT1120-di.patch
patching file drivers/mxc/ipu3/ipu_disp.c
patching file drivers/video/mxc/mxc_bt656if.c
patching file drivers/video/mxc/mxc_ipuv3_fb.c
linux@ubuntu:~/workspace/mx6q/linux-3.0.35$ patch -p1 < 0008-Fixed-a-hard-coding-DC-macro-issue-for-progressive-m.patch
patching file drivers/mxc/ipu3/ipu_disp.c
linux@ubuntu:~/workspace/okmx6q/linux-3.0.35$
After all patches are completed and modifications are complete, the board can display video images normally and stably at room temperature, as shown below:
The board is tested at low temperature at -40℃. The image is shown below. The adv7391 driver is integrated into the kernel, which may cause the kernel to crash when it starts. If the adv7391 driver is removed, the kernel will not crash. If the environment variable parameter is changed to HDMI display, it will work normally.
The following are some parameter configurations
# cat /sys/class/graphics/fb0/fsl_disp_dev_property
arch\arm\mach-mx6\clock.c 配置成了
clk_set_parent(&ipu1_di_clk[0], &pll3_pfd_540M); //for CVBS 27MHz clock
clk_set_parent(&ipu1_di_clk[1], &pll5_video_main_clk);
The environment variables are configured
"video=mxcfb0:dev=adv739x,BT656-PAL,if=BT656,fbpix=RGB565"
The above are my parameters.
望指教！
"Under the BT656 data line interface (8-bit data bus), does the current program support VSYNC/HSYNC mode for display output?" In the previous reply, suggestions on how to achieve this should have been given. EAV/SAV are output at blank time, which has no effect on HSYNC/VSYNC reception. You can actually measure the waveform to see that as long as blank does not exceed 255, it should be possible. This is the easiest to do under the current circumstances.
IPU can also support non-BT656 8-bit UYVY+HSYNC/VSYNC output. The main thing is to modify the settings on the IPU side to let it output one pixel with 2 pixel clocks. However, there is no ready-made patch, you need to develop it yourself, which requires a very good understanding of the DI part of the IPU.
The IPU code has nothing to do with the kernel version. The DE example just tells you that by encoding IPU DI, you can make IPU_DI_PIN output any waveform you need.
The HSYNC and VSYNC output by the display are both pulse signals with a maximum value of 255.
If you need to output a level signal, it is more complicated. You need to encode the DI logic of the IPU to make it output the level signal you need. Here is an example of DI encoding, using DI_PIN04 to output a DE signal. https://community.nxp.com/message/392943
Qiang_FSL Thank you for your reply. My HDMI needs to use a resolution of 720 * 576. According to your description, it seems that PLL5 cannot be used as the clock for both BT1120 and HDMI. Can I use one of the following clocks as the output of IPU1_DI0 (BT1120 1280*720@25)? If so, how should I change it in clk-imx6q.c?
mmdc_ch0_axi 528MHz
pll3_usb_otg 480MHz
pll2_pfd0_352m
pll2_pfd2_396m
pll3_pfd1_540m
I have tried to configure the clock source of IPU1_DI0 to pll3_pfd1_540m: mx_clk_set_parent(clk[IMX6QDL_CLK_IPU1_DI0_PRE_SEL], clk[IMX6QDL_CLK_PLL3_PFD1_540M]);, and then modify the output clock through pixclock in struct fb_videomode. I found that there will be BT1120 screen output, but the color is seriously distorted and the clock cannot be perfectly 74.25MHz . Thank you.
You can use pll3_pfd1_540m for HDMI's 720*576 display and PLL5 for BT1120's 1280*720@25 .
Thank you very much for your detailed reply, which has clarified many doubts for us.
In short, in BT656 mode, the data stream is still in the BT656 standard format, but it can output HSYNC and VSYNC synchronization signals at the same time.
But in other posts, I saw you mentioned VSYNC/HSYNC mode, and there was the following explanation:
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.
Then I would like to know whether the current program supports VSYNC/HSYNC mode for display output under BT656 data line interface (8-bit data bus). If not, can it be patched to support it? Is this a lot of work? Because we still use pure UYVY data stream mode without EAV/SAV output.
In addition, you mentioned the output of DE signal. Could you explain it further in combination with the existing program? Is there any control of DE output in the current code? Which pin is used? The suggestion in your reply above to use different pins to output DE signal seems to be based on version 3.0.xx. Could you give an example of version 3.14.52?
Finally, is the DE signal only available under the LCD interface?
No logs.
Check IOMUX to see if it is set correctly.
Thank you very much for your reply. I will take a good look at the post this afternoon. Thank you!!
Hi, Qiang,
The following is the information printed by the kernel, using IPU2-DI0 and IPU1-DI1, which is correct.
Clock source是设的pll3
寄件者: Qiang_FSL
Date of delivery: March 11, 2020 11:40
Recipient: Allon Li(李新龍)(SZX)
主旨: Re: - Patch to Support BT656 and BT1120 Output For i.MX6 BSP
NXP Community <>
Patch to Support BT656 and BT1120 Output For i.MX6 BSP
new comment by Qiang Li - Mpu Se<> View all comments on this document<>
From the phenomenon, the two IPUs are not separated clearly, so they will affect each other. If the PINs used on the two IPUs are different, for example, one is DATA0-7 and the other is DATA16-23, the BT656_IF_DI_MSB in ipu_disp.c should use different values for the two IPUs, but this will only affect the data, not the clock.
The two BT656 clock sources can use the same one. For example, in clock.c, the two BT656 are IPU1_DI0 and IPU2_DI1:
clk_set_parent(&ipu1_di_clk[0], &pll3_pfd_540M); /* For CVBS 27MHz clock */
clk_set_parent(&ipu1_di_clk[1], &pll5_video_main_clk);
clk_set_parent(&ipu2_di_clk[0], &pll2_pfd_352M);
clk_set_parent(&ipu2_di_clk[1], &pll3_pfd_540M); /* For CVBS 27MHz clock */
In drver, you can print out ipu_id and ipu_di, and it will be easy to know where the problem is.
If it is an iMX6DQ board, registered on 2 IPUs, there is no problem of DI being occupied.
Take a look at the kernel startup log. If the kernel command line sets LVDS and HDMI display, it can override the device tree settings.
You can also use the kernel command line to set up two BT656 displays:
video=mxcfb0:dev=bt656,BT656-NTSC,if=BT656,fbpix=RGB32 video=mxcfb1:dev=bt656,BT656-NTSC,if=BT656,fbpix=RGB32