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

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

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

3,890 Views
darryln
Contributor II

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

20 Replies

2,227 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

Hi Darryln, from your "regdump_direct.txt", I found the CSI1_SENS_CONF setting is wrong, CSI_DATA_DEST[26-24] should be changed from 0x4 "IDMAC via SMFC" to 0x2 "IC". The SMFC and IDMAC channel 0 should not be used in such use case, IDMAC_CH_EN_1 bit 1 should be 0.

0 Kudos

2,227 Views
darryln
Contributor II

Hello Qiang Li,

Thank you for the response.  I will try changing CSI1_SENS_CONF setting for the CSI direct use case.  Can you tell me what would prevent VDI interrupts from occurring, especially in the mem-VDI-mem use case?   I believe I have CPMEM configured correctly, and the reg dump shows IDMAC channels and EOF interrupts are definitely enabled, and the VDI is definitely enabled in IPU_CONF, but the set buffer ready seems to have no effect. 

Thanks,

Darryl

0 Kudos

2,227 Views
darryln
Contributor II

With CSI1_SENS_CONF=02008a30 and IDMAC_CH_EN_1=08a02700, still no VDI EOF interrupts.

0 Kudos

2,227 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

Hi Darry, for no EOF interrupts, there are two cases, one is no data coming to that IDMAC channel; another is wrong CPMEM setting, the seting frame size is bigger than the real input data size.

So  think you should check all used IDMAC channel's interrupt status, if there is no EOF status for all channel, I think your IPU processing flow is still not correct.

0 Kudos

2,227 Views
darryln
Contributor II

I found a significant VDI-related bug in the FSL common code [COMMON_FSL_V3\IPUV3\BASE\PDK\ipuv3_base.cpp]. The g_phIntrHdlr[0][5] was 0, g_pIntrGroupMask[0][5] was 0, and VDI_DMA_CHA_MASK #define did not include channel 5 (VDI frame output to mem). The other channels 8,9,10,13 were correctly set up.  I was really hoping this fixed the problem, but I still get no interrupt from any VDI or PRP channel.  As I said, SMFC EOF and NFACK interrupts work correctly.

Qiang Li wrote:

Hi Darry, for no EOF interrupts, there are two cases, one is no data coming to that IDMAC channel; another is wrong CPMEM setting, the seting frame size is bigger than the real input data size.

So  think you should check all used IDMAC channel's interrupt status, if there is no EOF status for all channel, I think your IPU processing flow is still not correct.

Still no VDI or PRP interrupts, regardless of which mode is configured. The FLOWx registers are per your guidance, and you said you saw nothing wrong when you reviewed the CPMEM settings. So apparently it's something else -- what else can you suggest? 

0 Kudos

2,227 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

Hi Darryln, since you still can see EOF on SMFC, that means the data is still go through the SMFC, this is wrong for your use case. When CSI data was sent to VDIC directly, no data will go through SMFC, there should be no EOF and NFACK interrupt on SMFC.

I think you should check if there is some other code changed your IPU setting and switched back to SMFC capture mode.

0 Kudos

2,227 Views
darryln
Contributor II

Qiang,

To clarify....SMFC EOF is enabled only for the "DMA only" use case -- the SMFC EOF interrupt handler does set buffer ready on VDI channels 8,9,10 and 5, and the EOF interrupt is enabled for all those channels,  but no interrupt occurs.  For the "Real time" use case of  CSI-VDI-PRPVF-mem, SMFC is totally disabled.  I don't get any PRP interrupt on channel 21 either.

You said CPMEM and flow configuration were the only possible reasons for no VDI interrupt.

You reviewed my CPMEM and said you didn't see anything wrong.

There doesn't seem to be anything wrong for the flow configuration either.

So there must be something else that prevents it from working, can you suggest?

Thanks,

Darryl

0 Kudos

2,227 Views
darryln
Contributor II

reg dump of "DMA only" mode. This dump is made during the SMFC EOF interrupt handler,  after VDI has been configured with 3 input fields on 8-9-10 and output on ch 5, and all buffers set ready.  No VDI interrupt occurs. 

IPU_CONF              40001766 IC_INPUT=1, VDI_EN=1, IC_EN=1, CSI1_EN=1

