Getting an 'err_id_vc0' error on iMX6 MIPI-CSI

erezsteinberg · ‎11-11-2014

Hello experts,

I'm working on a device driver for a Sony IMX208 MIPI Image Sensor for the iMX6 on Linux 3.0.35.

My MIPI is set up as follows:

mipi_csi2_info:

mipi_csi2_info.mipi_en = 1

mipi_csi2_info.ipu_id = 0

mipi_csi2_info.csi_id = 0

mipi_csi2_info.v_channel = 0

mipi_csi2_info.lanes = 1

mipi_csi2_info.datatype = 0x2b (RAW10)

I am able to communicate with the sensor over I2C and everything seems to be working. However, starting the stream and waiting for buffers (using select()), no buffers are available. I have 'DEBUG' enabled for the drivers; the log I get is:

In MVC:mxc_streamon

YUYV

In MVC:mxc_poll

In MVC:mxc_v4l_ioctl

In MVC: mxc_v4l_do_ioctl c0445611

case VIDIOC_DQBUF

In MVC:mxc_v4l_dqueue

ERROR: v4l2 capture: mxc_v4l_dqueue() interrupt received

fps=In MVC:mxc_v4l_ioctl

If I check the CSI-MIPI Error registers, I see an err_id_vc0 in MIPI_CSI_ERR2 ("Unrecognized or unimplemented data type detected in Virtual Channel 0"). I tried both RAW8 and RAW10 formats, and I get the same error. According to MIPI-CSI2 Specs, this would be an "Unrecognized ID, caused by the presence of an unimplemented or unrecognized ID in the header", and the proposed receiver behavior "to indicate that the data packet is unidentified and cannot be unpacked by the receiver". So, my guess is that the MIPI-CSI2 hardware detects an error and doesn't forward any data, and that's why dqbuf fails.

But -- I don't understand why this error is happening!

Does anyone know of possible reasons for such an error to occur?

Any recommendations how to debug this issue?

Regards,

Erez

erezsteinberg · ‎11-24-2014

Just to close the issue --- the problem was due to a non-standard data-type generated by the Sony Sensor.

The error message from the iMX6 CSI2 was correct.

After disabling the generation of the datatype by the sensor, the error is now gone.

Thanks to everyone for all the help.

View solution in original post

meflo · ‎01-30-2015

I managed to get it working.

But now I have a different issue.

I've opened another discussion here https://community.freescale.com/thread/340507

kurkinalexandr · ‎05-20-2016

Hello. Could you explain, how you solved your issue. I have the same problem - get 0x210 mipi status value.

erezsteinberg · ‎11-24-2014

Just to close the issue --- the problem was due to a non-standard data-type generated by the Sony Sensor.

The error message from the iMX6 CSI2 was correct.

After disabling the generation of the datatype by the sensor, the error is now gone.

Thanks to everyone for all the help.

allencao · ‎11-12-2014

Hi Erez,

