Jetson Thor MAX96712 D-PHY 1.6Gbps/lane Streaming Failure with NVCSI Deskew Calibration Errors

Robotics & Edge Computing Jetson Systems Jetson Thor
1

Hi NVIDIA team,

We are debugging a multi-camera YUV input pipeline on Jetson Thor using a MAX96712 deserializer. The current setup uses 4-lane D-PHY. /dev/video0 maps to max96712_0_vc0, CSI port PORT A, PHY PHY 0.

When max96712_0_vc0/mode0 in the device tree is configured as follows:

phy_mode = "DPHY";
num_lanes = "4";
pix_clk_hz = "74250000";
mclk_khz = "24000";
serdes_pix_clk_hz = "400000000";
discontinuous_clk = "no";
cil_settletime = "0";
dpcm_enable = "false";
dynamic_pixel_bit_depth = "16";
csi_pixel_bit_depth = "16";
mode_type = "yuv";
pixel_phase = "yuyv";
active_w = "1920";
active_h = "1080";
line_length = "2200";
embedded_metadata_height = "0";

streaming fails. VI reports a timeout, and the trace continuously reports NVCSI PHY_INTR0 errors.

Reproduction Steps

Start streaming:

v4l2-ctl -d /dev/video0 \
  --set-fmt-video=width=1920,height=1080,pixelformat=YUYV \
  --stream-mmap \
  --stream-to=/dev/null

dmesg Error

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

Key Trace Logs

     kworker/6:0-47      [006] .....  5882.217212: rtcpu_string: tstamp:5902626913125 id:0x04010000 str:"===== NVCSI Stream Configuration =====
"
     kworker/6:0-47      [006] .....  5882.217214: rtcpu_string: tstamp:5902626927032 id:0x04010000 str:"stream_id: PP 0, csi_port: PORT A
"
     kworker/6:0-47      [006] .....  5882.217215: rtcpu_string: tstamp:5902626940013 id:0x04010000 str:"Brick: PHY 0, Mode: D-PHY
"
     kworker/6:0-47      [006] .....  5882.217217: rtcpu_string: tstamp:5902626955004 id:0x04010000 str:"Partition: CIL A, LP bypass: Enabled, Lanes: 4
"
     kworker/6:0-47      [006] .....  5882.217219: rtcpu_string: tstamp:5902626964921 id:0x04010000 str:"Clock information:
"
     kworker/6:0-47      [006] .....  5882.217220: rtcpu_string: tstamp:5902626976421 id:0x04010000 str:"CIL rate: 270000000 Hz
"
     kworker/6:0-47      [006] .....  5882.217222: rtcpu_string: tstamp:5902626989023 id:0x04010000 str:"MIPI clock rate: 800000 kHz
"
     kworker/6:0-47      [006] .....  5882.217223: rtcpu_string: tstamp:5902627000986 id:0x04010000 str:"Physical rate: 1600000 Kbps


......
     kworker/6:0-47      [006] .....  5882.273196: rtcpu_vinotify_event: tstamp:5902635475273 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:5902626007894 data:0x0000000031000002
     kworker/6:0-47      [006] .....  5882.273199: rtcpu_nvcsi_intr: tstamp:5902666793810 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x0e000000
     kworker/6:0-47      [006] .....  5882.273200: rtcpu_nvcsi_intr: tstamp:5902666793810 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x06000000
     kworker/6:0-47      [006] .....  5882.273200: rtcpu_nvcsi_intr: tstamp:5902666824634 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x0e000000
     kworker/6:0-47      [006] .....  5882.273201: rtcpu_nvcsi_intr: tstamp:5902666824634 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x06000000
     kworker/6:0-47      [006] .....  5882.273201: rtcpu_nvcsi_intr: tstamp:5902672470810 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x0e000000
     kworker/6:0-47      [006] .....  5882.273201: rtcpu_nvcsi_intr: tstamp:5902672470810 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x06000000

trace.log (158.1 KB)

Additional Observations

  1. The MAX96712 deserializer MIPI D-PHY output has already been configured to 1.6 Gbps/lane. However, if we set the Tegra device tree to:
  serdes_pix_clk_hz = "350000000";

the full streaming pipeline works correctly.
2. After noticing the deskew-related errors, we also configured D-PHY Deskew Initial Calibration on the MAX96712 side. However, this did not resolve the issue.

Questions

  1. For a 4-lane D-PHY, YUYV, 1920x1080, csi_pixel_bit_depth = 16 use case, what are the recommended settings for serdes_pix_clk_hz, pix_clk_hz, csi_pixel_bit_depth, and dynamic_pixel_bit_depth?
  2. If the MAX96712 is actually configured to output 1.6 Gbps/lane, but Tegra can stream successfully with serdes_pix_clk_hz = 350000000 and fails with serdes_pix_clk_hz = 400000000, does this indicate that Tegra NVCSI enters a different deskew configuration path once the calculated lane rate exceeds 1.5 Gbps/lane?
  3. For MAX96712 D-PHY Deskew Initial Calibration, does Jetson Thor / Tegra264 require a specific companion sequence, deskew pattern, timing requirement, or device tree property on the Tegra side? Is enabling deskew calibration only on the MAX96712 side insufficient to satisfy Tegra NVCSI deskew requirements?
3

Make sure the MAX9672 output deskew word.

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)
4

I have confirmed that Deskew Initial for the MAX9672 has been enabled. The value I configured for register 0x903 is 0x81.

