ADV7610 CSI0 input

[allanmatthew]

Has anyone had any luck interfacing an ADV7610/ADV7611 HDMI input chip with CSI0?  I'm trying to get it working on an i.MX6S, and keep getting stuck at:

ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0

My physical interface almost exactly resembles the ADV7180/i.MX6 interface, with the addition of a DATA_ENABLE line.

I've modified my device tree to include the MX6QDL_PAD_CSI0_DATA_EN__IPU1_CSI0_DATA_EN (pinctrl_ipu1_2) and I've based my driver on the ADV7180.c driver in the BSP.

I'm positive that the ADV7611 is outputting an 8-bit BT656 720x480 (525i) signal, and I can verify that the pixelclk is running at about the right frequency.  HS, VS, DE, and PIXCLK are all enabled, and I believe the EAV/SAV are also enabled by default (these should not be needed though, right?).  I've tried a mix of HS/VS/DE/CLK polarities, but nothing seems to work.

Has anyone had any luck interfacing an ADV7610/7611 to an i.MX6?

Thanks,

[allanmatthew]

OK, I seem to be able to get data now.  I had to do the following:

1.) Make sure HSYNC and VSYNC were inverted polarity from the ADV7610

2.) Set a clock_curr value in my ioctl_g_ifparm() to !=0

3.) Set bt_sync_correct to 0 in ioctl_g_ifparm()

4.) set sen.pix.priv = 0 in my probe function

I'm now able to get some data into a file using the mfw_v4lsrc gstreamer pipeline, but it is very noisy.  I took a scope grab of the HSYNC (purple) and VSYNC (green).  This does not match the reference manual diagram exactly in that the HSYNC is running when the VSYNC is high, but I can't figure out how to make that not happen.  The clock runs continuously and the data stays low during the blanking period.

Does it matter that the HSYNC continues to run during the VSYNC period?  Should the above waveforms work with the CSI0 input?

Thanks,

-Allan

[igorpadykov]

Hi Allan

one can try not-gated mode (without HSYNC), timings are given in

sect.4.11.10.2.3 Non-Gated Clock Mode IMX6DQCEC

Best regards

chip

[allanmatthew]

I think I've found why its not working, anyway.  I took a scope trace of an OV camera input from a BD board, shown here:

You can see that the HSYNC (light blue) is inactive for the entire blanking time, and does not run when the VSYNC is active.  This seems to jibe with the IMX6DQCEC:

So it looks like I'll have to try and get the HSYNC/VSYNC signals from my ADV7610 to match up  Unfortunately I'm not sure if this will be possible, as the ADV7610 relies mostly on the DATA_EN pin to specify if data is correct or not.

Is there ANY WAY to make the DATA_EN pin work with the CSI0?

-Allan

[igorpadykov]

On i.MX6SDL side DATA_EN is configured using

CSI0_DATA_EN, Table 4-1. Pin Assignments IMX6SDLRM

and bit CSI0_DATA_EN_POL,  register IPU_CSI0_SENS_CONF

~chip

[allanmatthew]

Chip-

Actually, it turns out that turning OFF the DATA_EN seems to work a bit better.  I don't have a correct image yet, but I do have something.  There seems to be an offset in the video, like its starting to read lines in the VSYNC period when it should not be or something.  Is there a crop value or something in the v4l_capture that needs to be set?

-Allan

[igorpadykov]

Hi Allan

from link below seems 7611 works in 12bit BT.1120 mode.

Can't capture data from adv7611 with CSI0 on MX6Q

ADV7610 also supports 8-/12-bit ITU-R BT.656 mode.

Best regards

chip

[allanmatthew]

Hi Chip-

Yeah, I saw that.  Unfortunately I'm operating in 8-bit mode and don't have the ability to go to a 16-bit bus, but we need to support a 720p input.  We can't do that with the bt656 but should be able to do it with a simple gated parallel mode.

-Allan

[donfreiling]

Hi Allan,