It seems you set wrong data type of MIPI-CSI2 (something like: mipi_csi2_set_datatype(mipi_csi2_info, MIPI_DT_RGB888);

Please provide a detailed DS & AN of IMX208, thanks!

B.R.

Allen Cao

erezsteinberg · ‎11-12-2014

Hi Allen,

I set MIPI_DT_RAW8 and MIPI_DT_RAW10, and I can see the correct value in mipi_csi2_info.datatype = 0x2b.

Besides, I looked at the source for mipi_csi2_set_datatype(), and it doesn't seem to actually do anything with the type. Also, I couldn't find any registers in iMX6 that can be configured for different data types.

I cannot provide DS for IMX208 (It's under NDA).

I will say that:

(1) the IMX208 spec says the 'Data Identifier' is made of 2-bit virtual channel + 6 bits Data types

(2) Virtual Channel is configurable (set to 0 in my case)

(3) Data types generated by IMX208 are:

6'h00 FRAME START CODE

6'h01 FRANE END CODE

6'h10 Null (Invalid data / dummy data)

6'h12 Embedded Data (not transmitted by default)

6'h13 OPB Data

6'h2a RAW8

6'h2b RAW10

Regards,

Erez

allencao · ‎11-12-2014

Hi E,

Pls dump all the MIPI-CSI2 registers, thanks!

BTW, can you share your driver code, only MIPI-CSI2 part is OK?

B.R.

Allen Cao

erezsteinberg · ‎11-12-2014

Hi Allen,

Thanks for looking into this problem.

I attached the driver source code.

Here are the registers. PHY_STATE is not stable and changes between values 0x310 0x610 0x300

[root@erez]# devmem 0x21dc000

0x3130302A

[root@erez]# devmem 0x21dc004

0x00000000

[root@erez]# devmem 0x21dc008

0x00000001

[root@erez]# devmem 0x21dc00c

0x00000001

[root@erez]# devmem 0x21dc010

0x00000001

[root@erez]# devmem 0x21dc014

0x00000310

[root@erez]# devmem 0x21dc018

0x00000000

[root@erez]# devmem 0x21dc020

0x00000000

[root@erez]# devmem 0x21dc024

0x00001000

[root@erez]# devmem 0x21dc02c

0x00000000

[root@erez]# devmem 0x21dc030

0x00000000

[root@erez]# devmem 0x21dc034

0x00001414

allencao · ‎11-12-2014

Hi E,

There are some errs @ D-PHY Level. Please refer the following link to check your MIPI-CSI2 config:

Debug steps for customer MIPI sensor.docx

Please pay attention to the "Check the clock setting" section.

B.R.

Allen Cao

erezsteinberg · ‎11-12-2014

Hi -

How do you see there are errs @ D-PHY Level?

The IMX208 sensor for Raw10, MIPI 1 Lane, 30 fps has a Data Rate of 405 Mbps/Lane.

However, I configures the IMX208 MIPI Global Timing to 780 .. 900 MHz.

If I set MIPI Global Timing to 400 .. 460 I get a lot of errors on the CSI2 error registers.

Should I also change mipi_csi2_reset() in mxc_mipi_csi2.c ?

Currently it has:

	mipi_csi2_write(info, 0x00000001, CSI2_PHY_TST_CTRL0);
	mipi_csi2_write(info, 0x00000000, CSI2_PHY_TST_CTRL1);
	mipi_csi2_write(info, 0x00000000, CSI2_PHY_TST_CTRL0);
	mipi_csi2_write(info, 0x00000002, CSI2_PHY_TST_CTRL0);
	mipi_csi2_write(info, 0x00010044, CSI2_PHY_TST_CTRL1);
	mipi_csi2_write(info, 0x00000000, CSI2_PHY_TST_CTRL0);
	mipi_csi2_write(info, 0x00000014, CSI2_PHY_TST_CTRL1);
	mipi_csi2_write(info, 0x00000002, CSI2_PHY_TST_CTRL0);
	mipi_csi2_write(info, 0x00000000, CSI2_PHY_TST_CTRL0);

Should I just change the 0x00000014 to 0x0000000c ?

Regards,

Erez

Yuri · ‎11-12-2014

As for the mentioned Debug steps for customer MIPI sensor.docx :

27 MHz clock source is used there, please use the patch below to set mipi-csi2 dphy clock,
based on the ref_clk out is 24M.
The patch is intended for "linux-2.6-imx/drivers/mxc/mipi/mxc_mipi_csi2.c"

===========

--- mxc_mipi_csi2.c.orig

+++ mxc_mipi_csi2.c

@@ -272,7 +272,46 @@

* @param info mipi csi2 hander

* @return Returns 0 on success or negative error code on fail

*/

-int mipi_csi2_reset(struct mipi_csi2_info *info)

+

+struct _dphy_calib {

+ u32 low, high, val;

+};

+

+static struct _dphy_calib dphy_calib_data[] =

+{

+ {80, 90,0x00},

+ {90,100,0x10},

+ {100,110,0x20},

+ {110,125,0x01},

+ {125,140,0x11},

+ {140,150,0x21},

+ {150,160,0x02},

+ {160,180,0x12},

+ {180,200,0x22},

+ {200,210,0x03},

+ {210,240,0x13},

+ {240,250,0x23},

+ {250,270,0x04},

+ {270,300,0x14},

+ {300,330,0x04},

+ {330,360,0x15},

+ {360,400,0x25},

+ {400,450,0x06},

+ {450,500,0x16},

+ {500,550,0x07},

+ {550,600,0x17},

+ {600,650,0x08},

+ {650,700,0x18},

+ {700,750,0x09},

+ {750,800,0x19},

+ {800,850,0x0a},

+ {850,900,0x1a},

+ {900,950,0x2a},

+ {950,1000,0x3a},

+ {0,0,0}

+};

+

+int mipi_csi2_reset(struct mipi_csi2_info *info, u32 freq)

{

_mipi_csi2_lock(info);

@@ -286,7 +325,27 @@

mipi_csi2_write(info, 0x00000002, CSI2_PHY_TST_CTRL0);

mipi_csi2_write(info, 0x00010044, CSI2_PHY_TST_CTRL1);

mipi_csi2_write(info, 0x00000000, CSI2_PHY_TST_CTRL0);

- mipi_csi2_write(info, 0x00000014, CSI2_PHY_TST_CTRL1);

+ {

+ int i = 0;

+ freq<<=1;

+ while(dphy_calib_data[i].low ||

+ dphy_calib_data[i].high ||

+ dphy_calib_data[i].val)

+ {

+ if(freq >= dphy_calib_data[i].low &&

+ freq <= dphy_calib_data[i].high)

+ {

+ mipi_csi2_write(info, dphy_calib_data[i].val << 1, CSI2_PHY_TST_CTRL1);//270-300

+ printk(KERN_ERR "%s: D-PHY calib for %d: %x", __FUNCTION__, freq, dphy_calib_data[i].val);

+ break;

+ }

+ i++;

+ }

+// mipi_csi2_write(info, 0x00000014, CSI2_PHY_TST_CTRL1);//800-850

+// mipi_csi2_write(info, 0x00000028, CSI2_PHY_TST_CTRL1);//270-300

+// mipi_csi2_write(info, 0x00000044, CSI2_PHY_TST_CTRL1);//180-200

+// mipi_csi2_write(info, 0x00000022, CSI2_PHY_TST_CTRL1);//125-140

+ }

mipi_csi2_write(info, 0x00000002, CSI2_PHY_TST_CTRL0);

mipi_csi2_write(info, 0x00000000, CSI2_PHY_TST_CTRL0);

=============
Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Danube · ‎10-07-2015

Hi Sir,

I saw your struct in not the same Debug steps for customer MIPI sensor.docx define.

May I need to update to your dphy_calib_data[] ?

+static struct _dphy_calib dphy_calib_data[] =

+{

+ {80, 90,0x00},

+ {90,100,0x10},

+ {100,110,0x20},

+ {110,125,0x01},

+ {125,140,0x11},

+ {140,150,0x21},

+ {150,160,0x02},

+ {160,180,0x12},

+ {180,200,0x22},

+ {200,210,0x03},

+ {210,240,0x13},

+ {240,250,0x23},

+ {250,270,0x04},

+ {270,300,0x14},

+ {300,330,0x04},

+ {330,360,0x15},

+ {360,400,0x25},

+ {400,450,0x06},

+ {450,500,0x16},

+ {500,550,0x07},

+ {550,600,0x17},

+ {600,650,0x08},

+ {650,700,0x18},

+ {700,750,0x09},

+ {750,800,0x19},

+ {800,850,0x0a},

+ {850,900,0x1a},

+ {900,950,0x2a},

+ {950,1000,0x3a},

+ {0,0,0}

+};

Debug steps for customer MIPI sensor.docx

The range and the exact value when ref_clock is 27M are showed as below:

#define PLL_CLK 0x32 //783Mhz

// clock_range : register value // exact value when ref clock is 27M

// 950-1000MHz :0x74 //999Mhz

// 900-950Mhz :0x54 //972Mhz

// 850-900Mhz :0x34 //900Mhz

// 800-850MHz :0x14 //849Mhz

// 750-800MHz :0x32 //783Mhz

// 700-750Mhz :0x12 //750Mzh

// 650-700Mhz :0x30 //699Mhz

// 600-650MHz :0x10 //648Mhz

// 550-600MHz :0x2e //600Mhz

// 500-550Mhz :0x0e //549Mhz

// 450-500Mhz :0x2c //486Mhz

// 400-450MHz :0x0c //450Mhz

// 360-400MHz :0x4a //399Mhz

// 330-360Mhz :0x2a //360Mhz

// 300-330Mhz :0x48 //330Mhz

// 270-300MHz :0x28 //300Mhz

// 250-270MHz :0x08 //270Mhz

// 240-250Mhz :0x46 //249Mhz

// 210-240Mhz :0x26 //240Mhz

// 200-210MHz :0x06 //210Mhz

// 180-200MHz :0x44 //198Mhz

// 160-180Mhz :0x24 //180Mhz

// 150-160MHz :0x04 //159Mhz

// 140-150MHz :0x42 //150Mhz

// 125-140MHz :0x22 //135Mhz

// 110-125MHz :0x02 //123Mhz

// 100-110Mhz :0x40 //108Mhz

// 90-100Mhz :0x20 //99Mhz

// 80-90Mhz :0x00 //90Mhz (default)

erezsteinberg · ‎10-13-2015

It's for different ref_clk ... the doc is for 27Mhz, and mine was for 24MHz

meflo · ‎01-19-2015

Hi Yuri,

I have a question about the reference clock (mclk). Is it the clock that that camera sensor is using internally to function?

I am using an analog to digital decoder, so I am trying to understand what this mclk is supposed to be in my case.

Thank you

Yuri · ‎01-19-2015

The i.MX6 MCLK (Master clock) is just an output reference clock
for an external camera, which may be used by the camera - if needed -
for sync signal generation.

~Yuri.

meflo · ‎01-19-2015

Hi yuri,

thanks for the response.

My camera (analog to digital decoder in my case) gets it's clock from an 28,63 MHz oscillator. I believe this generates internally a 27 MHz clock. My decoder outputs a MIPI clock of 108 MHz to the imx6. Summing up, this means I should just do the following change:

mipi_csi2_write(info, 0x00000044, CSI2_PHY_TST_CTRL1);

without other changes in mxc_mipi_csi2.c file, right?

And from my driver, I should also call set_mclk_rate() to set mclk to 27000000 ?

Thank you.

Yuri · ‎01-19-2015

You may just apply the patch, mentioned in the thread - as is.

~Yuri.

meflo · ‎01-19-2015

The problem in my case is that mipi_csi2_get_error1() and mipi_csi2_get_error2() both return 0.

It is mipi_csi2_dphy_status() that returns 0x210 (I am on a 1 lane configuration). And apparently 0x210 means the phy_rxclkactivehs bit is not set.

This is why I am stuck on the clock changes that need to be done.

I did try your patch and I get the same 0x210.

Any ideas?

Thanks

erezsteinberg · ‎01-19-2015

Are you sure the sensor is enabled and streaming?

meflo · ‎01-20-2015

I measured the clock coming from the analog decoder. It is 108 MHz

erezsteinberg · ‎11-13-2014

Hi Yuri,

I did a fresh port of my BSP to L3.0.101 today, and I still get the same issue.

So, I wrote a 'scanner' to try all values from 0 to 255 in CSI2_PHY_TST_CTRL1.

The scan starts with resetting the IMX208 sensor, then resetting the MIPI-CSI2, and then reading the error registers and DPHY_STAT.

I get something like:

------- imx208 D-PHY Scan ---------

DPHY VAL 0 - err1 = 0x10000111 err2 = 0x1110 (300 / 300 / 310)

DPHY VAL 1 - err1 = 0x110 err2 = 0x1110 (300 / 300 / 300)

DPHY VAL 2 - err1 = 0x111 err2 = 0x1110 (300 / 300 / 300)

DPHY VAL 3 - err1 = 0x10000110 err2 = 0x1110 (310 / 310 / 310)

DPHY VAL 4 - err1 = 0x111 err2 = 0x1010 (300 / 300 / 300)

DPHY VAL 5 - err1 = 0x110 err2 = 0x1010 (300 / 300 / 300)

DPHY VAL 6 - err1 = 0x111 err2 = 0x1010 (300 / 300 / 300)

DPHY VAL 7 - err1 = 0x110 err2 = 0x1000 (310 / 310 / 300)

DPHY VAL 8 - err1 = 0x111 err2 = 0x1010 (300 / 300 / 300)

DPHY VAL 9 - err1 = 0x110 err2 = 0x1000 (300 / 300 / 300)

DPHY VAL 10 - err1 = 0x1 err2 = 0x1000 (300 / 300 / 300)

DPHY VAL 11 - err1 = 0x110 err2 = 0x1000 (300 / 300 / 300)

DPHY VAL 12 - err1 = 0x0 err2 = 0x1000 (300 / 300 / 300)

:

DPHY VAL 155 - err1 = 0x0 err2 = 0x0 (220 / 220 / 220)

DPHY VAL 156 - err1 = 0x0 err2 = 0x1000 (310 / 310 / 310)

DPHY VAL 157 - err1 = 0x0 err2 = 0x1000 (310 / 310 / 300)

DPHY VAL 158 - err1 = 0x0 err2 = 0x0 (300 / 300 / 300)

DPHY VAL 159 - err1 = 0x111 err2 = 0x1010 (300 / 300 / 300)

DPHY VAL 160 - err1 = 0x111 err2 = 0x1010 (300 / 300 / 300)

DPHY VAL 161 - err1 = 0x111 err2 = 0x1010 (300 / 300 / 300)

DPHY VAL 162 - err1 = 0x1 err2 = 0x1000 (310 / 310 / 310)

I got 3 values that did not result in errors during the scan, and with expected D-PHY STAT values (300 / 310)

But, even when I use these values, i eventually see errors on err1/err2.

So -- no value gives correct results.

What else could I try?

Getting an 'err_id_vc0' error on iMX6 MIPI-CSI

Getting an 'err_id_vc0' error on iMX6 MIPI-CSI

i.MX6_All

Linux

Multimedia