Stuck at __vb2_wait_for_done_vb when using yavta to do capture

[bensonhuang]

Hi,

We are using i.MX8M to develop i.MX8M MIPI CSI-2 video capture device.

In i.MX8M platform, there are two components which are related to MIPI CSI-2.

One is mx6s_capture (csi1_bridge) and the other is mxc-mipi-csi2_yav (mipi_csi_1).

Our current environment setting of MIPI CSI-2 is 1 data lane, 1 channel and 1 analog camera.

When we use yavta to test the function flow of V4L2, we will be stuck at __vb2_wait_for_done_vb.

Our command: yavta -fUYVY -s720x480 -n4 --capture=5 /dev/video0

After analyzing the log, we found that mx6s_vidioc_dqbuf is not returned and mx6s_csi_irq_handler is not triggered.

It seems maybe DMA transfer is not complete or some other reasons.

Could anyone help to provide some clues or guide us how to debug the issues (e.g. check the register status, buffer content...)?

Thanks.

[bensonhuang]

Hi,

Only when I use interlace field (e.g., V4L2_FIELD_INTERLACED), mx6s_vidioc_dqbuf will not return and mx6s_csi_irq_handler will not be triggered.

But if I use none interlace field (e.g., V4L2_FIELD_NONE), mx6s_vidioc_dqbuf will return and

mx6s_csi_irq_handler will be triggered.

It seems mx6s_capture.c has some problem when handling interlaced video from analog camera.

Could someone tell us how to solve this issue?

Thanks.

[dh29]

Hi Benson,

Did you manage to solve this problem? I am having the same problem using an ADV7280M (mipi / analogue camera) with an i.MX7D.

It seems to me the NXP documentation regarding the CSI/MIPI is a complete mess for the i.MX7, and probably likewise for the i.MX8. For instance the i.MX7 document pack contains a 150 page Graphics document that only mentions the i.MX6 family, never the i.MX7, and an 87 page VPU document, when the i.MX7 doesn't contain a VPU. Very confusing !!

Almost all of the CSI / MIPI posts assume use of an i.MX6 with a h/w IPU. Of course, the i.MX7 and the newer i.MX8 don't have a h/w IPU. And most posts, just like this one, are left 'hanging' without any conclusion.

I am using Kernel 4.9.11 and mx6s_capture.c attempts to set bits that are reserved according to the documentation.

Analogue video - by this I mean interlaced BT.656 - seem a very common use-case, but when using the CSI-MIPI it is completely unclear what driver is doing what.

With an analogue INTERLACED (PAL / NTSC) camera feed, and according to Analogue Devices documentation this results in a INTERLACED BT.656 compliant MIPI feed:

• I expected that mx6s_capture.c should be configured with CCIR enabled (CSICR1 bit 10), in order to decode the embedded timing (SAV, EAV) ??  But I can't get this to work !!
• If I don't enable CCIR, I can get an image, albeit with 2 copies one on top of each other, due to interlacing. But this raises the question of how has the embedded frame/field timing been decoded from the BT.656 without CCIR being enabled ??
• Is CCIR mode applicable when using the MIPI as a feed to the CSI ??

Some help from NXP is needed here !!

[jimmychan]

which BSP are you using?

You may get more details about the mipi csi driver in Linux reference manual.

you can get the document of different version BSP  from here:

i.MX Software|NXP 

e.g. under Documentation --i.MX Software|NXP             

• • Linux L4.9.51 8MQuad GA Documentation

[bensonhuang]

Hi Jimmychan,

We use Linux L4.9.51 for i.MX 8MQuad GA version.

The documents are nearly about i.MX6 series (IPU part) and don't mention i.MX8M.

Will NXP release new documents for i.MX8M?

Thanks.