ADV7280M -> iMX6QDL

[jasongaiser]

Hi!

We're trying to use an ADV7280M to capture a NTSC/PAL CVBS signal and stream it over the network using a headless iMX6QDL.  We are using a fork of the 3.14-1.0.x-mx6 branch of the community kernel(github.com/Freescale/linux-fslc).  

I've searched the forums and went through countless posts and troubleshooting guides.  So far I've managed to get video capture somewhat working but only using Gated clock mode.  Using either mxc_v4l2_capture.out or a gstreamer-1.0 pipeline(using v0.11.1 of gstreamer1.0-plugins-imx), I can capture videos or still images but the colorspace and format is wrong(images are purple/pink).  I'm guessing the color issues could be fixed with colorspace conversion so for now I'm focusing on the sync issue.

It is not very easy for us to inspect the MIPI signals on our board, so I cannot guarantee that the BT.656 signals are present in the stream.  However, I am using the recommended initialization settings for the ADV7280M so I am confident they are present in the stream.  I have tried both 656 v3 and v4 but neither one works.  

My ioctl_g_ifparm() configuration which works is:

p->u.bt656.clock_curr = 27000000; // This should be zero, but we never get frames if it is.
p->u.bt656.nobt_vs_inv = 0; // -> Vsync_pol
p->u.bt656.nobt_hs_inv = 0; // -> Hsync_pol
p->u.bt656.latch_clk_inv = 0; // -> pixclk_pol
p->u.bt656.bt_sync_correct = 0; // -> ext_vsync: 0: No external VSYNC and HSYNC, embedded EAV and SAV will be used for SYNC.

I've tried varying all of the parameters.  I've tried using the I2P/deinterlacer on the ADV7280M with clock_curr set to both 0 or 1 and it does not make a difference.  I've also tried using the ADV7280M in both normal(i.e. capturing a CVBS camera signal) and free-run mode using various test patterns.  Unless clock_curr > 1(i.e. gated mode), I never receive frames("ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0").  

We are using one MIPI CSI-2 lane and virtual channel zero.  I've made the appropriate changes to the device tree and they are reflected in the register settings.

Can anyone suggest a solution?  I've double-checked our IPU and CSI register settings and they all look OK.  Data and clocks look OK, and data does seem to arrive in gated mode, so unless we have a data quality issue which is corrupting the bt.656 sync codes, I can't see anything wrong.  I double-checked the CCIR codes and they seem OK for BT.656 video:

CSI_CCIR_CODE_1 = 0xD07DF; 
CSI_CCIR_CODE_2 = 0x40596;
CSI_CCIR_CODE_3 = 0xFF0000;

assuming the bits, from MSB to LSB, indicate HVF values in the BT.656 sync codes.

I've heard from another engineer on the forums that they had success with a newer kernel(v4.1) so I am going to investigate back-porting any relevant changes in order to see if I can get things working.  Any suggestions are appreciated!

Thanks!

[jasongaiser]

Finally fixed my colorspace issues.  I had modified MIPI_CSI2_SFT_RESET to 0x04 last week in an effort to get things working.  That ended up converting the UYVY to YUYV which resulted in swapped Y and UV.

Now I have other issues:

- Rolling vsync.  I've tried changing active_top from 13 to either 3 or 4 without any success.  I also tried enabling the I2P(deinterlacer) on the ADV7280M and switched the iMX6 back to progressive mode but it did not help the issue.  It's strange because this seemed to work fine for a bit and then I lost sync.

- Field ordering seems wrong.  If I disable the I2P(deinterlacer) on the ADV7280M and configure the iMX6 for interlaced mode, I get visual artifacts that appear to be field ordering related.  I'm working on testing this further.

- Frame rate seems low for interlaced content.  I'm only getting frames every 66ms, not every 33ms or every 16ms like I'd expect.

[jasongaiser]