IPU_INT_CTRL1 EOF     00002724 2(SMFC), 5, 8,9,10,13

IPU_INT_STAT1 EOF     00000000

IPU_INT_CTRL3 NFACK   00000000

IPU_INT_STAT3 NFACK   00000000

IPU_CUR_BUF_0         00000000

IPU_CH_BUF0_RDY0      00000000

IPU_CH_BUF1_RDY0      00000000

IPU_GPR               00000000

IPU_CH_DB_MODE_SEL0   10202724

IPU_FS_PROC_FLOW1     80000000 VF_IN_VALID=1 VDI_SRC_SEL=00

IPU_FS_PROC_FLOW2     00000000

IPU_FS_PROC_FLOW3     00000000

IC_CONF               00000300 CSI_MEM_WR_EN=0, RWS_EN=0, PRPVF_CSC1=1, PRPVF_EN=1

IC_PRP_ENC_RSC        20002000

IC_PRP_VF_RSC         20002000

IC_PP_RSC             20002000

IC_CMBP_1             00000000

IC_CMBP_2             00000000

IC_IDMAC_1            00000080

IC_IDMAC_2            00077c00

IC_IDMAC_3            000b3c00

IC_IDMAC_4            00005555

VDI_C                 0208fff2

VDI_FSIZE             01df02cf

CSI1_SENS_CONF        04008a30  DEST=4, SMFC

CSI1_SENS_FRM_SIZE    020c02cf

CSI1_ACT_FRM_SIZE     01df02cf

CSI1_OUT_FRM_CTRL     00000003

[IDMAC regs]

IDMAC_CONF            0000002f

IDMAC_CH_EN_1         08a00724

IDMAC_CH_EN_2         00080000

IDMAC_SEP_ALPHA       00800000

IDMAC_ALT_SEP_ALPHA   00000000

IDMAC_CH_PRI_1        00800020

IDMAC_CH_PRI_2        00000000

IDMAC_WM_EN_1         00000000

IDMAC_WM_EN_2         00000000

IDMAC_LOCK_EN_2       00000000

IDMAC_DUMMY_0         00000000

IDMAC_SUB_ADDR_1      00000000

IDMAC_SUB_ADDR_2      00000040

IDMAC_BNDM_EN_1       00000000

IDMAC_BNDM_EN_2       00000000

IDMAC_SC_CORD         00000000

IDMAC_CH_BUSY_1       00000000

IDMAC_CH_BUSY_2       00000000

0 Kudos

2,227 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

Hi Darryln, I make the MEM->VDI->MEM case working in Linux BSP, the followed is my key registers setting:

Note: I don't have the TVIn board on hand, so I used the camera for the test, the input is 640*480, no CSC and no resize, so IC wasn't enabled.

VDI_FSIZE = 0x1df027f.

VDI_C = 0x42497776.

VDI_C2 = 0x0.

IC_CONF = 0x0.

IPU_FS_PROC_FLOW1 = 0x0.

IPU_FS_PROC_FLOW2 = 0x0.

IPU_FS_PROC_FLOW3 = 0x0.

IPU_CONF = 0x7a1.

IDMAC 8, 9, 10, 5 setting, the input channel's height is the field height, 240; the output channel's height is the frame height, 480:

ch 9 word 0 - 00000000 00000000 00000000 E0001800 0003BC4F

ch 9 word 1 - 06000000 00000000 2143C000 00027FC0 00000000

PFS 0xa

BPP 0x3

NPB 0xf

FW 640

FH 240

EBA0 0x30000000

EBA1 0x0

Stride 2559

scan_order 0

uv_stride 0

u_offset 0x0

v_offset 0x0

Width0 0+1

Width1 0+1

Width2 0+1

Width3 0+1

Offset0 0

Offset1 0

Offset2 0

Offset3 0

ch 8 word 0 - 00000000 00000000 00000000 E0001800 0003BC4F

ch 8 word 1 - 060000A0 00000000 2143C000 00027FC0 00000000

PFS 0xa

BPP 0x3

NPB 0xf

FW 640

FH 240

EBA0 0x30000500

EBA1 0x0