image
image965×597 73.5 KB

5

Modify the serdes_pix_clk_hz to 374900000 to check if still the same deskew error.

Thanks

6

After changing serdes_pix_clk_hz to 374900000, streaming works successfully, and there are no errors after the change.

     kworker/1:2-151     [001] .....   212.414192: rtcpu_string: tstamp:232818053130 id:0x04010000 str:"===== NVCSI Stream Configuration =====
"
     kworker/1:2-151     [001] .....   212.414195: rtcpu_string: tstamp:232818066686 id:0x04010000 str:"stream_id: PP 0, csi_port: PORT A
"
     kworker/1:2-151     [001] .....   212.414197: rtcpu_string: tstamp:232818080001 id:0x04010000 str:"Brick: PHY 0, Mode: D-PHY
"
     kworker/1:2-151     [001] .....   212.414200: rtcpu_string: tstamp:232818095056 id:0x04010000 str:"Partition: CIL A, LP bypass: Enabled, Lanes: 4
"
     kworker/1:2-151     [001] .....   212.414203: rtcpu_string: tstamp:232818104954 id:0x04010000 str:"Clock information:
"
     kworker/1:2-151     [001] .....   212.414205: rtcpu_string: tstamp:232818116445 id:0x04010000 str:"CIL rate: 270000000 Hz
"
     kworker/1:2-151     [001] .....   212.414208: rtcpu_string: tstamp:232818129019 id:0x04010000 str:"MIPI clock rate: 749800 kHz
"
     kworker/1:2-151     [001] .....   212.414210: rtcpu_string: tstamp:232818140991 id:0x04010000 str:"Physical rate: 1499600 Kbps
"
     kworker/1:2-151     [001] .....   212.414212: rtcpu_string: tstamp:232818150306 id:0x04010000 str:"T_HS settle: "
     kworker/1:2-151     [001] .....   212.414213: rtcpu_string: tstamp:232818159584 id:0x04010000 str:"autoconfigured"
     kworker/1:2-151     [001] .....   212.414214: rtcpu_string: tstamp:232818169010 id:0x04010000 str:", T_CLK settle: "
     kworker/1:2-151     [001] .....   212.414214: rtcpu_string: tstamp:232818178436 id:0x04010000 str:"autoconfigured"
     kworker/1:2-151     [001] .....   212.414215: rtcpu_string: tstamp:232818190251 id:0x04010000 str:"
======================================

However, I noticed that there are some CORRECTABLE_ERR errors in the trace, which I hadn’t seen before.

     kworker/1:2-151     [001] .....   212.414283: rtcpu_vinotify_event: tstamp:232828068575 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:232817765214 data:0x0000000031000002
     kworker/1:2-151     [001] .....   212.414284: rtcpu_nvcsi_intr: tstamp:232840330927 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x0e000000
     kworker/1:2-151     [001] .....   212.414284: rtcpu_nvcsi_intr: tstamp:232840330927 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x06000000
     kworker/1:2-151     [001] .....   212.414284: rtcpu_nvcsi_intr: tstamp:232840330927 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000e00
     kworker/1:2-151     [001] .....   212.414285: rtcpu_nvcsi_intr: tstamp:232840330927 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:1 st:0 vc:0 status:0x00000600
     kworker/1:2-151     [001] .....   212.414285: rtcpu_nvcsi_intr: tstamp:232840378714 class:GLOBAL type:PHY_INTR0 phy:0 cil:0 st:0 vc:0 status:0x0e000000
     kworker/1:2-151     [001] .....   212.414285: rtcpu_nvcsi_intr: tstamp:232840378714 class:GLOBAL type:PHY_INTR0 phy:0 cil:1 st:0 vc:0 status:0x06000000
     kworker/1:2-151     [001] .....   212.414286: rtcpu_nvcsi_intr: tstamp:232840378714 class:CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000e00

trace_374900000.log (418.4 KB)

8

The log still show the deskew calibration error.

Could you try 300000000 or less.

Thanks

9

I tried setting it to 350000000, and there were no errors.
tract_350000000.log (234.1 KB)

However, if I need a higher data rate, how should I resolve this deskew calibration error?

Is it acceptable for the SerDes transmitter rate and the SoC receiver rate to be inconsistent? For example, the transmitter side is set to 2.0 Gbps/lane, while the SoC is still configured with serdes_pix_clk_hz = 350000000 (1.4 Gbps).

10

Yes, you can try if failed you need to modify the cil_settle time manually instead of auto(0).

11

Additional information:

  1. The previous CORRECTABLE_ERR type:PHY_INTR phy:0 cil:0 st:0 vc:0 status:0x00000e00 seen when 374900000 was configured was because both Deskew Initial Calibration and Periodic Deskew Calibration were enabled on the MAX96712 at the same time. The log below shows that after I disabled Periodic Deskew Calibration, the error no longer appeared.
    trace_374900000(2).log (265.7 KB)
  2. Following your suggestion, when configuring 400000000, I manually set cil_settletime according to the formula:
85 ns + 6 × UI < cil_settletime × lp_clock_period < 145 ns + 10 × UI

The lane rate is:

lane_rate = 1.6 Gbps/lane
UI = 1 / lane_rate
   = 1 / 1.6 GHz
   = 0.625 ns

So the valid range of cil_settletime is 37–61. I chose 48. However, streaming still failed, and I did not see any useful error information in the trace log.
trace_400000000.log (29.0 KB)