imx6 MIPI sync issues

[matthewdavis]

I have a MIPI sensor running on an i.MX6Q board based on the Sabre reference design running Android 4.4 and I'm having trouble with sync reliability.  Everything is stable, but the image wraps around (as if the first starting pixel is not at 0,0, but rather at some value x,y elsewhere in the image).  The frame doesn't "roll" during a single capture--the sync location seems stable, but if I start and stop capture, the offset changes.  Basically, it looks like the start of frame happens somewhere in the middle of the frame and stays at that offset for every capture.

I've been changing the polarity of hsync and vsync in the driver, but the behavior doesn't appear to change.  I can't think of any settings that would cause the start/end of frame signals in the MIPI stream to be out of sync with the frame, so I can only assume the problem is on the controller driver side.  I have an Ov5640 on the parallel0 interface to IPU0/CSI0 and that works correctly.  The issue is only with the Ov8865 I have on the MIPI port VC1 to IPU0/CSI1.

Has anybody else run across this issue with their designs?  What did you do to resolve it?

[maitegonzalez]

Hii!!

I am working with the integration of MT9P031 cmos and imx6-hummingboard. Currently, I have the same error of syncronization.. 

Mathew, have you resolved it? something related to vsync and pixel clock??

I'll appreciate any comment

Thanks!!

Maite

[igorpadykov]

Hi Matthew

>What types of problems typically cause this error?

usually this is caused by data starvation due to huge load on the DDR memory bus,

so just for test one can try to decrease resolution@fps numbers both sensor and lcd.

Also one can try to test with bare minimal linux image .

~igor

[igorpadykov]

Hi Matthew

one can test if this is caused by performance isues removing parallel

sensor or allocating to other IPU. May be useful to check CSI performance

data described in Chapter 37 Image Processing Unit (IPU) p.2725

i.MX6DQ Reference Manual

http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

[matthewdavis]

Hello Igor,

Thanks for the response.  To be clear, I am not using the two cameras simultaneously.  They both have driver support in the same image and I use them one at a time, so I don't think that the parallel sensor should contend for resources with the MIPI camera unless I am misunderstanding something.

I have checked the data rate and it looks like we are comfortably below those limits.  The one thing about my application that is unusual is that I'm interpreting the data as grayscale data (GENERIC in the IPU), which required a little bit of additional code in the kernel driver, but I don't see how that would be a problem.

It seems to me that something is confusing the state machine that handles the start of frame / end of frame packets, but as this is my first MIPI camera driver, I don't have much insight into what might cause that sort of failure.

[igorpadykov]

Hi Matthew

for mipi generic data driver example may be useful to look at

https://community.freescale.com/message/344529#344529

Best regards

igor

[matthewdavis]

Hi Igor,Yes, I have spent many hours looking over that thread and it got me to where I am now.  I think that everything is correct with the exception of some minor detail somewhere.

I've turned on some tracing and found that I'm seeing the error:IPU Warning - IPU_INT_STAT_5 0x00000001

If I'm reading that correctly, that means that the IPU is seeing a new frame before the end of the previous frame.  I can't think of any reason for this to be the case.  This type of problem seems pretty common as it's mentioned in other places (including the link you just posted):https://community.nxp.com/message/341843
https://community.nxp.com/message/804934

But I haven't seen a solution or even an explanation of what might cause it.  I'm fairly certain that the imager is not generating SOFs without EOFs.  I don't see any tunable options on the MIPI channel that might create that type of pattern.  My only guess is that it's an issue with the IPU state machine not being reset properly.  It doesn't look like any sort of IPU reset is part of the workflow in the reference driver, though, and my sensor driver is based on the reference design.

What types of problems typically cause this error?