IMX8MM MIPI CSI camera 'base address switching change error' on RAW8

[mazpeitia_ikerlan]

Hello, we are trying to integrate a 1600x1400@30fps 2 lane MIRA220 camera on a i.MX8MM, and so far we have been able to succesfully obtain RAW12 and RAW10 frames.

However, when we try to obtain RAW8 frames we get the dreaded 'base address switching change error' message from the mx6s_capture.c driver.

Now, by applying the patch mentioned on this post by NXP user 'joanxie'

https://community.nxp.com/t5/i-MX-Processors/IMX8MM-Camera-IMX298-module-bringup/m-p/1986712

static int mx6s_csi_enable(struct mx6s_csi_dev *csi_dev)

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

/* For mipi csi input only */
if (csi_dev->csi_mipi_mode == true) {

We have been able to get rid of that error and obtain frames, but these do not look good at all.

Here we see a diagonal gradient test pattern obtained when using RAW12 which is correct:

And here what we are obtaining when using RAW8:

This other image also shows a RAW8 picture. It looks like the channels are displaced? as you can kind of see the face "split up".

We have also tried applying the patch mentioned by NXP employee 'haidong_zheng' here:

https://community.nxp.com/t5/i-MX-Processors/MIPI-Camera-Frame-corruption-in-IMX8MM-when-MIPI-DOUBLE...

But this is what we obtain with the test pattern:

[Bio_TICFSL]

Hello,

The "base address switching change error" you're experiencing with RAW8 format is a known issue with the i.MX8MM MIPI-CSI interface. This error occurs when frame switching happens before the DMA can complete data transfer.

## Analysis of Your Issue

Based on your description and test images, the problem appears to be related to how the CSI driver handles different RAW formats. While RAW12 and RAW10 work correctly, RAW8 exhibits corrupted frames with what looks like displaced color channels.

## Recommended Solution

There are two approaches to resolve this issue:

1. **First approach** (joanxie's patch):
- This patch removes the line `cr18 |= csi_dev->soc->baseaddr_switch` in mx6s_capture.c
- While this eliminates the error message, it doesn't properly fix the frame corruption issue you're experiencing

2. **Better approach** (recommended):
- Modify the mx6s_capture.c driver to properly handle RAW8 format:
- Add an "else" clause to the csi_tvdec_enable() function:

```
--- a/drivers/media/platform/mxc/capture/mx6s_capture.c
+++ b/drivers/media/platform/mxc/capture/mx6s_capture.c
@@ -750,6 +751,8 @@ static int mx6s_csi_enable(struct mx6s_csi_dev *csi_dev)
if (pix->field == V4L2_FIELD_INTERLACED)
csi_tvdec_enable(csi_dev, true);
+ else
+ csi_tvdec_enable(csi_dev, false);
/* For mipi csi input only */
if (csi_dev->csi_mipi_mode == true) {
```

This patch ensures proper control of BIT_BASEADDR_SWITCH_EN, BIT_BASEADDR_SWITCH_SEL, and BIT_BASEADDR_CHG_ERR_EN in the CSI_CR18 register.

## Additional Considerations

- Check if your pixel format configuration is correct for RAW8
- Verify if the camera is properly providing RAW8 data
- For RAW8 format, ensure the csi_dev->csi_two_8bit_sensor_mode is properly set

Hope this helps

Regards

[mazpeitia_ikerlan]

Hi, thanks for the fast reply.

I have already applied the patch mentioned in your second "Better approach", but the frames are corrupted as shown in my original post.

I also already have the 'fsl,two-8bit-sensor-mode' attribute on my dts which should be enabling csi_dev->csi_two_8bit_sensor_mode. This is my dts:

Could the error be related to the 'dma-coherent' attribute? And what about the MIPI clocks? I have seen in other threads that changing the clock speed can fix the error, but modifying the 'clock-frequency' and 'link-frequencies' values does not seem to have any effect at all

&mipi_csi_1 {
	status = "okay";
	clock-frequency = <456000000>;
	port {
		#address-cells = <1>;
		#size-cells = <0>;

		mipi1_sensor_ep: endpoint@1 {
			reg = <1>;
			remote-endpoint = <&mira220_mipi1_ep>;
			data-lanes = <2>; 
			csis-hs-settle = <10>;
			csis-clk-settle = <0>;
			csis-wclk;
		};

		csi1_mipi_ep: endpoint@2 {
			reg = <1 2>;
			remote-endpoint = <&csi1_ep>;
		};
	};
};

&csi1_bridge {
	fsl,mipi-mode;
	fsl,two-8bit-sensor-mode;
	dma-coherent;
	status = "okay";
	port {
		csi1_ep: endpoint {
			remote-endpoint = <&csi1_mipi_ep>;
		};
	};
};

&i2c2 {
	clock-frequency = <400000>;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_i2c2>;
	status = "okay";

	mira220: mira220@10 {
		compatible = "ams,mira220";
		reg = <0x54>;
		status = "okay";

		vana-supply = <&cam1_reg>;	/* 2.8v */
		vdig-supply = <&cam_dummy_reg>;	/* 1.8v */
		vddl-supply = <&cam_dummy_reg>;	/* 1.2v */

		clocks = <&clk IMX8MM_CLK_CLKO1>;
		clock-names = "xclk";
		assigned-clocks = <&clk IMX8MM_CLK_CLKO1>;
		assigned-clock-parents = <&clk IMX8MM_CLK_24M>;
		assigned-clock-rates = <24000000>;
		csi_id = <0>;
		mclk = <24000000>;
		mclk_source = <0>;

		port {
			mira220_mipi1_ep: endpoint {
				remote-endpoint = <&mipi1_sensor_ep>;
				clock-lanes = <0>;
				data-lanes = <1 2>;
				// clock-noncontinuous;
				link-frequencies =
					/bits/ 64 <456000000>;
			};
		};
	};

};