i.mx6 quad CSI vsync issues (IPU Warning - IPU_INT_STAT_5 = 0x00000001)

[ivankozic]

Hi all,

I have been moderately successful in making Aptina AR0330 work with i.MX6 via MIPI-CSI. However, I cannot get the VSYNC to lock properly. I would say that the frames I currently get via mxc_v4l2_capture.out app are correct, but they start on random locations.

As suggested by the RM, I am using non-gated clock mode (because of MIPI), but the waveforms in RM show VSYNC only couple of sensor_clk cycles long (in fact only one cycle long), while Aptina outputs Frame_Valid signal (active throughout the whole frame). And it seems that IPU is only level-triggered, which implies that capture is starting somewhere during the frame (at a random location). I sometimes even get half of the line at the start of the frame, which implies that even HSYNC has the same issue. This is very weird as DATA_EN coming from MIPI receiver should effectively gate HSYNC (in non-gated mode, clock should be provided to CSI only when there is valid data). I have also read through chip errata and found out that actually DATA_EN (dvalid) is active even when there are blanking and null packets (HW bug).

One of the factors leading to this is the fact that V4L2 (in Kernel 3.0.35) has no way of stopping the sensor stream (I am no V4L2 expert, but VIDIOC_STREAMOFF should provide this functionality, however a handle to this is not included in the V4L2 structure on i.MX6) - it only has a handle to mode_change() function which turns off the streaming, updates the mode and turns on the streaming again. This is why it is crucial for IPU to sync on the VSYNC - otherwise it will never lock vertically.

CSI port is also quite buggy - since when using MIPI mode, data width and format are automatically taken from MIPI receiver through MCT_DI bus, it is not possible to pack 12bit to 16bit data in system memory. IPU also does not seem to care much if the CSI0_DATA_SOURCE is set to MIPI or not - it always gets the test pattern from the sensor (always with wrong sync - no matter if this bit is set or not).

So currently we would be happy to just sync to the actual frame start, and we can't do it no matter which config of IPU we make. We would be very grateful if anyone knows how this problem could be resolved.

Did anyone have similar problems? And if so, how did you resolve it?

P.S. We are using a prototype ic, so at least part of the issues might lie there (there are indeed many bugs on both software and hardware level).

[davemcmordie]

Ivan,

Did you eventually get this solved with the advice from Qiang?  I am capturing from an 8-bit RAW mipi sensor (to IPU2 CSI0) and a 12 bit parallel sensor (to IPU1 CSI0) and am getting frames, but with an incorrect vertical sync (and sometimes incorrect horizontal sync).  Just wondering if getting through this left you with any insights as to what to look at.

Dave

[qiang_li-mpu_se · Accepted solution]

For CSI non-gated mode, the IPU will only capture the low to high modification on VSYNC, so if your sensor can generate such trigger for each frame, it is OK to keep the VSYNC in high for whole frame.

And for non-gated clock mode, data enable was also needed, and pixel clock should be ticking only when data is valid.

VIDIOC_STREAMOFF was supported in mxc_v4l2_capture.c of freescale kernel.

For MIPI mode, SENS_DATA_FORMAT and DATA_WIDTH registers are ignored, this can be found in iMX6 reference manual.

For your case, I think you should make sure the sensor output is a correct non-gated clock mode.