i.MX8M Plus dual MIPI camera: CSI-2.1 not leaving ULPS state

[mfoerst]

Hello everybody,

I am trying to run two IMX258 cameras on the two MIPI ports of the i.MX8MP.

After the required modifications to the camera driver and the device-tree, I am able to stream frames from both cameras.

However, for the second camera (connected to mipi_csi_2.1) the streaming works only one time after a reboot. When stopping the stream and starting it again, no frames are received anymore. After a reboot of the device, it works again for a single time.

Both cameras are the same models and use the same driver, but the problem only exists for the one connected to the second MIPI port.

I checked the CSI status registers and it turned out that the only difference between the first (successful) and the second (failing) streaming is the ULPSCLK bit in the CSIS_DPHYSTATUS register:

These are the CSI registers for the successful stream:

mxc-mipi-csi2.1: --- mipi_csis_s_stream --- 
mxc-mipi-csi2.1: CSIS_VERSION[0]: 0x03060301 
mxc-mipi-csi2.1: CSIS_CMN_CTRL[4]: 0x00004905 
mxc-mipi-csi2.1: CSIS_CLK_CTRL[8]: 0x000f0000 
mxc-mipi-csi2.1: CSIS_INTMSK[10]: 0x0fffff1f 
mxc-mipi-csi2.1: CSIS_INTSRC[14]: 0x00000000 
mxc-mipi-csi2.1: CSIS_DPHYSTATUS[20]: 0x000000f0 
mxc-mipi-csi2.1: CSIS_DPHYCTRL[24]: 0x1c800007 
mxc-mipi-csi2.1: CSIS_DPHYBCTRL_L[30]: 0x000001f4 
mxc-mipi-csi2.1: CSIS_DPHYBCTRL_H[34]: 0x00000000 
mxc-mipi-csi2.1: CSIS_DPHYSCTRL_L[38]: 0x00000000 
mxc-mipi-csi2.1: CSIS_DPHYSCTRL_H[3c]: 0x00000000 
mxc-mipi-csi2.1: CSIS_ISPCONFIG_CH0[40]: 0x000000ac 
mxc-mipi-csi2.1: CSIS_ISPCONFIG_CH1[50]: 0x000008fd 
mxc-mipi-csi2.1: CSIS_ISPCONFIG_CH2[60]: 0x000008fe 
mxc-mipi-csi2.1: CSIS_ISPCONFIG_CH3[70]: 0x000008ff 
mxc-mipi-csi2.1: CSIS_ISPRESOL_CH0[44]: 0x0c001000 
mxc-mipi-csi2.1: CSIS_ISPRESOL_CH1[54]: 0x80008000 
mxc-mipi-csi2.1: CSIS_ISPRESOL_CH2[64]: 0x80008000 
mxc-mipi-csi2.1: CSIS_ISPRESOL_CH3[74]: 0x80008000 
mxc-mipi-csi2.1: CSIS_ISPSYNC_CH0[48]: 0x00000000 
mxc-mipi-csi2.1: CSIS_ISPSYNC_CH1[58]: 0x00000000 
mxc-mipi-csi2.1: CSIS_ISPSYNC_CH2[68]: 0x00000000 
mxc-mipi-csi2.1: CSIS_ISPSYNC_CH3[78]: 0x00000000 
mxc-mipi-csi2.1: --- mipi_csis_s_stream --- 
mxc-mipi-csi2.1: GPR_GASKET_0_CTRL[60]: 0xffff8000 
mxc-mipi-csi2.1: GPR_GASKET_0_HSIZE[64]: 0xffff8000 
mxc-mipi-csi2.1: GPR_GASKET_0_VSIZE[68]: 0xffff8000​

And for the failing stream:

mxc-mipi-csi2.1: --- mipi_csis_s_stream ---
mxc-mipi-csi2.1: CSIS_VERSION[0]: 0x03060301
mxc-mipi-csi2.1: CSIS_CMN_CTRL[4]: 0x00004905
mxc-mipi-csi2.1: CSIS_CLK_CTRL[8]: 0x000f0000
mxc-mipi-csi2.1: CSIS_INTMSK[10]: 0x0fffff1f
mxc-mipi-csi2.1: CSIS_INTSRC[14]: 0x00000000
mxc-mipi-csi2.1: CSIS_DPHYSTATUS[20]: 0x000000f2
mxc-mipi-csi2.1: CSIS_DPHYCTRL[24]: 0x1c800007
mxc-mipi-csi2.1: CSIS_DPHYBCTRL_L[30]: 0x000001f4
mxc-mipi-csi2.1: CSIS_DPHYBCTRL_H[34]: 0x00000000
mxc-mipi-csi2.1: CSIS_DPHYSCTRL_L[38]: 0x00000000
mxc-mipi-csi2.1: CSIS_DPHYSCTRL_H[3c]: 0x00000000
mxc-mipi-csi2.1: CSIS_ISPCONFIG_CH0[40]: 0x000000ac
mxc-mipi-csi2.1: CSIS_ISPCONFIG_CH1[50]: 0x000008fd
mxc-mipi-csi2.1: CSIS_ISPCONFIG_CH2[60]: 0x000008fe
mxc-mipi-csi2.1: CSIS_ISPCONFIG_CH3[70]: 0x000008ff
mxc-mipi-csi2.1: CSIS_ISPRESOL_CH0[44]: 0x0c001000
mxc-mipi-csi2.1: CSIS_ISPRESOL_CH1[54]: 0x80008000
mxc-mipi-csi2.1: CSIS_ISPRESOL_CH2[64]: 0x80008000
mxc-mipi-csi2.1: CSIS_ISPRESOL_CH3[74]: 0x80008000
mxc-mipi-csi2.1: CSIS_ISPSYNC_CH0[48]: 0x00000000
mxc-mipi-csi2.1: CSIS_ISPSYNC_CH1[58]: 0x00000000
mxc-mipi-csi2.1: CSIS_ISPSYNC_CH2[68]: 0x00000000
mxc-mipi-csi2.1: CSIS_ISPSYNC_CH3[78]: 0x00000000
mxc-mipi-csi2.1: --- mipi_csis_s_stream ---
mxc-mipi-csi2.1: GPR_GASKET_0_CTRL[60]: 0xffff8000
mxc-mipi-csi2.1: GPR_GASKET_0_HSIZE[64]: 0xffff8000
mxc-mipi-csi2.1: GPR_GASKET_0_VSIZE[68]: 0xffff8000

When pinging the registers, I can also see that in both cases, the STOPSTATEDAT bit of the two used data lanes in the CSIS_DPHYSTATUS register alters between 0 and 1, so I conclude that MIPI data is received on them.

I do not understand yet, why the CSI is not leaving the ULPS state at the second stream and why this only occurs on one of the two MIPI port.

Things I already tried include:

• Testing with different hardware (cameras and SoMs)
• Varying the HS_SETTLE and CLK_SETTLE parameters of the CSI ports

The hardware is a VAR-SOM-MX8MP Symphony Evaluation board and I'm running Linux Kernel 5.15.60 compiled in Yocto. Find attached the relevant parts of the device tree sources.

Best regards,

Mathis

[mfoerst]

Thanks a lot for the reply. The IMX258 was configured in continuous clock mode.

I switched to non-continuous clock mode and it solved the problem.

Is there a reason why a continuous clock is a problem for the second CSI interface only?

[jimmychan · Accepted solution]

Hello,

Reply from the expert

=================

In non-continuous clock mode, the clock lane will have a LP to HS transition for every frame.

But in continuous clock mode, there may only be one LP state at the very beginning, and clock lane will always work in HS mode later.

But it's better to make sensor work in LP state before enable 8MP DPHY, otherwise, DPHY may not detect the HS mode, then it can't receive data from sensor.

=================

Best regards,

Jimmy

[jimmychan]

Is the IMX258 working in non-continuous clock mode?