Ok, I got the ADV7180 working with the Android camera app. I'll have several action items for my local rep (when I see him) e.g., explain the synchronization strategy between the CSI port and the IDMAC in CSI->MEM.
It looks like in the CSI->MEM path the CSI free runs and the IDMAC generates the camera call back every time it completes capturing one frame of data without syncronizing SOF to the CSI port SAV code timing. If so, there's potential for these to get out of sync.
In the CSI->IC path syncronization appears to be done appropriately resulting in a stable image always.
Of course this could just be the current state of Linux drivers and not a design limitation,.
Once you get the frames synced properly and adjust offsets to account for the porches, then the de-interlacer in the IDMAC will start to behave as well.
We need de-interlace support in i.MX51 CSI1 interface & we are struggling to bring-up.
Can you share the de-interlacing support on i.mx51CSI1 interface+ADV7180?
Are you porting in Wince ?
we 're just debugging now since HW ready in these day.As i know ADV7180 is use I2C command to control this chip.
can you read chip-set staus?
the otherwise,do you have record software (API).
I haven't found good documentation on this yet, but while trying to get a ADV7180 up in Android I discovered the CSI->MEM path appears to be deinterlacing video on the fly. Unfortunately it's not aligning the two frames properly and I have VSYNC issues. The partial de-interlacing results in no chroma where the frames don't align. Changing the ADV register settings per their DS results in better algnment (defaults have every other fame really deinterlaced poorly), but still not correct (and still not v-synced)
Askng FSL for detailed information on the CSI and IPU configuration but it's slow getting a reply. The CCIR registers in the CSI block are not documented for bit order or why there are two blanking fields per frame. This makes verifying that they are setup correctly almost impossible, but the reference code seems reasonable ofter compiling several variations of CCIR code bit orders and testing them to see which ones are potential fits. The naming convention for fields in the CCIR registers does not appear to be be imply correct ordering for the H, F and V bits. The only thing keeping me sane on all the compiles is having a fast quad core laptop.
Placing printk's everwhere I don't see where the CSI is linking to the VDIC and the SMFC doesn't appear to be throwing away frames and rescaling.
Also of interest is the PRP path (tested with the mxc_v4l2_overlay unit test) works fine (good hsync) but the CSI_ENC route fails to sync. I've tried going to progressive mode hoping to just see interleaved data, but that fails to VSYNC as well (picture rolls). Attempts to change the mx5x/libcamera routines to use the PRP path (changing the input from 1 to 0) fail with no video captured.
I would even consider trying gated mode to get rid of the sync issue, but the RM and UG have no verified timing diagrams to demonstrate signal polarities and porch requirements. It's also unclear if the CSI would discard the embedded codes based upon an external hsync. I'm guessing this would require a logic analyzer to verify the h-v sync timing is properly aligned with the SAV and EAV codes unless FSL can state that it would treat this as YUV data (even though the values would be out of range).
Has anyone sucessfully integrated an adv7180 with Android yet? I'm starting to wonder if CSI1 on the i.MX53 has an issue with AV codes...