Orin NX MIPI Driver Without I2C

Hello Team,

A MIPI CSI camera driver development has been carried out on a Jetson Orin NX platform running JetPack 6.2.1. The camera is a block-type device that continuously streams image data and does not use any I²C-based control interface.

In the initial phase, the device tree configuration was derived from the existing imx219-A reference design. On the driver side, a custom driver was created by modifying the ov5693.c driver and removing all I²C-related functionality.

As a result of these changes, the driver successfully probes and binds to the device tree. However, no image frames are received at the video capture stage. According to the camera specifications, the incoming stream is 1920×1080 resolution at 50 FPS.

Relevant kernel and NVCSI/VI logs have been attached for further analysis.

trace_log.txt (5.1 MB)

tegra234-p3767-camera-p3768-dummy.dts.txt (4.7 KB)

dummy-driver.c.txt (18.5 KB)

hello drklck,

did you have sensor node register to linux kernel?
you may see-also developer guide, To verify the port binding result
please also check.. $ v4l2-ctl -d /dev/video0 --list-formats-ext

Hello JerryChang,

We have checked with ls /proc/device-tree/bus@0/cam_i2cmux/i2c@1/h4240_mipi@3c directory and it seems like there is the sensor node.

The result that we get after ls -list /proc/device-tree/bus@0/cam_i2cmux/i2c@1/h4240_mipi@3c command :

sudo media-ctl -p -d /dev/media0

$ v4l2-ctl -d /dev/video0 --list-formats-ext

hello drklck,

let’s test with v4l2 standard IOCTL for fetching camera frames.
for instance,
$ v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=UYVY --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100

Hello JerryChang,

Thanks for the answer. The given v4l2 command just waits and we still cannot capture frames. The dmesg and trace logs did not change. I am still getting the same error messages shown below.

trace_log.txt

Screenshot from 2026-01-21 15-38-33

Screenshot from 2026-01-21 15-38-33972×300 62.5 KB

hello drklck,

it’s fetch timeout, which means there’s no validate frames on the CSI channel.
did you have hardware resources to examine the MIPI signaling? please check the high-speed signaling if that’s possible.

Hello again JerryChang,

Let me check the MIPI signaling to ensure if it is a hardware connection problem.

Could you please examine this logs. What should I understand from this trace log output? Are these logs also means that there is HW problem?

kworker/2:2-163 [002] … 3840.623517: rtcpu_nvcsi_intr: tstamp:120822574872 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x00000044
kworker/2:2-163 [002] … 3840.623517: rtcpu_nvcsi_intr: tstamp:120822574872 class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x00000044

kworker/2:2-163 [002] … 3840.623526: rtcpu_nvcsi_intr: tstamp:120822580536 class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:0 st:0 vc:0 status:0x00000040
kworker/2:2-163 [002] … 3840.623527: rtcpu_nvcsi_intr: tstamp:120822580536 class:CORRECTABLE_ERR type:PHY_INTR phy:1 cil:1 st:0 vc:0 status:0x00000044

Hello,

We checked the MIPI signaling and no problems were observed related to the camera and the connection.

Hello again,

After making some changes, specifically increasing the pixel-clock-hz parameter, the logs got changed. This is what we get right now from trace logs.

vi-output, fpga-3133 [001] … 58.062714: tegra_channel_capture_setup: vnc_id 0 W 2048 H 1536 fmt 13
vi-output, fpga-3132 [000] … 58.062829: vi_task_submit: class_id:48 ch:0 syncpt_id:31 syncpt_thresh:214 pid:3132 tid:3132
vi-output, fpga-3132 [000] … 58.062840: vi_task_submit: class_id:48 ch:0 syncpt_id:31 syncpt_thresh:214 pid:3132 tid:3132
vi-output, fpga-3132 [000] … 58.062841: vi_task_submit: class_id:48 ch:0 syncpt_id:31 syncpt_thresh:214 pid:3132 tid:3132
vi-output, fpga-3132 [000] … 58.062842: vi_task_submit: class_id:48 ch:0 syncpt_id:31 syncpt_thresh:214 pid:3132 tid:3132
kworker/0:3-162 [000] … 58.113669: rtcpu_vinotify_event: tstamp:2616123435 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:83700259616 data:0x799e300010000000
kworker/0:3-162 [000] … 58.113672: rtcpu_vinotify_event: tstamp:2616123594 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:83700301632 data:0x0000000031000001
kworker/0:3-162 [000] … 58.113673: rtcpu_vinotify_event: tstamp:2616123732 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:83700319808 data:0x799e2d0010000000
kworker/0:3-162 [000] … 58.113674: rtcpu_vinotify_event: tstamp:2616123887 cch:0 vi:1 tag:VIFALC_ACTIONLST channel:0x23 frame:0 vi_tstamp:83700340128 data:0x0000000007020001
kworker/0:3-162 [000] … 58.113675: rtcpu_vinotify_event: tstamp:2616124023 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:83700382496 data:0x0000000031000002
kworker/0:3-162 [000] … 58.113676: rtcpu_nvcsi_intr: tstamp:2616944604 class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x04000000
kworker/0:3-162 [000] … 58.169864: rtcpu_nvcsi_intr: tstamp:2617569557 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.169867: rtcpu_nvcsi_intr: tstamp:2618194511 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.169868: rtcpu_nvcsi_intr: tstamp:2618819813 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.226086: rtcpu_nvcsi_intr: tstamp:2619444416 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.286314: rtcpu_nvcsi_intr: tstamp:2621944578 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.286317: rtcpu_nvcsi_intr: tstamp:2622569530 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.342550: rtcpu_nvcsi_intr: tstamp:2623819438 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.398754: rtcpu_nvcsi_intr: tstamp:2624444045 class:GLOBAL type:PHY_INTR0 phy:1 cil:1 st:0 vc:0 status:0x04000000
kworker/0:3-162 [000] … 58.398757: rtcpu_nvcsi_intr: tstamp:2625069000 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.398757: rtcpu_nvcsi_intr: tstamp:2625069359 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.398758: rtcpu_nvcsi_intr: tstamp:2625693953 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.454987: rtcpu_nvcsi_intr: tstamp:2626318904 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.454989: rtcpu_nvcsi_intr: tstamp:2627568813 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.511194: rtcpu_nvcsi_intr: tstamp:2628819066 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.511195: rtcpu_nvcsi_intr: tstamp:2629444018 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000
kworker/0:3-162 [000] … 58.567445: rtcpu_nvcsi_intr: tstamp:2630693581 class:GLOBAL type:PHY_INTR0 phy:1 cil:0 st:0 vc:0 status:0x10000000

Could you please examine this logs?

hello drklck,

this error indicates that the D-PHY data-lanes are not properly aligned. this is a synchronization issue.
this typically occurs when the sensor is sending data on multiple D-PHY lanes but they’re not time-aligned, or, there’s signal integrity issues causing skew between lanes, or, the D-PHY deskew calibration failed or wasn’t performed.

you may check deskew calibration if you’re running with data-rate above 1.5Gbps,
please also review sensor initialization sequence.