i.MX53 IPU Deinterlacer

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX53 IPU Deinterlacer

14,785 Views
CraigPetku
Contributor III
Has anyone come across a white paper or a Linux driver which implements the HW deinterlacer found in the i.MX53?  After getting an ADV7180 running on CSI1, I now have odd/even fields that need to be combined (preferably using the IPU).  For a quick demo using the unit_tests it's easy just to crop and scale, but I'd really like to see the IPU do the heavy lifting.
Tags (1)
48 Replies

859 Views
LautaroCarmona1
Contributor II
Hi Craig,

While we were doing some tests with TVP5147 and i.MX51's CSI, we realized that our CSI is not performing deinterlacing either and we are receiving the two fields of every frame as two separated image of about 240 lines each, and that they are being drawn together (I will upload a photo of this sceneario to explain myself better asap)... i found in this discussion that you had a similar situation with ADV7180... can you explain me how did you get the frames synced properly?

Thanks,
Lautaro
0 Kudos

859 Views
CraigPetku
Contributor III

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.

859 Views
DualDisplayiss1
Contributor I


iWave Systems Technologies said:

Eric,

 

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?

 

 

Hi~~

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

Eric

 

0 Kudos

859 Views
CraigPetku
Contributor III
So hunting through the code today I found the csi_enc routines seem to do their de-interlacing using the idmac in ipu_common.c.  Still looking for my cause of video rolling which is starting to look like the idmac  My updates are still too rough to post.  Hopefully I'll have this figured out before Thursday.  If so I'll send a note to Zafeer.
0 Kudos

859 Views
iWave
Contributor V

Eric,

 

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?

0 Kudos

859 Views
CraigPetku
Contributor III

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

0 Kudos

859 Views
DualDisplayiss1
Contributor I

Do you mind use i.mx51CSI1 interface+ADV7180?

 

Eric

0 Kudos