Stride 2559

scan_order 0

uv_stride 0

u_offset 0x0

v_offset 0x0

Width0 0+1

Width1 0+1

Width2 0+1

Width3 0+1

Offset0 0

Offset1 0

Offset2 0

Offset3 0

ch 10 word 0 - 00000000 00000000 00000000 E0001800 0003BC4F

ch 10 word 1 - 060200A0 00000000 2143C000 00027FC0 00000000

PFS 0xa

BPP 0x3

NPB 0xf

FW 640

FH 240

EBA0 0x30100500

EBA1 0x0

Stride 2559

scan_order 0

uv_stride 0

u_offset 0x0

v_offset 0x0

Width0 0+1

Width1 0+1

Width2 0+1

Width3 0+1

Offset0 0

Offset1 0

Offset2 0

Offset3 0

ch 5 word 0 - 00000000 00000000 00000000 E0001800 00077C4F

ch 5 word 1 - 03140000 00000000 2143C000 00013FC0 00000000

PFS 0xa

BPP 0x3

NPB 0xf

FW 640

FH 480

EBA0 0x18a00000

EBA1 0x0

Stride 1279

scan_order 0

uv_stride 0

u_offset 0x0

v_offset 0x0

Width0 0+1

Width1 0+1

Width2 0+1

Width3 0+1

Offset0 0

Offset1 0

Offset2 0

Offset3 0

2,227 Views
darryln
Contributor II

I have duplicated these settings as far as possible (difference is 720 width and CSI1), but still no VDI EOF interrupt.

!.  you have VDI_EN=0... but according to the RM it should be 1 to enable VDI.  Does your code work with VDI_EN=0?

2. what does the CPMEM width value "0+1" mean?  Shouldn't CPMEM offset & width be set for UYVY format?

Width0 0+1

Width1 0+1

Width2 0+1

Width3 0+1

0 Kudos

2,227 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

Hi DarryIn, the VDI_EN should also be set, I dumpped the registers before enabled the IDMAC channel, the VDI_EN will be set when IDMAC channel was enabled.

For 2, width are not used for YUV data, that "+1" is just print out messages:

printk("Width0 %d+1 \r\n", ipu_ch_param_read_field_io(ipu_ch_param_addr(ipu, ch), 1, 116, 3));

0 Kudos

2,226 Views
darryln
Contributor II

Result is the same - still no VDI interrupt.

0 Kudos

2,227 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

I'm trying the CSI->MEM->VDI->MEM case on Freescale BSP, after enabled, I will give you the workable IPU setting. It needs time.

0 Kudos

2,227 Views
darryln
Contributor II

reg dump of "real time" mode CSI-VDI-PRPVF-mem.  Ch 21 interrupt does not occur.

IPU_CONF            40001666 IC_INPUT=1, VDI_EN=1, IC_EN=1, CSI1_EN=1

IPU_INT_CTRL1 EOF   00200000 21 enabled

IPU_INT_STAT1 EOF   00000000

IPU_INT_CTRL3 NFACK 00000000

IPU_INT_STAT3 NFACK 00000000

IPU_CUR_BUF_0       00000000

IPU_CH_BUF0_RDY0    00000000

IPU_CH_BUF1_RDY0    00000000

IPU_GPR             00000000

IPU_CH_DB_MODE_SEL0 10200000 21 PRPVF output double buffered

IPU_FS_PROC_FLOW1   95000000 VF_IN_VALID=1, VDI_SRC_SEL=01, PRP_SRC_SEL=0101

IPU_FS_PROC_FLOW2   00000000 PRP_DEST_SEL=0000, PRPVF_DEST_SEL=0000

IPU_FS_PROC_FLOW3   00000000

IC_CONF             00000300 CSI_MEM_WR_EN=0, RWS_EN=0, PRPVF_CSC1=1, PRPVF_EN=1

IC_PRP_ENC_RSC      20002000

IC_PRP_VF_RSC       20002000

IC_PP_RSC           20002000

IC_CMBP_1           00000000

IC_CMBP_2           00000000

IC_IDMAC_1          00000080

IC_IDMAC_2          00077c00

IC_IDMAC_3          000b3c00

