i.MX6 MIPI CSI with OV13850 driver porting

[m_c]

1. We are using OV13850 (10 bit RAW) sensor with IMX6. As 10 bit mode is not supported, it is packed into 16 bit mode as mentioned in Manual section 37.4.3.7. We would like to know how the additional 6 bits are padded to form a 16 bit data.

Ex- Suppose, the sensor sends data (1010001011 - RAW 10 - 10 Bits); after the IPU, do we get [9:0, 9:4] which is [1010001011 101000 - 16 bits] == 0xA2 0xE8 ?

2. Also we do not have any external vsync line. We observe that our frames are unsynchronized. Do we need to make any additional configuration for vsync or is it handled via MIPI bus itself?

[weidong_sun]

Hello Mike,

   1. Reference Manual:

MIPI CIS-2 of i.MX6 can support RAW 10 bit data from camera. See i.MX6Q reference manula, please!

2. Linux and android BSP support OV5640 MIPI

See OV5640's internal diagram, please!

3. other camera sensors of OV

(1) OV5645

I have ever ported ov5645 to i.MX6 Serials platform(I.MX6Q/D/DL/S) , which is no any problems.

BUT you will have to pay attention to ISP & Formattter function in OV chip, which is used to convert image format to what CPU can support. For example , OV5640 & OV5645's output will be converted to YUV format for CPU MIPI CSI-2, then mxc_v4l2_capture driver receive data and handle it.

If in OV's chip there is no ISP and formatter, RAW data will be output to MIPI CSI-2 interface of CPU,  MIPI interface can receive it normally, BUT there is no follow-up processing for these data, so you can see image displayed on screen.

(3)OV5647 & OV5648

ISP is not supported by OV5647

ISP is supported, BUT there is no formatter, so customer should confirm if the ISP can convert image format to YUV or RGB for what MIPI CSI-2 of CPU requires.

(4)Finally, let's look at the internal functions of ov13850.

From above diagram, we can find OV13850's functions are very similar to those of OV5648. There is also no FORMATTER in it, which means it only supports RAW data output,  so capture driver only receive these data , not handle it.

Hope above information is helpful for you.

Have a nice day!

BR,

weidong

[arunkumar_ev]

Hello Wigros,

Thanks for the response.

We are aware of the fact that OV13850 does not support any internal processing from RAW to YUV format and imx6 IPU does not have any block for demosaicing or interpolation.

Our goal is to capture raw dump from sensor and perform software processing. While running our entire setup in 8 bit mode configuration we receive a raw dump and after conversion to RGB888, the test pattern seems to be proper. Attached snapshot (test_pattern_8bit.png) for the same. But while running the setup in 10 bit mode configuration, we observe multiple frames being clubbed in one single dump. Attached snapshot (test_pattern_10bit.png) for the same. (converted to greyscale).

Both of above test was performed with resolution of 2112x1568.We are using standard v4l2 ioctl calls to get the dump.

Can you give suggestions on the following:

1) In case of 10 bit mode the size was configured as:

                       size = width * height * 2 (as specified in RM that only 8 or 16 bit is supported at IPU)

We observe that the dump we receive has a size of 6.4M (each pixel of 16 bits). Since it is a 10 bit mode, we would like to know how these additional 6 bits are added? Or is the final dump we receive packed in same format as mentioned in "RAW10 data reception" screenshot?

2) At times while capturing the image we receive the following warning indicating new frame before EOF of previous frame:

                                 imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_5 = 0x00000002

    Any suggestions?

Thanks & Regards,

Arun Kumar

[weidong_sun · Accepted solution]

Hi Arun,

   The capture of raw data is saved in memory according to the original format, which has nothing to do with the display image.

   Did you understand above descriptions on "RAW10 data Recepation" ?

   For example, 4 sets of 10bit data, a[9:0], b[9:0],c[9:0],d[9:0] will be saved to 32bit(4 Bytes) of memory.  a[9:2],b[9:2],c[9:2],d[9:2] are saved to the word(32bit), then a[1:0], b[1:0],c[1:0],d[1:0] will be saved to another new word.

it means this ensures 8-bit alignment.

Have a nice day!

BR,

Weidong