AnsweredAssumed Answered

Mipi Csi-2: Capturing RAW12 Data correctly into Memory

Question asked by Michael Koschutnig on Apr 30, 2014
Latest reply on May 22, 2014 by jamesbone
Branched to a new discussion

Hello!
After reading maybe every single discussion about mipi in this forum I still can't get my setup to work so i am looking for help.

I am trying to capture a 12bit sensor's data output on an i.MX6D. Sensor output is not really normal video, but could be interpreted as 12 bit grayscale. The sensor is connected via MIPI Csi-2 and has very few configuration capabilities. The sensor's data type is fixed at RAW12 format, only configurable options are the lanes (1 or 2, i configured 2) and the addition of a current line identifier to the mipi short packets. The sensor is running in non-continuous clock mode, so clock lane goes into STOP mode when no data is transferred.

Sensor resolution is 160x120.

 

Generally i am looking for a working configuration to save the 160x120 data frames to the memory, It doesn't have to work with gstreamer.

My current configuration:
CSI 0 and IPU 0, gpr1 set accordingly, 2 lanes, vchannel 0.
I used the ov5640 driver for reference and left the clock settings in mipi_csi2_reset at 0x14 as I measured a 400MHz clock on the clock lane (DDR: 800MHz -> 0x14).

In my driver file i configured mipi_csi2_set_datatype(mipi_csi2_info, MIPI_DT_RAW12) and i used my own pixelformat for testing. The pixelformat is the same as IPU_PIX_FMT_GENERIC_16 with some changes to the CPMEM parameters.
I have some difficulties to understand the funktion of the bt656 configurations. For the ov5640 it was configured for V4L2_IF_TYPE_BT656_MODE_NOBT_8BIT or V4L2_IF_TYPE_BT656_MODE_NOBT_10BIT, according to the sensor configuration. bt_sync_correct was 1. When I configure it to V4L2_IF_TYPE_BT656_MODE_NOBT_12BIT I am just getting ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0. I don't understand this behaviour, I traced the function of this setting to  mxc_v4l2_capture.c, where it sets the CSI data width. In my opinion, this has to be 12 in my case. Or even 16? I also don't understand the function of bt_sync_correct. Does this have to do with the optional line sync identifiers i can configure on the sensor?

Like I said, i changed the CPMEM configuration to

        ipu_ch_param_set_field(&params, 0, 107, 3, 3);  /* bits/pixel */
        ipu_ch_param_set_field(&params, 1, 85, 4, 6);   /* pix format */
        ipu_ch_param_set_field(&params, 1, 78, 7, 15);  /* burst size */


I also came across configurations regarding gated and non-gated clock modes, but my sensor output doesn't really change when changing those settings. What clock mode would be correct in my setting?

 

My current configuration gives me some data, but the values don't look right.

 

Last but not least i am unsure about how my data is processed on it's way. My current understanding: The RAW12 transmission is rearranged by the csi-receiver and put into a 32 bit buffer. the buffer goes to the CSI2IPU gasket and gets cut up into a 16 bit data buffer. What happens at the IPU with this buffer? Does it get cut up into the "real" bits according to CPMEM configuration and expandet to 16 bit pixel data?

 

Thank you for any answer to my problems...

Outcomes