IC_IDMAC_4          00005555

VDI_C               0208FFF2

VDI_FSIZE           01df02cf

CSI1_SENS_CONF      02008a30  DEST=2, IC

CSI1_SENS_FRM_SIZE  020c02cf

CSI1_ACT_FRM_SIZE   01df02cf

CSI1_OUT_FRM_CTRL   00000003

[IDMAC regs]

IDMAC_CONF          0000002f

IDMAC_CH_EN_1       08a00000 21 enabled

IDMAC_CH_EN_2       00080000

IDMAC_SEP_ALPHA     00800000

IDMAC_ALT_SEP_ALPHA 00000000

IDMAC_CH_PRI_1      00800020

IDMAC_CH_PRI_2      00000000

IDMAC_WM_EN_1       00000000

IDMAC_WM_EN_2       00000000

IDMAC_LOCK_EN_2     00000000

IDMAC_DUMMY_0       00000000

IDMAC_SUB_ADDR_1    00000000

IDMAC_SUB_ADDR_2    00000040

IDMAC_BNDM_EN_1     00000000

IDMAC_BNDM_EN_2     00000000

IDMAC_SC_CORD       00000000

IDMAC_CH_BUSY_1     00000000

IDMAC_CH_BUSY_2     00000000

2,227 Views
darryln
Contributor II

I'm using the same CPMEM settings on the VDI input channels 8-9-10 as for the SMFC input channel (since SMFC EOF interrupt works correctly).  But I still don't get any VDI interrupts.  See below for VDI CPMEM settings.  Also see attached register dump files.

Can you please tell me what the FLOW1 and FLOW2  register values should be for each VDI use case:

1. mem-VDI-mem

2. CSI1-VDI-PRP VF-mem

Also, for use case 2, it is not clear how to use the IDMAC channels. The RM says the incoming CSI field is stored to VDI internal FIFO1, and also to memory via chan 13, and the other two input fields come from memory on chans 9 and 10.  So I would configure chans 13, 9, and 10 CPMEM the same as SFMC input, right?  Also, it seems that chans 9 and 10 buffers would have to be manually updated on each field EOF so they point to the correct field, is that right?  Also not clear what the PRP VF input channel is, see below.

Also, can you please confirm the IDMAC channel usage:

5 VDI deinterlaced frame out to memory

8-9-10 VDI field input from memory - VDI use case 1

9-10 VDI field input from memory - VDI use case 2

13 VDI field output to memory (copy of FIFO1) - VDI use case 2

12 IC PRP VF video input from memory -   is this chan used for VDIC frame input for use case 2?

14 IC PRP VF graphic input from memory - is this chan used VDIC frame input for use case 2?

21 IC PRP VF output to memory

Below are the CPMEM settings for VDI input and output channels.  Please let me know if you see anything wrong.

#define YUV_FIELD_STRIDE    (D1_Width*2) //1440

#define YUV_FRAME_STRIDE    (D1_Width*2) //1440

#define YUV_FIELD_WIDTH     (D1_Width) // 720

#define YUV_FRAME_WIDTH     (D1_Width) // 720

#define YUV_FIELD_HEIGHT    (D1_NTSC_Height/2) // 240

#define YUV_FRAME_HEIGHT    (D1_NTSC_Height) // 480

#define YUV_FIELD_BUFFER_SIZE       (YUV_FIELD_WIDTH * YUV_FIELD_HEIGHT * 2)    // UYVY interlaced, 16 bpp (1/2 frame)

#define YUV_FRAME_BUFFER_SIZE       (YUV_FRAME_WIDTH * YUV_FRAME_HEIGHT * 2)    // UYVY progressive, 16 bpp

#define VDI_PIXEL_BURST 16

#define IDMAC_CH_5                  5

#define IDMAC_CH_VDI_FRAME_OUT      IDMAC_CH_5

#define IDMAC_CH_VDI_FIELD_OUT      IDMAC_CH_13


