AM625: csi2rx 30101000 Failed to configure external DPHY: -95

Hello,

The link frequency is different from the CSI data lane speed. For your camera output of 1920x1280 30fps UYVY data, it won't use 1.5Gbps/lane. You'll need to check the sensor data sheet or driver and see what should be the link frequency. For example, the IMX219 is configured to have 456MHz link frequency:

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/arch/arm64/boot/dts/ti/k3-am62x-sk-csi2-imx219.dtso?h=ti-linux-6.1.y#n49

This frequency supports 2MP@30fps raw 10-bit data, or 8MP@15fps raw 10-bit.

Regards,

Jianzhong

Hello Jianzhong Xu,

We are using a GMSL2 interface with a predefined output frequency of 1500 Mbps.

Based on the formula:

Kaya Kaan Tuna said:

Given that our pixel rate is 187,500,000, a 16-bit sample depth, and 2 lanes, the expected link frequency should be 750,000,000 (750 MHz).

If the pixel rate is 187.5MPixel/s, it means the frame rate must be 60fps. Based on this pixel rate, the link frequency is 750MHz, which means the data rate is 1.5Gbps/lane.

Kaya Kaan Tuna said:

However, when setting the link frequency to this value, we are unable to get any output frame from the camera.

Per MIPI spec, a deskew sequence is needed when data rate is above 1.5Gbps. Did you configure the GMSL2 to send the deskew sequence?

Kaya Kaan Tuna said:

Interestingly, when reducing the CSI PHY on the deserializer to 1200 Mbps and setting the link frequency to 600,000,000 (600 MHz), we do get an output, but the images are glitchy.

Two lanes with 1.2Gbps/lane is not enough to transmit 187.5MPixel/s with 16-bit per pixel. This is probably the reason why the images are glitchy. 

Hi @Jianzhong Xu,

Jianzhong Xu said:

If the pixel rate is 187.5MPixel/s, it means the frame rate must be 60fps. Based on this pixel rate, the link frequency is 750MHz, which means the data rate is 1.5Gbps/lane.

Since my GMSL is configured for 1.5 Gbps per lane, this should be the correct setting, right? If so, then I would suspect a hardware issue on my side.

Jianzhong Xu said:

Per MIPI spec, a deskew sequence is needed when data rate is above 1.5Gbps. Did you configure the GMSL2 to send the deskew sequence?

Since I am operating at exactly 1.5 Gbps per lane, I assume that the deskew sequence is not required. Am I correct?

I’ll probe my MIPI signals and get back to you. In the meantime, are there any memory dump registers I can check for MIPI debugging? If you could share some useful ones, I would greatly appreciate it.

Thanks.

You're correct on those two questions.

Kaya Kaan Tuna said:

are there any memory dump registers I can check for MIPI debugging? I

Please check the following threads:

• https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1272946/sk-am62a-lp-csi-2-rx-register-values-and-debug-info-for-an-image-sensor

• https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1420096/am62a7-unable-to-capture-frame

Hi Jianzhong,

I checked the hardware and found some instability when operating the GMSL at 1.5 Gbps per lane. To address this, I reduced the GMSL speed to 800 Mbps per lane and adjusted the pixel clock and link frequencies accordingly. After this change, I was able to capture a frame successfully.

However, when I try to capture 100 frames using the following command:

```
v4l2-ctl --device /dev/video-isx021-cam0 --set-fmt-video=width=1920,height=1280,pixelformat=UYVY --stream-mmap --stream-to=frame.raw --stream-count=100
```
I observe that some frames are captured, but then the board seems to lag and starts dropping frames. The output looks like this:

```
<<<<<<<<<<< 8.82 fps
2453504 != 4915200
< 2.95 fps
4096 != 4915200
<4096 != 4915200
< 3.20 fps
4096 != 4915200
<4096 != 4915200
< 2.79 fps
4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
<4096 != 4915200
...
...

Interestingly, this issue does not occur when I stream directly to RAM without saving the output file:

```
v4l2-ctl --device /dev/video-isx021-cam0 --set-fmt-video=width=1920,height=1280,pixelformat=UYVY --stream-mmap
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 30.00 fps
```

It seems that writing the data to file is causing a bottleneck or introducing latency that leads to dropped frames. Do you have any ideas on why this might be happening or any suggestions to resolve it?

Thanks.

Kaya Kaan Tuna said:

I observe that some frames are captured, but then the board seems to lag and starts dropping frames. The output looks like this:

I think that's expected when you write images to a file on the SD card. You're limited by how fast you can write to the SD card.