AnsweredAssumed Answered

Deinterlace using VDIC "real time" and "DMA only" modes

Question asked by darryln on Sep 5, 2014

Using GuruCE/Device Solutions Opal i.MX53 board running WEC7. TVP5150 TV decoder attached to CSI1, running in BT656 interlaced mode, with NTSC TV input.  I am able to capture fields via SMFC and display them in a camera app at 1/2 vertical resolution (240p stretched to fit 480), so this proves the TVP5150 and CSI support are correct. 


I am trying to implement deinterlace, YUV->RGB, and resize, using VDIC "real time" mode, i.e. CSI->VDI->PRP VF->mem automated flow, with frame output on PRP VF task IDMAC channel 21. This way, the only CPU intervention required is the channel 21 EOF handler which writes the RGB progressive frames to the capture pin stream queue.  The RM clearly states this is supported, but doesn't give much detail on configuration.


WEC7 IPU code does not support this, so I created a custom camera driver PDD which includes the necessary register-level support for VDI, IC PRP VF, IPU_CONF, etc.  I disabled the VDI usage in the display driver overlay code, and removed the VDI DLL from the build, so there is no conflict over VDI or IC PRP.


As an interim step, I would like to verify deinterlace using "DMA only" mode, i.e. mem->VDI->mem, with the input fields on channels 8,9,10, and the frame output on channel 5. 

PROBLEM: no VDIC interrupts, even with all the VDIC input and output channels enabled ,and buffers ready.  single or double buffered, nothing happens.

QUESTION: what are possible causes for no VDIC interrupts?


IDMAC settings for the VDIC input channels are basically the same as with CSI->SMFC->mem.

 

I have looked at the Platform SDK code for clues, but it only supports an undocumented mode where only channel 9 is used for field input, and the PRP VF output goes direct to DP input.


Additional info 9/12: Attached register dumps after configuring for mem-VDI-mem and CSI->VDI->PRPVF->mem. Reg dumps show IPU_CH_BUF_RDY0=0 for the VDIC and PRP VF channels.  Expectation is these bits should be set in the calls to IDMACChannelBUF0SetReady and IDMACChannelBUF1SetReady, so either they are not getting set  (unlikely as the SMFC field interrupt works) or they are self-clearing without triggering any transfers to/from the VDIC.

Original Attachment has been moved to: regdump_direct.txt.zip

Original Attachment has been moved to: regdump_smfc.txt.zip

Outcomes