VDI Input:

        CPMEMData.iBitsPerPixel         = CPMEM_BPP_16;

        CPMEMData.iDecAddrSelect        = CPMEM_DEC_SEL_ADDR_0_TO_15;

        CPMEMData.iAccessDimension      = CPMEM_DIM_2D;

        CPMEMData.iScanOrder            = CPMEM_SO_INTERLACED;

        CPMEMData.iThresholdEnable      = CPMEM_THE_DISABLE;

        CPMEMData.iThreshold            = 0;

        CPMEMData.iCondAccessEnable     = CPMEM_CAE_COND_SKIP_DISABLE;

        CPMEMData.iCondAccessPolarity   = CPMEM_CAP_COND_SKIP_LOW;

        CPMEMData.iAlphaUsed            = CPMEM_ALU_ALPHA_SAME_CHANNEL;

        CPMEMData.iAXI_Id               = CPMEM_ID_0;

        CPMEMData.iBandMode             = CPMEM_BNDM_DISABLE;

        CPMEMData.iBlockMode            = 0;

        CPMEMData.iRotation90           = 0;

        CPMEMData.iFlipHoriz            = 0;

        CPMEMData.iFlipVert             = 0;

        CPMEMData.iPixelBurst           = VDI_PIXEL_BURST-1;

        CPMEMData.iPixelFormat          = IDMAC_INTERLEAVED_FORMAT_CODE_UYVY2;

        CPMEMData.iWidth                = YUV_FIELD_WIDTH - 1;

        CPMEMData.iHeight               = YUV_FIELD_HEIGHT - 1;

        CPMEMData.iLineStride           = YUV_FIELD_STRIDE - 1;

        CPMEMData.pixelFormatData.component0_offset = UYVY_COMPONENT0_OFFSET;

        CPMEMData.pixelFormatData.component1_offset = UYVY_COMPONENT1_OFFSET;

        CPMEMData.pixelFormatData.component2_offset = UYVY_COMPONENT2_OFFSET;

        CPMEMData.pixelFormatData.component3_offset = UYVY_COMPONENT3_OFFSET;

        CPMEMData.pixelFormatData.component0_width  = UYVY_COMPONENT0_WIDTH - 1;

        CPMEMData.pixelFormatData.component1_width  = UYVY_COMPONENT1_WIDTH - 1;

        CPMEMData.pixelFormatData.component2_width  = UYVY_COMPONENT2_WIDTH - 1;

        CPMEMData.pixelFormatData.component3_width  = UYVY_COMPONENT3_WIDTH - 1;

        // channel params

        CPMEMWrite(IDMAC_CH_VDI_INPUT_PREV_FIELD, &CPMEMData, TRUE);

        CPMEMWrite(IDMAC_CH_VDI_INPUT_CUR_FIELD,  &CPMEMData, TRUE);

        CPMEMWrite(IDMAC_CH_VDI_INPUT_NEXT_FIELD, &CPMEMData, TRUE);

        // channel offset

        CPMEMOffsetData.bInterleaved = TRUE;

        CPMEMOffsetData.interlaceOffset  = 0;

        CPMEMWriteOffset(IDMAC_CH_VDI_INPUT_PREV_FIELD,  &CPMEMOffsetData, CPMEMOffsetData.bInterleaved);

        CPMEMWriteOffset(IDMAC_CH_VDI_INPUT_CUR_FIELD,   &CPMEMOffsetData, CPMEMOffsetData.bInterleaved);

        CPMEMWriteOffset(IDMAC_CH_VDI_INPUT_NEXT_FIELD,  &CPMEMOffsetData, CPMEMOffsetData.bInterleaved);

        CPMEMWriteXScroll(IDMAC_CH_VDI_INPUT_PREV_FIELD, 0);

        CPMEMWriteXScroll(IDMAC_CH_VDI_INPUT_CUR_FIELD,  0);

        CPMEMWriteXScroll(IDMAC_CH_VDI_INPUT_NEXT_FIELD, 0);

