Jetson Thor T5000: 1280x800@30fps YUV422-8bit camera fails to stream, while 1920x1080 and 3840x2162 modes work

Hi NVIDIA team,

I am bringing up a 1280x800@30fps YUV422-8bit camera on Jetson Thor T5000 with Jetson Linux r38.4, but this specific mode cannot stream successfully.

System Configuration

  • Platform: Jetson Thor T5000

  • Jetson Linux: r38.4

  • CSI-2: 4 data lanes

  • Deserializer: MAX96712

  • Serializer: MAX96701

  • Data format: YUV422 8-bit / YUYV

  • Target mode: 1280x800@30fps

  • CSI interface: serial_a

  • Port index: 0

  • Brick: Brick 0 / PORT_A

  • VC mapping: VC0-VC3 → video0-video3

Background
The current driver supports three modes:

mode0: 1920x1080 YUYV
mode1: 1280x800 YUYV
mode2: 3840x2162 YUYV

I have verified that mode0 and mode2 can stream correctly. Only mode1, which is 1280x800 YUYV, fails to output frames.

The following command times out and no frame is captured:

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

Device Tree Configuration
The related device-tree mode settings are:

mode0 {
tegra_sinterface = "serial_a";
phy_mode = "DPHY";
num_lanes = "4";
pix_clk_hz = "71280000";
mclk_khz = "0";
serdes_pix_clk_hz = "350000000";
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";
vc_id = "0";
};

mode1 {
tegra_sinterface = "serial_a";
phy_mode = "DPHY";
num_lanes = "4";
pix_clk_hz = "74250000";
mclk_khz = "0";
serdes_pix_clk_hz = "350000000";
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 = "1280";
active_h = "800";
line_length = "1280";
embedded_metadata_height = "0";
vc_id = "0";
};

mode2 {
tegra_sinterface = "serial_a";
phy_mode = "DPHY";
num_lanes = "4";
pix_clk_hz = "285384000";
mclk_khz = "0";
serdes_pix_clk_hz = "350000000";
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 = "3840";
active_h = "2162";
line_length = "3840";
embedded_metadata_height = "0";
vc_id = "0";
};

dmesg:

[ 3663.404118] [RCE] CSI port AB
[ 3663.404121] [RCE] AFE_HFGAIN_IO0_A=7
[ 3663.404123] [RCE] AFE_HFGAIN_IO1_A=7
[ 3663.404127] [RCE] AFE_HFGAIN_CLK_A=7
[ 3663.404130] [RCE] AFE_HFGAIN_IO0_B=7
[ 3663.404133] [RCE] AFE_HFGAIN_IO1_B=7
[ 3663.404135] [RCE] AFE_HFGAIN_CLK_B=7
[ 3666.119971] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 3668.679949] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 3671.208097] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms

trace:

trace.log (39.2 KB)

kworker/6:1-129 [006] … 716.486663: rtcpu_unknown: tstamp:736853704514 id:0x000a000b len:4 data:00 00 00 00
kworker/6:1-129 [006] … 716.486663: rtcpu_unknown: tstamp:736853719755 id:0x000f0001 len:8 data:00 00 00 00 00 00 00 00
kworker/6:1-129 [006] … 716.486663: rtcpu_vinotify_event: tstamp:736861815764 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:736851612655 data:0x0000000031000002
kworker/6:1-129 [006] … 716.486664: rtcpu_vinotify_event: tstamp:736889536347 cch:0 vi:0 tag:FS channel:0x00 frame:0 vi_tstamp:736889486421 data:0x0000000000000010
kworker/6:1-129 [006] … 716.542540: rtcpu_vinotify_event: tstamp:736898931375 cch:0 vi:0 tag:ATOMP_FS channel:0x00 frame:0 vi_tstamp:736889486437 data:0x0000000800000000

Question
Since mode0 and mode2 work with the same driver and CSI link, but mode1 fails, I suspect the issue may be related to the mode1 timing or device-tree parameters.

Could you please advise how to debug this issue on Jetson Thor?

I would suspect the sensor REG config cause the problem.

It could be below condition.

  1. missing / malformed FE
  2. unstable frame timing
  3. truncated frame / dropped tail of frame
  4. upstream deserializer / transport disturbance

Thank you for your reply! I will further check the deserializer configuration following your suggestions.

One additional note: the same configuration has been used before, and it can be received correctly on other SoCs.
I would like to confirm whether parameters such as pix_clk_hz, line_length, serdes_pix_clk_hz, and csi_pixel_bit_depth are correct, and whether they are unlikely to be the cause of this issue.

Suppose it could be fine for the clk config due to the trace log shows receiving the FS.