Orin camera can not capture

Continuing the discussion from Orin camera can not preview:
Gmsl sensor work can output mipi data normally, but VI channel request timed out. according to the forum, change serdes_pix_clk_hz/pix_clk_hz in device tree. but the problem still exists. Please help analyze the problem?
trace_log.txt (90.9 KB)

what’s the output size. Could you try 1080p or 720p

output size 1920x1024

Sorry for the late response, our team will do the investigation and provide suggestions soon. Thanks

Didn’t receive any validate data from the sensor.
May need to confirm the device tree configure.

This is device tree configuration,Please help check it out
tegra234-camera-imx390.dtsi (48.2 KB)

Suppose virtual channel max support to 4, your device tree set the vcid to 7
Did you verify this sensor board on any others platform for your driver and device tree?

Verify that virtual channel to 16 is working properly on Xavier

But the VCID is 2 bit data of MIPI CSI2. How can it support 8 virtual channel?

tegra234-0000-camera-imx390-a00.dtsi (9.1 KB)
Support two deserializers, a deserializer uses 4 virtual channels.

But your device tree shows both of them connect to the same CSI/VI port(port-index=0)

tegra234-camera-imx390-fix.dtsi (45.5 KB)
This is the modified device tree,but VI channel request timed out。

tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms

trace.log (9.2 KB)

Modify the pix_clk_hz and serders_pix_clk_hz to 370000000 to try and get the trace log.

trace_log.txt (663.3 KB)

The Dphy output rate of the deserializer is 2.5Gbps/lane, lane number is 4

Try the output data rat > 1.5Gpbs

Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
An initiation deskew signal should be sent by sensor or deserializer to perform the skew calibration. If the deskew signals is not sent, the receiver will stall, and the capture will time out.
You can calculate the output data rate with the following equation:

Output data rate = (sensor or deserializer pixel clock in hertz) * (bits per pixel) / (number of CSI lanes)

Also boost the clocks to try.

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

serdes_pix_clk_hz = (2500x1000x1000x4)/16 = 625000000, Actual settings serdes_pix_clk_hz = 620000000,but VI channel request timed out

For sensor modules that use serializer/deserializer chips (GMSL or FPD link), the frames received by the SoC are output from SerDes and not from the sensors. Therefore, the SerDes pixel clock must be specified correctly to configure the SoC-camera interface correctly and avoid buffer overrun issues.

You can start by checking the deserializer output data rate and ensure it is sufficient to stream all the connected sensors. After you determine the proper data rate, the SerDes pixel clock can be calculated by using the following equation:

serdes_pix_clk_hz = (deserializer output data rate in hertz) * (number of CSI lanes) / (bits per pixel).

Sorry for the late response, have you managed to get issue resolved or still need the support?
Please try with JetPack 5.0.2 GA release.
Thanks