Not sure if you've solved this yet but our design is based on an i.mx6solo and includes both an ADV7181 and ADV7610. We only use one of these at a time so both are connected to CSI1 (we use CSI0 for a MIPI camara module) and we tri-state the output of the which ever one is not in use. We use BT.656 to bring in the data and have tested both chips in 8 and 16 bit width. The embedded clock mode has worked so well for us that we have actually dropped HSYNC, VSYNC and DAT_EN for our production board.

One thing that I had to mess with to get BT.656 working was the ADV7610's LLC delay. See IO Register 0x19 (LLC_DDL_EN).

Here are the few changes I had to make to my adv7610 driver in order when switching between 8 and 16 bit modes:

In probe()

#ifdef ADV7610_16BIT

   adv_data.v4l2_data.pix.pixelformat = V4L2_PIX_FMT_YUYV;

#else

   adv_data.v4l2_data.pix.pixelformat = V4L2_PIX_FMT_UYVY;

#endif

In init_ADV7610_regs:

#ifdef ADV7610_16BIT

   { IO_ADDR, 0x03, 0x80 }, // Output format is 16 bit SDR ITU-656 Mode 0

   { IO_ADDR, 0x19, 0x89 }, // LLC DLL phase, changed to improve setup/hold time

#else

   { IO_ADDR, 0x03, 0x00 }, // Output format is 8 bit SDR ITU-656

   { IO_ADDR, 0x19, 0xC3 }, // LLC DLL phase

#endif

In ioctl_g_ifparm

#ifdef ADV7610_16BIT

   p->if_type = V4L2_IF_TYPE_BT1120;

   p->u.bt1120.mode = V4L2_IF_TYPE_BT1120_MODE_BT_8BIT;

   p->u.bt1120.clock_curr = (V4L2_DV_INTERLACED == adv_data.timings.bt.interlaced) ?

         0 : adv_data.timings.bt.pixelclock;

   p->u.bt1120.nobt_hs_inv = 0;  // horizontal sync invert

   p->u.bt1120.nobt_vs_inv = 0;  // vertical sync invert

   p->u.bt1120.frame_start_on_rising_vs = 0; // VS rising indicates a start

                                    // of a new frame

   p->u.bt1120.latch_clk_inv = 0;

   p->u.bt1120.bt_sync_correct = 0;

#else

   p->if_type = V4L2_IF_TYPE_BT656;

   p->u.bt656.mode = V4L2_IF_TYPE_BT656_MODE_BT_8BIT;

   p->u.bt656.clock_curr = (V4L2_DV_INTERLACED == adv_data.timings.bt.interlaced) ?

         0 : adv_data.timings.bt.pixelclock;

   p->u.bt656.nobt_hs_inv = 0;

   p->u.bt656.nobt_vs_inv = 0;

   p->u.bt656.latch_clk_inv = 0;

   p->u.bt656.frame_start_on_rising_vs = 0;

   p->u.bt656.bt_sync_correct = 0;

#endif

[allanmatthew]

Hi Don-

Thanks very much for your response.  I actually did get the ADV7610 working in BT656 with an 8-bit bus, but I'm looking to get it working in the 16-bit setup.

I've patched mxc_v4l2_capture.c and v4l2-int-device.h, updated my dtb, and included your suggestions in my adv7610.c.  I'm stuck at the dqueue timeout again, unfortunately.

I notice that you set

p->u.bt1120.mode = V4L2_IF_TYPE_BT1120_MODE_BT_8BIT;

in your 16-bit configuration, is there any reason that you did that instead of V4L2_IF_TYPE_BT1120_MODE_BT_16BIT;

Also, in your physical interface, I'm assuming you're using CSI0_DATA02->CSI0_DATA09 and CSI0_DATA12->CSI0_DATA19.  In the i.MX6 datasheet, CSI0_DATA00, CSI_DATA01, CSI_DATA10 and CSI_DATA11 are listed as "0" instead of "-", so I'm wondering if you pull those pins low?

Lastly, to use the V4L2_IF_TYPE_BT1120 are you using patches from this post? https://community.freescale.com/thread/295157