Thanks for the suggestion.  I actually started by modifying Fan Al's driver from that thread.  I modified his driver to remove any regulator support(we control power differently).  I also modified it to compile properly against the 3.14 kernel.  I have compared his code to the mainline adv7180.c driver as well as the recommended register settings from Analog Devices and made a few adjustments, but those changes did not affect the behavior much.  The most necessary change was to set MIPI_CSI2_PHY_TST_CTRL1 to 0x26 in order to match the ADV7280m clock (in interlaced mode).  When, and if, I get this configuration working, I will post my code so that other engineers do not have to repeat this debugging process.

In our case, we do not see errors in the MIPI_CSI2_ERR1/MIPI_CSI2_ERR2 registers.  In the case where I try to use IPU_CSI_CLK_MODE_CCIR656_INTERLACED, here is a register dump before the call to wait_event_interruptible_timeout() in mxc_v4l_dqueue():

[ 95.186611] MIPI_CSI2_ERR1 = 0
[ 95.186613] MIPI_CSI2_ERR2 = 0
[ 95.186616] MIPI_CSI2_PHY_STATE = 300
[ 95.186619] IPU_CONF = 0x10000101
[ 95.186622] IDMAC_CONF = 0x0000002F
[ 95.186624] IDMAC_CHA_EN1 = 0x00000001
[ 95.186626] IDMAC_CHA_EN2 = 0x00000000
[ 95.186629] IDMAC_CHA_PRI1 = 0x18800001
[ 95.186631] IDMAC_CHA_PRI2 = 0x00000000
[ 95.186634] IDMAC_BAND_EN1 = 0x00000000
[ 95.186636] IDMAC_BAND_EN2 = 0x00000000
[ 95.186638] IPU_CHA_DB_MODE_SEL0 = 0x00000001
[ 95.186641] IPU_CHA_DB_MODE_SEL1 = 0x00000000
[ 95.186643] IPU_CHA_TRB_MODE_SEL0 = 0x00000000
[ 95.186719] IPU_CHA_TRB_MODE_SEL1 = 0x00000000
[ 95.186721] DMFC_WR_CHAN = 0x00000090
[ 95.186724] DMFC_WR_CHAN_DEF = 0x202020F6
[ 95.186726] DMFC_DP_CHAN = 0x00009694
[ 95.186729] DMFC_DP_CHAN_DEF = 0x2020F6F6
[ 95.186731] DMFC_IC_CTRL = 0x00000002
[ 95.186734] IPU_FS_PROC_FLOW1 = 0x00000000
[ 95.186736] IPU_FS_PROC_FLOW2 = 0x00000000
[ 95.186738] IPU_FS_PROC_FLOW3 = 0x00000000
[ 95.186740] IPU_FS_DISP_FLOW1 = 0x00000000
[ 95.186743] IPU_VDIC_VDI_FSIZE = 0x00000000
[ 95.186745] IPU_VDIC_VDI_C = 0x00000000
[ 95.186747] IPU_IC_CONF = 0x00000000
[ 95.186750] IC_IDMAC_1 = 0x00000000
[ 95.186752] IC_IDMAC_2 = 0x00000000
[ 95.186754] IC_IDMAC_3 = 0x00000000
[ 95.186757] IC_IDMAC_4 = 0x00000000
[ 95.186760] IPU_INT_CTRL_1 = 0x00000001
[ 95.186763] IPU_INT_CTRL_2 = 0x00000000
[ 95.186766] IPU_INT_CTRL_3 = 0x00000000
[ 95.186768] IPU_INT_CTRL_4 = 0x00000000
[ 95.186771] IPU_INT_CTRL_5 = 0xBFFEFF2F
[ 95.186774] IPU_INT_CTRL_6 = 0x001FFF02
[ 95.186776] IPU_INT_CTRL_7 = 0x00000000
[ 95.186779] IPU_INT_CTRL_8 = 0x00000000
[ 95.186782] IPU_INT_CTRL_9 = 0xDC000001
[ 95.186785] IPU_INT_CTRL_10 = 0x777F000F
[ 95.186788] IPU_INT_CTRL_11 = 0x00000000
[ 95.186791] IPU_INT_CTRL_12 = 0x00000000
[ 95.186793] IPU_INT_CTRL_13 = 0x00000000
[ 95.186796] IPU_INT_CTRL_14 = 0x00000000
[ 95.186799] IPU_INT_STAT_1 = 0x00000000
[ 95.186801] IPU_INT_STAT_2 = 0x00000000
[ 95.186805] IPU_INT_STAT_3 = 0x00000000
[ 95.186808] IPU_INT_STAT_4 = 0x00000000
[ 95.186810] IPU_INT_STAT_5 = 0x00000000
[ 95.186813] IPU_INT_STAT_6 = 0x00000000
[ 95.186816] IPU_INT_STAT_7 = 0x00000000
[ 95.186818] IPU_INT_STAT_8 = 0x00000000
[ 95.186821] IPU_INT_STAT_9 = 0x00000000
[ 95.186824] IPU_INT_STAT_10 = 0x00000000
[ 95.186828] IPU_INT_STAT_11 = 0x00000000
[ 95.186830] IPU_INT_STAT_12 = 0x00000000
[ 95.186834] IPU_INT_STAT_13 = 0x00000000
[ 95.186837] IPU_INT_STAT_14 = 0x00000000
[ 95.186839] IPU_GPR = 0x00000000
[ 95.186841] IPU_CHA_CUR_BUF_0 = 0x00000001
[ 95.186844] IPU_CHA_CUR_BUF_1 = 0x00000000
[ 95.186846] IPU_CHA_BUF0_RDY_0 = 0x00000001
[ 95.186848] IPU_CHA_BUF0_RDY_1 = 0x00000000
[ 95.186850] IPU_CHA_BUF1_RDY_0 = 0x00000000
[ 95.186853] IPU_CHA_BUF1_RDY_1 = 0x00000000
[ 95.186855] IPU_CHA_EN_1 = 0x00000001
[ 95.186857] IPU_CHA_EN_2 = 0x00000000
[ 95.186860] IDMAC_CHA_BUSY_1 = 0x00000000
[ 95.186862] IDMAC_CHA_BUSY_2 = 0x00000000
[ 95.186865] CSI_SENS_CONF = 0x04000A30
[ 95.186867] CSI_CCIR_CODE_1 = 0x010D07DF
[ 95.187858] CSI_CCIR_CODE_2 = 0x00040596
[ 95.187861] CSI_CCIR_CODE_3 = 0x00FF0000
[ 95.187864] CSI_MIPI_DI = 0xFFFFFF1E
[ 95.187867] SMFC_MAP = 0x00000000
[ 95.187869] SMFC_BS = 0x00000007

