iMX7 CSI MIPI : BT.656

[dh29]

iMX7 : ADV7280M : SUBDEV framework (mx6s_capture.c)

In my on-going battle to get an AD7280M (csi-mipi) working on an i.MX7 I can now capture an image from a PAL camera feed. Stable picture, correct colors, picture is clear....BUT.... I have 2 copies of the image, one on top of the other.

I am guessing that this is due to the ADV7280M sending INTERLACED picture, and I am not set-up for this.

I have tried patching parts of mx6s_capture.c to enable CCIR656 mode, enable Interlaced mode and enable de-interlace output, but when I try this everything stops - I get no ouput, and no mx6s_csi_irq_handler  interrupts.

Various parts of mx6s_capture.c don't look correct for the IMX7. For instance it tries to set bit1 os CSI control reg 18 (which it thinks is TVDECODER_IN_EN), but according to the iMX7 h/w manual this bit is RESERVED and should NOT be set!

Anybody got any experience in getting the CCIR656 mode (BT.656) / Interlaced input working with the iMX7.

[Please note the iMX7. For other CSI MIPI posts, on the (very) rare occasions I've had a reply from NXP-support-staff, they have quoted advice only relevant to the iMX6 with an IPU which uses a completely different driver framework].

[celinelaurencin]

Hi,

I am currently experimenting to capture interlaced video with ADV7281 decoder and iMX8Mini using the same capture driver as mentioned in this post mx6s_capture.c.

I experienced the same issue described in this post, where PAL interlaced video stream can only be captured successfully when CSI module is not configured for CCIR656 mode.

Could you please confirm that the source cause of this behavior comes from no compatibility between the 2 following statements:

• ADV7281 outputs MIPI CSI-2 with Frame Start/ Frame End packets and Line Start/End packets instead of EAV/SAV codes
• iMX8Mini CSI interface is expecting EAV/SAV codes when CSI is configured for CCIR656 mode

Depending on the source cause, a workaround should be implemented in appropriate driver (ADV7180 or CSI) and should make sure to respect the followings:

• user applications should get from V4L the information for interlaced mode

Thanks in advance.

Regards,

Céline

[dh29]

Since my original post I can now successfully capture PAL PROGRESSIVE and PAL INTERLACED using the ADV7280M and i.MX7. It seems that I do not need to configure anything regarding BT.656 as the MIPI CSI2 (PHY) sorts out the SAV/EAV timing before passing to the MIPI CSI block.

I am however struggling to get anything stable with an NTSC camera feed. See my post https://community.nxp.com/thread/480516 .

[dh29]

It seems that when using the MIPI, the MIPI CSI-2 sorts out the EAV/SAV coding. See Analogue Devices post Cannot capture from ADV7281-M with i.MX6Q | EngineerZone 

The ADV7281-M outputs MIPI CSI-2 with Frame Start/ Frame End packets and Line Start/End packets. This takes the place of the EAV/SAV codes that were used in the BT656 specification.

This implies that I should not enable CCIR mode within the iMX7 as this will enable the CSI to look for the EAV/SAV codes, which won't be present. I think this explains why I can't capture anything when CCIR was enabled.

So I think I can safely ignore the CCIR feature and proceed with trying to de-interlace my image.

Can anybody confirm my understanding?

[joanxie]

Got this information from expert team for imx6q, but you can find the register settings according imx7 RM

1. the adv7280 should be enabled after mipi_csi2_reset().

2. For MIPI CSI input, the clock mode in IPU_CSI_SENS_CONF must be gated clock mode.

          p->u.bt656.clock_curr = 1;

3. For interlaced input, IDMAC 0 should be set to interlaced mode: "params.csi_mem.interlaced = true;"

case IPU_CSI_CLK_MODE_GATED_CLK: in file drivers\media\video\mxc\capture\ipu_csi_enc.c, function csi_enc_setup().

4. For device type:

     adv7280_data.sen.pix.priv = 1;  /* 1 is used to indicate TV in */

[dh29]

Hi Joan Xie,

The iMX.7 does not have an IPU and hence does not use the capture framework driver as referenced by your reply. The recommended driver framework for the iMX.7 (as per NXP documentation) is to use the subdev driver framework. 

NXP seem to have real difficulty in understanding the differences between the i.MX6 family and the i.MX7, and the implications to the Linux drivers!!