AnsweredAssumed Answered

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

Question asked by Ivan Kozic on Jul 25, 2013
Latest reply on Oct 23, 2013 by Dave McMordie
Branched to a new discussion

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).

Outcomes