BT656 output on ADV7391 using imx6 quad

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

BT656 output on ADV7391 using imx6 quad

Jump to solution
19,372 Views
meflo
Contributor II

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!

Labels (4)
1 Solution
13,581 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

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.

View solution in original post

0 Kudos
59 Replies
6,740 Views
jasonxiong
Contributor II

Hi Li Qiang,

Have you generated similar patches for Yocto/kernel 3.5.7 (iMX6D)? Thanks.

Jason Xiong

0 Kudos
6,740 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

Hi Jason, the 3.5.7 kernel release is not a GA release, so I will not generate patch for it.

0 Kudos
6,740 Views
jasonxiong
Contributor II

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

0 Kudos
6,740 Views
jasonxiong
Contributor II


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";

    };

     mxc_bt656if@0 {

         compatible = "fsl,mxc_bt656if";

         ipu_id = <0>;

         disp_id = <0>;

         default_ifmt = "BT656";

         pinctrl-names = "default";

         pinctrl-0 = <>;

         status = "okay";

   };

0 Kudos
6,740 Views
ivanljubicic
Contributor III

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.

0 Kudos
6,742 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

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

0 Kudos
6,742 Views
meflo
Contributor II

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.

0 Kudos
6,742 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

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);

6,742 Views
meflo
Contributor II

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.

0 Kudos
6,742 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

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?

0 Kudos
6,741 Views
meflo
Contributor II

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.

0 Kudos
6,741 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

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.

0 Kudos
6,741 Views
meflo
Contributor II

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

0 Kudos
6,741 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

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.

0 Kudos
6,741 Views
meflo
Contributor II

Hi,

I am attaching the diff's between the patches you posted and the patches I had done.

Thank you.

0 Kudos
6,741 Views
meflo
Contributor II

Hi, is there anything in the diffs that has caught your attention?

0 Kudos
6,741 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

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.

0 Kudos
6,741 Views
meflo
Contributor II

Attached are the patches.

Thank you.

0 Kudos
6,742 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

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?

0 Kudos
6,742 Views
meflo
Contributor II

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.

0 Kudos