VDI output:

    CPMEMData.iBitsPerPixel         = CPMEM_BPP_16;

    CPMEMData.iDecAddrSelect        = CPMEM_DEC_SEL_ADDR_0_TO_15;

    CPMEMData.iAccessDimension      = CPMEM_DIM_2D;

    CPMEMData.iScanOrder            = CPMEM_SO_PROGRESSIVE;

    CPMEMData.iThresholdEnable      = CPMEM_THE_DISABLE;

    CPMEMData.iThreshold            = 0;

    CPMEMData.iCondAccessEnable     = CPMEM_CAE_COND_SKIP_DISABLE;

    CPMEMData.iCondAccessPolarity   = CPMEM_CAP_COND_SKIP_LOW;

    CPMEMData.iAlphaUsed            = CPMEM_ALU_ALPHA_SAME_CHANNEL;

    CPMEMData.iAXI_Id               = CPMEM_ID_0;

    CPMEMData.iBandMode             = IDMAC_CH_BAND_MODE_DISABLE;

    CPMEMData.iBlockMode            = 0;

    CPMEMData.iRotation90           = 0;

    CPMEMData.iFlipHoriz            = 0;

    CPMEMData.iFlipVert             = 0;

    CPMEMData.iPixelBurst           = VDI_PIXEL_BURST-1;

    CPMEMData.iPixelFormat          = IDMAC_INTERLEAVED_FORMAT_CODE_UYVY2;

    CPMEMData.iHeight               = YUV_FRAME_HEIGHT - 1;

    CPMEMData.iWidth                = YUV_FRAME_WIDTH - 1;

    CPMEMData.iLineStride           = YUV_FRAME_STRIDE - 1;

    CPMEMData.pixelFormatData.component0_offset = UYVY_COMPONENT0_OFFSET;

    CPMEMData.pixelFormatData.component1_offset = UYVY_COMPONENT1_OFFSET;

    CPMEMData.pixelFormatData.component2_offset = UYVY_COMPONENT2_OFFSET;

    CPMEMData.pixelFormatData.component3_offset = UYVY_COMPONENT3_OFFSET;

    CPMEMData.pixelFormatData.component0_width = UYVY_COMPONENT0_WIDTH - 1;

    CPMEMData.pixelFormatData.component1_width = UYVY_COMPONENT1_WIDTH - 1;

    CPMEMData.pixelFormatData.component2_width = UYVY_COMPONENT2_WIDTH - 1;

    CPMEMData.pixelFormatData.component3_width = UYVY_COMPONENT3_WIDTH - 1;

    CPMEMWrite(IDMAC_CH_VDI_FRAME_OUT, &CPMEMData, TRUE);

    CPMEMOffsetData.bInterleaved = TRUE;

    CPMEMOffsetData.interlaceOffset  = 0;

    CPMEMWriteOffset(IDMAC_CH_VDI_FRAME_OUT,  &CPMEMOffsetData, CPMEMOffsetData.bInterleaved);

0 Kudos

2,227 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

For mem->VDI->mem case, in FLOW1 register, VDI_SRC_SEL should be 0x00 ARM. This is IDMAC 8, 9, 10 -> VDI -> IDMAC 5 data path, in this path, no CSC and no resize.

For mem->VDI->PRP VF->mem case, it should already be supported in BSP, in FLOW1 register, VDI_SRC_SEL should be 0x00 ARM, PRP_SCR_DEL should be 0x0 ARM; in flow2 register, PRP_DEST_SEL should  be 0x0 ARM. This is IDMAC 8, 9, 10 -> VDI -> PRP VF -> IDMAC 21 data path, it supports CSC and resize.

For CSI->VDI->PRP VF->mem case, in FLOW1 register, VDI_SRC_SEL should be 0x01 CSI Direct, PRP_SCR_DEL should be 0x5; in flow2 register, PRP_DEST_SEL should

be 0x0 ARM. Channel 5, 12 and 13 are not needed. The PRP VF input is the VDI source, not IDMAC channel.

In "i.MX 6Series Platform SDK", it had already been supported the CSI -> VDI -> PRP VF -> MEM case, you can download it and search the "csi_vdi_direct_path". The IPU setting is same for IMX53 on such use case. That case implemented motion 2 mode, so CH9, CH10, CH13 are not used, only CH 21 was used as the output. You can start from that code.

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&nodeId=018rH3ZrDRB24A&fpsp=1&t...

0 Kudos

2,227 Views
darryln
Contributor II

Qiang Li,

Thank you for describing the required values for FLOW1 and FLOW2 fields.  

