Hi,
I am trying to use the adv7391 encoder to output using cvbs with am imx6 quad board. I am using the patches from https://community.freescale.com/docs/DOC-94019 (specifically the patch L3.0.35_4.1.0_GA_bt656_output_patch_2013-09-30.zip which seems to be the latest). The encoder is setup on IPU number 2 and Display 0.
The scenario is with ldb and cvbs output on a monitor connected to the encoder.
When android boots up, I get the normal image on the ldb and on the cvbs output I get the same image but with flickering scrambled image, greenish. So really bad coloring etc.
When I try to use mxc_v4l2_output, I get the following warnings:
imx-ipuv3 imx-ipuv3.1: IPU Warning - IPU_INT_STAT_5 = 0x00800000
imx-ipuv3 imx-ipuv3.1: IPU Warning - IPU_INT_STAT_10 = 0x00080000
The uboot related line is:
video=mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=UYVY16 video=mxcfb1:dev=ldb,800x480M@60,if=RGB24,bpp=32 video=mxcfb2:off
Any suggestion is welcome.
Thanks!
Solved! Go to Solution.
I think the color issue should be related with your setting "imx-fbdev.legacyfb_deph=32", you can use the 32bpp setting for BT656 too:
video=mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=BGR32
By the way, in Android OS, the file "mxc_ipuv3_fb.c", function mxcfb_set_par(), the followed line should be un-masked, it is because Android can only support RGB frame buffer.
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.
Hi Li Qiang,
Have you generated similar patches for Yocto/kernel 3.5.7 (iMX6D)? Thanks.
Jason Xiong
Hi Jason, the 3.5.7 kernel release is not a GA release, so I will not generate patch for it.
Li Qiang,
Ok. Sorry to hear that. I will try to port them myself then. Changing from board specific files to Device Tree model is a little tricky. But I will give it a try.
Thanks.
Jason Xiong
Just want to follow up on this. I did get it to work on kernel 3.5.7. The patches are attached. And also need to add the following items to device tree.
head_unit_video: video-encoder@2b {
compatible = "fsl,mxc_adv739x";
reg = <0x2b>;
ipu_id = <0>;
disp_id = <0>;
default_ifmt = "BT656";
};
compatible = "fsl,mxc_bt656if";
ipu_id = <0>;
disp_id = <0>;
default_ifmt = "BT656";
pinctrl-names = "default";
pinctrl-0 = <>;
status = "okay";
};
Hi,
it there a patch for jethro 3.14.28-1.0.0 kernel version, or there is possibility to use current patches but adopted. The problem is that adv739x driver is not instantiated for current kernel version, despite I use OK configuration in device tree. Also there are no mxc_bt656if driver in current kernel version.
Device tree configuration:
fb_lcd: fb@2 {
compatible = "fsl,mxc_sdc_fb";
disp_dev = "adv739x";
interface_pix_fmt = "BT656";
mode_str ="BT656-NTSC";
default_bpp = <16>;
int_clk = <0>;
late_init = <0>;
status = "okay";
};
adv7391: adv7391@2b {
compatible = "adv,mxc_adv739x";
reg = <0x2b>;
pinctrl-names = "default", "enable";
pinctrl-0 = <&pinctrl_adv7391_off>;
pinctrl-1 = <&pinctrl_adv7391>;
rst-gpios = GP_ADV7391_RESET;
default_ifmt = "BT656";
ipu_id = <1>;
disp_id = <1>;
};
Please if you can give me some advice, I would be very grateful because I am stopped now in development because adv739x driver in not working and I cannot use TV out to display video on it.
Thanks, regards, Ivan.
When you see the followed errors, it means the IPU display had run into wrong status. How about the test result if you only enable the adv739x display? "video=mxcfb0:dev=adv739x,BT656-NTSC,if=BT656,fbpix=UYVY16 video=mxcfb1:off video=mxcfb2:off"
imx-ipuv3 imx-ipuv3.1: IPU Warning - IPU_INT_STAT_5 = 0x00800000
imx-ipuv3 imx-ipuv3.1: IPU Warning - IPU_INT_STAT_10 = 0x00080000
Hi,
if I enable only the adv739x display I get the same kind of output on my monitor as in the video. So no change.
Is there anything in addition I should keep in mind in my setup considering I am trying to use it on IPU2 DI0 rather than the case you tested it (IPU1 DI0)?
Thank you.
By the way, did you measure the pixel clock output from iMX6?
When you change adv739x from IPU1 to IPU2, the clock.c should also be modified
From
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);
To
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], &pll3_pfd_540M); //for CVBS 27MHz clock
clk_set_parent(&ipu2_di_clk[1], &pll5_video_main_clk);
I had the clock.c changes done already. That did not help.
So the IPU2 related changes that I did were in this clock.c file and in my board machine file, where I changed the .ipu_id from 0 to 1. Guess those should be all IPU related changes I needed to do.
As for verifying the pixel clock output from imx, I tested that by I2C getting the adv encoder to do a self test with a color bar test pattern which rendered well on my external CVBS monitor. So clock seems to be okay.
If you change the adv739x driver to IPU1, of cource there will be no display on adv739x. Will you still get the followed errors?
imx-ipuv3 imx-ipuv3.1: IPU Warning - IPU_INT_STAT_5 = 0x00800000
imx-ipuv3 imx-ipuv3.1: IPU Warning - IPU_INT_STAT_10 = 0x00080000
Do you only see such error when put adv739x to IPU2?
Yes, just tested that and I get those errors a lot.
When adv is set on IPU2 I get those warnings 2 times each only, but now that I changed it to IPU1 my ring buffer is full of those errors.
If so, I think the issue should be related with your patch porting. When you see such error, that means the IPU IDMAC is run in error, so the display will be wrong too.
In the patch's Readme file, you said this:
3) When bt656 interface is the second display for each IPU,1-layer-fb (it can be checked with command^M
"$ cat /sys/class/graphics/fbx/fsl_disp_property"), the frame buffer can only be YUV format. In this^M
case, the IPU DC channel was used for BT656 display, it has no CSC function, so RGB frame buffer was^M
not supported.
I actually use DI0, so the first interface of IPU2, and can only use fbpix UYVY16. According to the above sentence from the Readme, I should be able to use RGB565 or BGR32 since I am not on DI1, but if I use those I do not get any kind of signal on my monitor.
# cat /sys/class/graphics/fb0/fsl_disp_dev_property
adv739x
# cat /sys/class/graphics/fb0/mode
D:720x480i-60
# cat /sys/class/graphics/fb0/fsl_disp_property
2-layer-fb-bg
I haven't got the issue like you said, maybe you can attach your modified source code files here, I can help to have a check.
Hi, is there anything in the diffs that has caught your attention?
Your diff mode patch based on my patch is really hard to read, can you generate a patch based your last code and the code after applied my original patch?
By the way, if you are using Android, fbpix=UYVY16 was not supported, Android can only support RGB framebuffer.
I can't find issue from these patch files.
Can you attach your kernel boot up log? How do you test v4l2 output driver in Android?
I am attaching the dmesg for 3 cases; I am anyway attaching the UYVY16 case in case it helps in any way. Also, in the dmesg_RGB565_ldb_on_fb0 you will notice how the kernel hangs when ldb is on mxcfb0 and the adv on mxcfb1.
As for testing, in the case it actually boots, that is adv on mxcfb0 and ldb on mxcfb1, the ldb is mirrored on the screen. In the UYVY16 case the external monitor gets a signal from the adv, as seen in the attached video at the beginning of this thread. In the RGB565 case, there is no signal at all.
In addition, I tried using the mxc_v4l2_output binary to display some video captured using mxc_v4l2_tvin from a adv7180, but same as the above, with UYVY16 the image is scrambled, flickery, greenish, just like in the video; using RGB565, the monitor has no signal.
Thank you for your support.