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

mfoerst — Thu, 08 Dec 2022 11:55:27 GMT

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

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

jimmychan — Fri, 23 Dec 2022 01:43:55 GMT

Is the IMX258 working in non-continuous clock mode?

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

mfoerst — Fri, 23 Dec 2022 09:10:31 GMT

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?

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

jimmychan — Tue, 27 Dec 2022 01:44:05 GMT

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

i.MX Processorsのトピックi.MX8M Plus dual MIPI camera: CSI-2.1 not leaving ULPS state

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

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

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

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