Still some areas that need clarification:

  1. How are channels 13, 9, and 10 (VDI inputs) used in the CSI1-VDI-PRVF-mem use case?  The RM says the incoming CSI field is stored to VDI internal FIFO1, and also to memory via chan 13, and the other two input fields come from memory on chans 9 and 10.  This suggests that the buffers for channels 9 and 10 would have to be updated during each field EOF interrupt handler, so they point to the correct field, with respect to the field in FIFO1.  If so, this is complicated and adds CPU overhead, reducing the benefit of using CSI-VDI direct input.   
  2. If the so-called "motion 2 mode" eliminates the CPU overhead of the 3-input method above, it is preferred. It is not documented in the RM. I had already analyzed these CSI direct paths in the Platform SDK, but wasn't sure whether to pursue due to the lack of documentation. Can you provide documentation or a brief description?
  3. Could you please review the CPMEM settings in the previous post.  These are for D1 720x480 UYVY 16 BPP interlaced.
  4. Could you please provide values for the following, for each VDI use case.

            FLOW1.31, VF_IN_VALID = ?

            IC_CONF.31, CSI_MEM_WR_EN=?

            IC_CONF.30, RWS_EN=?

Thanks,

Darryl

0 Kudos

2,227 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

For 1, the VDI can use three fields for de-interlace in motion 0 and motion 1 mode. In this case, channel 9 and 10 are used to send another two fields from memory to VDI, and the channel 13 was used to save the current frame to memory which will be used for next time's de-interlace.
In fact, in this mode, because all frame data will be saved to memory too, it will not reduce system more.

For 2, the motion 2 mode will only handle current field for de-interlace, it can be used for high motion input. In this case, no channel 9, 10 and 13 are needed, the captured data will not be saved to memory. But if the input is static picture, the de-interlaced video quality will be poor in this mode. The motion mode information can be found in reference manual "37.4.11.2.2 Motion Calculator Block (di_mcalc)".

For 3, the CPMEM seems OK for me. You can also dump the setting for MEM->VDI->IC->MEM mode, they should be same.

For 4,  RWS_EN should be 0 in this case. FLOW1.31, VF_IN_VALID and CSI_MEM_WR_EN are not cared.

0 Kudos

2,227 Views
宗標廖
Contributor V

Hello Qiang Li

I am now using the mxc_v4l2_tvin.out to test video in on i.MX6QSabreauto with L3.0.35_4.1.0,

I have some question about it, could you help me?

My questions are below.

Q1:

when run the mxc_v4l2_tvin.out with -m parameter, I think the data flow in IPU is

MEM -> VDIC -> IC -> MEM, and when without -m parameter, I think the data flow is

MEM -> IC -> MEM.Could tell me is it right or not?

Q2:

when I run mxc_v4l2_tvin.out -ow 1024 -oh 768 -m <x> &(x is 0 or 1 or 2), and then rum memtool - 32  0x02668004 4

and memtool - 32  0x02a68004 4, I always got value 00000000 for both addr 0x02668004 and 0x02a68004.

but according to the IMX6DQRM page 2939 and page 2958,  0x02668004 and 0x02a68004 are address

for VDI Control Register(IPU1 and IPU2).I donnot understand why I always got 0, could you help me.

Q3:

I think the De-Interlacing algorithm for IPU VDIC is not contained in the BSP code(Because I have not found it),

So could you tell me the processing flow for -m 0, -m 1 and -m 2.What are the differences among them.

Q4:

the app mxc_v4l2_tvin.out has an optional -tb,after tracing the BSP code,I found if using -tb,the bit30 for

VDI Control Register (IPUx_VDI_C)(IMX6DQRM page 3530) will be set to 0,or it will be set to 1.And according

to the RM, 0 for bit30 represents to top field is field 0 and  1 for bit30 represents to top field is field 1,So could you

tell me what do the field0 and field1 here mean.

I am so sorry to trouble you with so many questions.

Best Regards,

ZongbiaoLiao

0 Kudos

2,227 Views
qiang_li-mpu_se
NXP Employee
NXP Employee

Please create another discussion for for issues, I can answer you there. Thanks!

0 Kudos