I've incorporated what I believe are the relevant portions of mxc_v4l2_capture.c and v4l2-int-device.h, but I'm not sure if there is more thats needed to be done.

Thanks!

-Allan

[allanmatthew]

Got it working actually!  I used the interface described in "https://community.freescale.com/thread/314211" and used internal pulldowns to pull DATA0,1, 10 and 11 low.  Using the exisitng CCIR codes seemed to work as well.  Thanks!

-Allan

[wuchirk]

Hi Allan,

I am looking for iMX6Q CSI1 parallel interface with BT1120 interlace and I also have the dequeue timeout issue. Now I refer the link Re: 16bit BT1120 does not work on MX6Q , so I have these acts as below:

(1) mxc_v4l2_capture.c

     csi_param.clk_mode = IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_SDR

     csi_param.data_width = IPU_CSI_DATA_WIDTH_8

(2) ipu_capture.c(for CCIR1120_INTERLACED_SDR or CCIR1120_INTERLACED_DDR)

     ipu_csi_write(ipu, csi, 0xD07DF, CSI_CCIR_CODE_1);

     ipu_csi_write(ipu, csi, 0x40596, CSI_CCIR_CODE_2);

     ipu_csi_write(ipu, csi, 0xFF0000, CSI_CCIR_CODE_3);

(3) Pull DATA0, 1, 10, 11 to low by HW

(4) Connected CSI1_DATA02~09 to decoder "C" data and CSI1_DATA12~19 to decoder "Y" data.

Did you mind to describe your settings actually that ioctl_g_ifparm(), values of CSI_CCIR_CODE_1~3 and clk_mode?

Thank you pretty much.

Chirk

[igorpadykov]

Hi Allan

v4l2 capture is used for cameras, while

for  ADV7180 - like devices one needs to use mxc_v4l2_tvin.out, it

was specially created to test the adv7180 functionality, turning on the de-interlace function.

Pelase check below links

Re: ADV7181 on IMX6Q board

De-interlace Capture Device

Can't capture data from adv7611 with CSI0 on MX6Q

Best regards

chip

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[allanmatthew]

Hi Chip-

Thanks for the prompt reply.  I tried the mxc_v4l2_tvin.out but no dice, I see the same "ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0".

I've done a bit more testing, and here is what I know from the ADV7610 side:

1.) HSYNC is active high

2.) VSYNC is active high

3.) DE is active high

I've checked with a scope and their traces appear (to me) to be correct, however they don't necessarily match the "gated mode" in the i.MX6 reference manual:

My VSYNC will stay high for the entirety of the frame, and the HSYNC stays high for the entirety of the line.  Thats normal operation in my experience, but does the i.MX6 require something different?

Also, there is almost no mention of the DATA_ENABLE line in the reference manual.  Should it be used?  How do I enable it, beyond setting the right pinctl in the DTS?

Lastly, what are the correct settings in the various IOCTLs of my driver to enable the HSYNC/VSYNC/DE modes?

Thanks,

-Allan

[igorpadykov]

Hi Allan

actually suggested links answer some questions:

Re: ADV7181 on IMX6Q board

for mxc_v4l2_tvin.out one needs to verify that device outputs EAV and SAV codes.

In BT656 interlaced mode the CSI will check the data bus for EAV and SAV,

it will only capture the video data after found the correct EAV and SAV.

If device outputs HSYNC/VSYNC, then one can use v4l2 capture, as for cameras.

Best regards

chip

[allanmatthew]

Hi Chip-

Indeed, and I've tried both methods. I can inject SAV EAV codes and try the tvin type, or leave them out and use the HSYNC/VSYNC with v4l2_capture but neither works, both give the same error.

Since I know the codes and sync pins are working, there must be something wrong in my i.mx6 configuration... Could you explain what settings I need to make sure are set to get this running? I would prefer to use the HSYNC/VSYNC. Also, what do I need to do with the DE?

Thanks,

-Allan