One further question:  Is there a way to capture the raw data on the MIPI bus so that I can analyze it myself?  I'd like to verify the BT-656 datastream without having to rent a MIPI bus analyzer.

Thanks!

[igorpadykov]

regarding bt656 - please be aware of sect.37.4.3.6.2 Non-Gated Mode

i.MX6DQ Reference Manual :

When working with MIPI, the non-gated mode should be configured.

Best regards
igor

[jasongaiser]

Thanks for pointing that out!  Now, does that mean an external VSYNC must be applied,  or does the iMX6 derive the VSYNC signal from the information on the MIPI CSI-2 bus?

[jasongaiser]

I guess I should have waited to ask that.  :smileyhappy:  Using non-gated mode, I can capture a stable image from the ADV7280M in free-run mode(displaying color bars).  I'm still seeing incorrect colors when using gstreamer:

gst-launch-1.0 imxv4l2videosrc device=/dev/video0 ! imxvpuenc_h264 bitrate=10000 ! filesink location=test.mp4

but that may be caused by my older version of gstreamer1.0-plugins-imx.  

I am now having problems capturing camera images(this worked in gated mode, but with VSYNC issues), so I still have some work to do.  I will post a summary of my findings here once I get everything working.

Thanks for your help!

[igorpadykov]

Hi Jason

please check suggestions given on

i.MX6Q video capture issue with ADV7280-M 

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