MIPI CSI2 - MEM_PRP_VF_MEM question

[meflo]

Hi everybody,

I am trying to get some video capture working using MIPI CSI2 and I am having the following issue.

I am able to capture video, but the video is in a grid view of 2 x 2. Meaning, the video is shown 4 times, each window smaller, side by side in a grid instead of the normal picture.

I am using "CSI MEM":

static struct v4l2_input mxc_capture_inputs[MXC_V4L2_CAPTURE_NUM_INPUTS] = {

        {

         .index = 0,

         .name = "CSI IC MEM",

         .type = V4L2_INPUT_TYPE_CAMERA,

         .audioset = 0,

         .tuner = 0,

         .std = V4L2_STD_UNKNOWN,

         .status = 0,

         },

        {

         .index = 1,

         .name = "CSI MEM",

         .type = V4L2_INPUT_TYPE_CAMERA,

         .audioset = 0,

         .tuner = 0,

         .std = V4L2_STD_UNKNOWN,

         .status = V4L2_IN_ST_NO_POWER,

         },

};

My sensor is outputting YUV422 and I do not need any preprocessing done (don't need to resize the video or rotate it).

But apparently the stream goes through MEM_PRP_VF_MEM somehow, and that is why I get the grid view video in the end.

ipu_init_channel() inits the channel as MEM_PRP_VF_ENC.

How could I not use PRP VF so the YUV422 stream from the sensor is available to v4l2 capture as is?

Thanks

[meflo]

Here's how the captured image looks like:

Dropbox - 20150129_102941.jpg

That is using V4L2_PIX_FMT_UYVY in my driver.

If I use V4L2_PIX_FMT_YUV420, I get a 2x4 grid.

The driver enabled mipi using datatype:

mipi_csi2_set_datatype(mipi_csi2_info, MIPI_DT_YUV422);

The images are stable, not scrolling, but you can see some slight color issues (seems to be a bit greenish) and the fact that it actually displays the frames in the space of a grid of 2 x 2. Sometimes it displays the entire 4 frames, sometimes like in the picture it displays some of the frames full and the others with some hsync and vsync issues.

[meflo]

IPUx_CSI0_SENS_CONF is 0x00008A32

IPUx_CSI0_ACT_FRM_SIZE is 0x023F02CF

The above registers look to be good but the issue is there

[meflo]

On second thought, IPUx_CSI0_SENS_CONF shows the CSI data width is 8 bits. I would have expected that to be 16 bits for YUV422

[meflo]

From imx6 dual/duad Reference Manual:

37.4.3.2.2

High-speed serial interface - MIPI (Mobile Industry Processor

Interface).

In MIPI interface two values arrive in each cycle. Each value is 8 bit wide, which means

16 MSB bits of the data bus input are treated, while 4 LSB bits are ignored.

When working in this mode, the CSI can handle up to 4 streams of data. Each stream is

identified with DI (data identifier) that includes the virtual channel and the data type of

this stream. Each stream that is handled is defined in registers MIPI_DI0-3. Only the

main stream (MIPI_DI0) can be sent to all destination units while the other streams are

sent only to the SMFC as generic data.

In this mode SENS_DATA_FORMAT and DATA_WIDTH registers are ignored, since

this information is coming to the CSI via the MCT_DI bus.

[qiang_li-mpu_se]

What's the MIPI virtual channel do you use? If it is not 0, please reference to this patch: https://community.freescale.com/docs/DOC-102233

[meflo]

Hi Qiang,

I use virtual channel 1.

I applied the patch above, but now I get:

ERROR: v4l2 capture: mxc_v4l_dqueue counter 0

VIDIOC_DQBUF failed.

[qiang_li-mpu_se]

Please pay attention to GPR1 or GPR13 setting.

[meflo]

Any thought to why it goes through MEM_PRP_VF_ENC?

I am using the path CSI -> MEM. But apparently, once the data goes to memory, it goes through PRP VF and I suspect that is why I get that w eird image (wrong color and multiple images instead of one). How can I make it so the PRP is not used?

[meflo]

Also, that image I get is using bt656 synchronization.

For example, in ov5640_mipi.c driver, it is:

p->u.bt656.clock_curr = ov5640_data.mclk;

So clock_curr is nonzero. Thus, in mxc_v4l2_capture.c:

       if (ifparm.u.bt656.clock_curr == 0)

                csi_param.clk_mode = IPU_CSI_CLK_MODE_CCIR656_INTERLACED;

        else

                csi_param.clk_mode = IPU_CSI_CLK_MODE_GATED_CLK;

looks like the gated mode is used for ov5640_mipi..

In my driver, clock_curr is set to zero, so IPU is configured to be in BT 656 interlaced mode.

However, the imx6 Reference Manual states that when using MIPI, non-gated mode must be used. How does it work for ov5640? In my case, I do not have a mclk from imx6 to my video decoder.

[qiang_li-mpu_se]

Your original issue means virtual channel was not set correct on iMX6, so I gave you the patch for not virtual channel 0 case, but that sample code is for virtual channel 3, you should do some modification for virtual channel 1 case.

Your new timeout issue means the patch hasn't been successfully merged, no data coming to IPU CSI side.

[meflo]

Hi Qiang. My original issue was that the image I receive seems to be going through the PRP and somehow converted to a different format so I get wrong colors and multiple images.

Regarding your patch, I did the changes for virtual channel 1 and get no data. So I am back to my case, wondering how to bypass the PRP.

[qiang_li-mpu_se]

Hi Meton, if you are using the mxc_v4l2_tvin test application, the data path was fixed at CSI->MEM, no PRP will be used.

In fact I had seen the wrong virtual channel case, the captured image is same as yours.

By the way, you'd better enable your camera on virtual channel 0 first.

[meflo]

The MIPI clock rate I have is 108 MHz. So I have set DDR at 216 MHz.

Now, if using bt656 synchronization, what should the clock_curr value be in the driver? I do not have the mclk line (master clock) from the imx to the decoder.

I am on kernel 3.0.35

It's not clear on how the non-gated mode is used for MIPI

[qiang_li-mpu_se]

For clock_curr, it can be any non-0 value.

[meflo]

So if it is any non zero value, then it will go into gated mode,according to the BSP. But the reference manual says it must be non gated for mipi

[qiang_li-mpu_se]

In real test, both gated and non gated clock mode work on MIPI CSI2 input.

You can reference to this link to debug your MIPI sensor: https://community.freescale.com/thread/307065

[meflo]

Hi Qiang,

I managed to get it working but the image I get is interlaced.

Using "-m" for mxc_v4l2_tvin did not help though

[qiang_li-mpu_se]

In ipu_csi_enc.c, function csi_enc_setup(), please change it to "params.csi_mem.interlaced = true;".

case IPU_CSI_CLK_MODE_GATED_CLK:

case IPU_CSI_CLK_MODE_NONGATED_CLK:

case IPU_CSI_CLK_MODE_CCIR656_PROGRESSIVE:

case IPU_CSI_CLK_MODE_CCIR1120_PROGRESSIVE_DDR:

case IPU_CSI_CLK_MODE_CCIR1120_PROGRESSIVE_SDR:

  params.csi_mem.interlaced = false;

[meflo]

One small issue however. The image that is output has the colors inverted. Red is blue and blue is red. That is on the main display. On the second display the image is shown with correct colors. Is this something that android can address or is it more from the bsp side?

Thanks

[qiang_li-mpu_se]

I think you can check the "fbpix" setting for your two displays.

Function mxcfb_option_setup() in file "drivers\video\mxc\mxc_ipuv3_fb.".