IMX8MQ MIPI-CSI2 Base address switching change err occurring randomly

[jgsandom]

Hi NXP community,

I've been facing an issue integrating an IMX378 image sensor with an IMX8MQ when configured for MIPI-CSI over 2 lanes at 1920x1080p @ 80fps. Note that the IMX378 provides progressive video, not interlaced. The kernel being used is linux-imx-4.14.98 and the IMX8 reference manual being referred to is Rev 3 04/2020: IMX8M Reference Manual .

Issue;

The issue seems to occur quite randomly - 50% of the time, I boot and I'm able to stream video successfully with the correct fps. If it works on first boot, then it will continue to work as I stop and start streaming again. However, the other 50% of the time, I am faced with the "Base address switching change error", which persists when attempting to stop and start streaming again. The only way to resolve this is to reboot and hope that it boots in a good state. This is extremely unreliable and I'm in need of a fix!

Attempted fixes;

I've seen that a lot of the community have faced similar issues and have tried various suggestions. See below;

1. One suggestion by @igorpadykov  was that BASEADDR_SWITCH_EN is only applicable for interlaced video sources and it can actually be disabled. Is this true? I haven't seen anything in the documentation about this. Following from this @leolarrel suggested the following patch;

if (pix->field == V4L2_FIELD_INTERLACED)
csi_tvdec_enable(csi_dev, true);
+ else
+ csi_tvdec_enable(csi_dev, false);

1. This ensures that all bits associated to BASEADDR are disabled;  (BIT_TVDECODER_IN_EN | BIT_BASEADDR_SWITCH_EN | BIT_BASEADDR_SWITCH_SEL | BIT_BASEADDR_CHG_ERR_EN). This gets rid of the base address switching error because the interrupt is no longer enabled. However, this doesn't solve the issue entirely as in an error state, there's a drop from 80fps to around 50fps and the resulting video feed has significant amounts of noise and almost seems as though multiple frames are mixed together e.g. I'm seeing incomplete frames overlaid with each other. 

• Another suggestion is that the clocks may be configured incorrectly. I have set the MIPI core clock, MIPI PHY ref clock and MIPI ESC clock to the maximum values stated in the IMX reference manual (MIPI Core Clock: 266MHz, MIPI PHY Clock: 333MHz, MIPI ESC: 133MHz) See below; (I have also tried variations of this, such as setting the MIPI PHY clock to 250MHz and 125MHz)

assigned-clock-rates = <266000000>, <333000000>, <133000000>;

1. Setting the above values didn't solve the base address switching issue. However, it is required to set these values to get any streaming to work at all for my data rate. i.e. setting the above clock values allowed me to stream correctly 50% of the time. 

Debug information;

I had a look at the CSI register values to see if anything stood out when starting the stream. Here is the output;

[   77.614214] CSI_CSICR1: 0x11f0902
[   77.617538] CSI_CSICR2: 0xc0000000
[   77.621067] CSI_CSICR3: 0x10a0
[   77.624257] CSI_STATFIFO: 0x26b026aa
[   77.627960] CSI_CSIRXFIFO: 0x211a2221
[   77.631922] CSI_CSIRXCNT: 0x9600
[   77.635266] CSI_CSISR: 0x92224001
[   77.638695] CSI_CSIDBG: 0x0
[   77.641487] CSI_CSIDMASA_STATFIFO: 0x0
[   77.645350] CSI_CSIDMATS_STATFIFO: 0x0
[   77.649214] CSI_CSIDMASA_FB1: 0xc4100000
[   77.653311] CSI_CSIDMASA_FB2: 0xc4300000
[   77.657348] CSI_CSIFBUF_PARA: 0x0
[   77.660777] CSI_CSIIMAG_PARA: 0x7800438
[   77.664787] CSI_CSICR18: 0xd44ad030
[   77.668389] CSI_CSICR19: 0x2d

 Here we can see that the RXFIFO does have data present, so not sure what the issue is.

I have also seen suggestions to upgrade to the latest kernel (linux-imx-5.4.47) - I had a look at the source code for the relevant IMX8MQ drivers (mx6s_capture.c and mxc-mipi-csi2_yav.c). I didn't see any significant register configuration changes so I don't think this will help.

Does anyone have any ideas on how to finally solve this issue? any help would be appreciated! Thank you.

[t_spil]

We've faced very similar issues integrating a RAW12 720x480p @300fps dept sensor on mipi_csi_1. The imx8mq booting in the failure mode happened about 70-80% of the time. The attached patch seemed to do the trick for us, I mostly stumbled upon this by accident, but I idly wondered why half those registers needed to be disabled for the tv decoding. This patch completely fixed the above issue for us.

Hope this patch works for you too!

[t_spil]

While this patch does fix the base address switching error, every fourth pixel is now incorrect. The received test pattern output is offset by one and every fourth pixel is repeated twice (which makes normal output look alright and why I didn't pick up on this issue straightaway). This seems to happen without fail and not with the same 50-50 ratio as the base address switching error.