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
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.
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
With CSI1_SENS_CONF=02008a30 and IDMAC_CH_EN_1=08a02700, still no VDI EOF interrupts.
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.
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?
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.
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
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
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
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
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));
Result is the same - still no VDI interrupt.
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.
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
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);
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.
Qiang Li,
Thank you for describing the required values for FLOW1 and FLOW2 fields.
Still some areas that need clarification:
FLOW1.31, VF_IN_VALID = ?
IC_CONF.31, CSI_MEM_WR_EN=?
IC_CONF.30, RWS_EN=?
Thanks,
Darryl
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.
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
Please create another discussion for for issues, I can answer you there. Thanks!