IMX219 DS90UB95x SerDes Setup on Orin NX

Having issues getting a camera stream up using an IMX219 sensor.

Hardware:

  • Custom Carrier Board with Jetson Orin NX 16Gb
  • from cat /etc/nv_tegra_release# R35 (release), REVISION: 3.1, GCID: 32827747, BOARD: t186ref, EABI: aarch64, DATE: Sun Mar 19 15:19:21 UTC 2023
  • from uname -r 5.10.104-tegra
  • Using only 2 lanes from IMX219PQH5-C. The 2 lanes on the Jetson side are CSI2_D0 and CSI2_D1, which correct me if I am wrong, use Port 2, Stream 2 (serial_c for tegra_sinterface).
  • Deserializer: ds90ub954
  • Serializer: ds90ub953
  • Using only RIN Port 1 on the Deserializer. Only one camera and one serializer for now.

For the sake of verification, I am using a pattern generation from the deserializer. My workflow is:

  • Setup des and ser over i2c. With the back channel configured, the kernel can see the camera sensor at i2c address 0x10.
  • The des pattern generation is then configured. It is setup to mimic the output from the imx219 using RAW10, 3280 x 2464, and at 21fps.
  • Then I restart the nv_imx219 kernel module. After this is done, here are the results:

In dmesg:

[ 1910.743131] imx219 1-0010: tegracam sensor driver:imx219_v2.0.6
[ 1910.762444] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx219 1-0010 bound

V4l2 Compliance Test using v4l2-compliance -d /dev/video0:

v4l2-compliance SHA: not available, 64 bits

Compliance test for tegra-video device /dev/video0:

Driver Info:
	Driver name      : tegra-video
	Card type        : vi-output, imx219 1-0010
	Bus info         : platform:tegra-capture-vi:2
	Driver version   : 5.10.104
	Capabilities     : 0x84200001
		Video Capture
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x04200001
		Video Capture
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : tegra-camrtc-ca
	Model            : NVIDIA Tegra Video Input Device
	Serial           : 
	Bus info         : 
	Media version    : 5.10.104
	Hardware revision: 0x00000003 (3)
	Driver version   : 5.10.104
Interface Info:
	ID               : 0x03000024
	Type             : V4L Video
Entity Info:
	ID               : 0x00000022 (34)
	Name             : vi-output, imx219 1-0010
	Function         : V4L2 I/O
	Pad 0x01000023   : 0: Sink
	  Link 0x02000028: from remote pad 0x1000003 of entity '13e40000.host1x:nvcsi@15a00000-': Data, Enabled

Required ioctls:
	test MC information (see 'Media Driver Info' above): OK
	test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
	test second /dev/video0 open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
	test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls (Input 0):
	test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
	test VIDIOC_QUERYCTRL: OK
	test VIDIOC_G/S_CTRL: OK
	test VIDIOC_G/S/TRY_EXT_CTRLS: OK
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 1 Private Controls: 20

Format ioctls (Input 0):
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
		fail: v4l2-test-formats.cpp(1280): ret && node->has_frmintervals
	test VIDIOC_G/S_PARM: FAIL
	test VIDIOC_G_FBUF: OK (Not Supported)
	test VIDIOC_G_FMT: OK
	test VIDIOC_TRY_FMT: OK
	test VIDIOC_S_FMT: OK
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
	test Cropping: OK (Not Supported)
	test Composing: OK (Not Supported)
	test Scaling: OK (Not Supported)

Codec ioctls (Input 0):
	test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls (Input 0):
		fail: v4l2-test-buffers.cpp(715): q.create_bufs(node, 1, &fmt) != EINVAL
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
	test VIDIOC_EXPBUF: OK
	test Requests: OK (Not Supported)

Total for tegra-video device /dev/video0: 45, Succeeded: 43, Failed: 2, Warnings: 0

From media-ctl -p:

Media controller API version 5.10.104

Media device information
------------------------
driver          tegra-camrtc-ca
model           NVIDIA Tegra Video Input Device
serial          
bus info        
hw revision     0x3
driver version  5.10.104

Device topology
- entity 1: 13e40000.host1x:nvcsi@15a00000- (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
	pad0: Sink
		<- "imx219 1-0010":0 [ENABLED]
	pad1: Source
		-> "vi-output, imx219 1-0010":0 [ENABLED]

- entity 32: imx219 1-0010 (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev1
	pad0: Source
		[fmt:SRGGB10_1X10/3280x2464 field:none colorspace:srgb]
		-> "13e40000.host1x:nvcsi@15a00000-":0 [ENABLED]

- entity 34: vi-output, imx219 1-0010 (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video0
	pad0: Sink
		<- "13e40000.host1x:nvcsi@15a00000-":1 [ENABLED]

The error after running v4l2-ctl -d /dev/video0 --stream-mmap is:

[  459.251111] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[  459.260268] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[  459.270096] (NULL device *): vi_capture_control_message: NULL VI channel received
[  459.277814] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
[  459.288613] (NULL device *): vi_capture_control_message: NULL VI channel received
[  459.296385] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 2 vc- 0
[  459.307302] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[  462.067041] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[  462.076202] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[  462.087141] (NULL device *): vi_capture_control_message: NULL VI channel received
[  462.095421] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
[  462.106701] (NULL device *): vi_capture_control_message: NULL VI channel received
[  462.114521] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 2 vc- 0
[  462.125671] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[  464.883010] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[  464.892162] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[  464.902085] (NULL device *): vi_capture_control_message: NULL VI channel received
[  464.909819] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
[  464.920498] (NULL device *): vi_capture_control_message: NULL VI channel received
[  464.928226] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 2 vc- 0
[  464.939031] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[  467.698998] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[  467.708143] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[  467.718098] (NULL device *): vi_capture_control_message: NULL VI channel received
[  467.725821] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
[  467.736571] (NULL device *): vi_capture_control_message: NULL VI channel received
[  467.744300] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 2 vc- 0
[  467.755134] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[  470.515019] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[  470.524230] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[  470.534120] (NULL device *): vi_capture_control_message: NULL VI channel received
[  470.541847] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
[  470.552556] (NULL device *): vi_capture_control_message: NULL VI channel received
[  470.560285] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 2 vc- 0
[  470.571076] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[  473.331143] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[  473.340289] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel

Also enabling the debug trace with:

enable_vi_trace:
	@sudo echo 1 > /sys/kernel/debug/tracing/tracing_on
	@sudo echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
	@sudo echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
	@sudo echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
	@sudo echo 2 > /sys/kernel/debug/camrtc/log-level
	@sudo echo > /sys/kernel/debug/tracing/trace

this gives:

# tracer: nop
#
# entries-in-buffer/entries-written: 40/40   #P:8
#
#                                _-----=> irqs-off
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| /     delay
#           TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
#              | |         |   ||||      |         |
     kworker/4:1-55      [004] ....   110.405630: rtcpu_string: tstamp:4155018217 id:0x04010000 str:"VM0 deactivating."
     kworker/4:1-55      [004] ....   111.825603: rtcpu_string: tstamp:4198493373 id:0x04010000 str:"VM0 activating."
     kworker/4:1-55      [004] ....   111.825608: rtcpu_vinotify_event: tstamp:4199184668 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:134357980832 data:0x719e300010000000
     kworker/4:1-55      [004] ....   111.825609: rtcpu_vinotify_event: tstamp:4199184804 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:134357987296 data:0x0000000031000001
     kworker/4:1-55      [004] ....   111.825609: rtcpu_vinotify_event: tstamp:4199184961 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:134358032672 data:0x719e2d0010000000
     kworker/4:1-55      [004] ....   111.825609: rtcpu_vinotify_event: tstamp:4199185094 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:134358039200 data:0x0000000031000002
     kworker/4:1-55      [004] ....   114.525593: rtcpu_vinotify_event: tstamp:4283278770 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:137054334432 data:0x719e300010000000
     kworker/4:1-55      [004] ....   114.525597: rtcpu_vinotify_event: tstamp:4283278907 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:137054381760 data:0x0000000031000001
     kworker/4:1-55      [004] ....   114.525597: rtcpu_vinotify_event: tstamp:4283279064 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:137054399328 data:0x719e2d0010000000
     kworker/4:1-55      [004] ....   114.525598: rtcpu_vinotify_event: tstamp:4283279195 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:137054493216 data:0x0000000031000002
     kworker/4:2-130     [004] ....   117.337581: rtcpu_vinotify_event: tstamp:4371170227 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:139867290976 data:0x719e300010000000
     kworker/4:2-130     [004] ....   117.337583: rtcpu_vinotify_event: tstamp:4371170363 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:139867333664 data:0x0000000031000001
     kworker/4:2-130     [004] ....   117.337584: rtcpu_vinotify_event: tstamp:4371170519 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:139867351168 data:0x719e2d0010000000
     kworker/4:2-130     [004] ....   117.337584: rtcpu_vinotify_event: tstamp:4371170654 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:139867411584 data:0x0000000031000002
     kworker/4:2-130     [004] ....   120.149557: rtcpu_vinotify_event: tstamp:4458857863 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:142683244576 data:0x719e300010000000
     kworker/4:2-130     [004] ....   120.149560: rtcpu_vinotify_event: tstamp:4458858002 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:142683287264 data:0x0000000031000001
     kworker/4:2-130     [004] ....   120.149561: rtcpu_vinotify_event: tstamp:4458858160 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:142683304864 data:0x719e2d0010000000
     kworker/4:2-130     [004] ....   120.149561: rtcpu_vinotify_event: tstamp:4458858295 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:142683365248 data:0x0000000031000002
     kworker/4:1-55      [004] ....   122.965551: rtcpu_vinotify_event: tstamp:4547008089 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:145503211552 data:0x719e300010000000
     kworker/4:1-55      [004] ....   122.965554: rtcpu_vinotify_event: tstamp:4547008229 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:145503257120 data:0x0000000031000001
     kworker/4:1-55      [004] ....   122.965554: rtcpu_vinotify_event: tstamp:4547008387 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:145503274688 data:0x719e2d0010000000
     kworker/4:1-55      [004] ....   122.965554: rtcpu_vinotify_event: tstamp:4547008522 cch:0 vi:1 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:145503335072 data:0x0000000031000002
     kworker/4:1-55      [004] ....   131.789568: rtcpu_string: tstamp:4823041790 id:0x04010000 str:"VM0 deactivating."

There is data on the CSI2_CLK, CSI2_D0, and CSI2_D1 lanes. There is only continuity between the deserializer pins and the Orin’s pins.
I have a feeling this is a device tree misconfiguration. For example, why does the vi trace show vi:1?
Can you verify my device tree? (decompiled the current running dtb, attached).
kernel_tegra234-p3767-0000-p3768-0000-a0.txt (414.3 KB)

Thank you!

1 Like

The device configuration is correct.
Orin NX have two vi logic and it assign to vi:1 for it doesn’t matter with the port number.

1 Like

I would suggest confirm this device configure by connect imx219 directly first.

2 Likes

Thanks @ShaneCCC,

I will try that. In the meantime, I had another question about the nv_imx219 driver. From the kernel source code (35.3.1), it looks like the driver does not support setting VC ID or 4 lane from the device tree (looking at kernel/nvidia/drivers/media/i2c/imx219_mode_tbls.h, in static imx219_reg imx219_mode_common, register 0x0114 is hardcoded to 2 lane, and register 0x0110 is not written to at all which results in a fixed vc-id of 0.)

It also looks like kernel/kernel-5.10/drivers/media/i2c/imx219.c is the out of date version that also only supports 2 lane. Latest version seems to be here https://github.com/torvalds/linux/blob/master/drivers/media/i2c/imx219.c that supports 4 lane configuration.

My first question is if I compile the latest imx219.c/.h into a kernel module, would I be missing any functionality that the nv_imx219 driver provides? Is there any special integration to the nvidia camera stack that the generic imx219 driver doesn’t have?

My second question has to do with data rates. The IMX219 says it can output a max of 912 Mbps per lane when in the 2 lane configuration. The deserializer is set to an output data rate of 1.5 Gbps per lane (options are only 1.6G, 1.5G, 800M, 400M). Is skew calibration required here? I think I saw another forum post that stated that 35.3.1 doesn’t have skew calibration support - do I need to upgrade to 35.4.1? If I were able to lower the data rate to say 1.4 or 1.3 Gbps per lane, would I still need the skew calibration / upgrade to 35.4.1?

Last question is if there is any way to view the data on the MIPI CSI lanes (like via a stream) without using a sensor at all? In my current setup with the deserializer pattern generator, I still need to talk to the IMX sensor to get a device to show on /dev/video0 so I can then use the v4l2 commands.

In case this is at all useful, my pattern generator setup is below. Again it was set to mimic the imx219_mode_3280x2464_21fps

Settings:

    // 7.5.11.3 Packet Generator Programming
    // The information in this section provides details on how to program the Pattern Generator to provide a specific
    // color bar pattern, based on datatype, frame size, and line size.
    // Most basic configuration information is determined directly from the expected video frame parameters. The
    // requirements should include the datatype, frame rate (frames per second), number of active lines per frame,
    // number of total lines per frame (active plus blanking), and number of pixels per line.
    // • PGEN_ACT_LPF – Number of active lines per frame
    // • PGEN_TOT_LPF – Number of total lines per frame
    // • PGEN_LSIZE – Video line length size in bytes. Compute based on pixels per line multiplied by pixel size in
    // bytes
    // • CSI-2 DataType field and VC-ID
    // • Optional: PGEN_VBP – Vertical back porch. This is the number of lines of vertical blanking following Frame
    // Valid
    // • Optional: PGEN_VFP – Vertical front porch. This is the number of lines of vertical blanking preceding Frame
    // Valid
    // • PGEN_LINE_PD – Line period in 10-ns units. Compute based on Frame Rate and total lines per frame
    // • PGEN_BAR_SIZE – Color bar size in bytes. Compute based on datatype and line length in bytes (see details
    // below)

Patterns:

    PGEN_CFG
        Reference Color Bar Pattern
        8 Color bars
        ROM SPEC: RAW10 requires a 5-byte block size which is equal to 4 pixels.
        Block size set to 15 bytes.

    PGEN_CSI_DI
        virtual ID to be 0
        data type to be raw 10
        according to https://www.ti.com/lit/an/snla267a/snla267a.pdf?ts=1697718566294&ref_url=https%253A%252F%252Fwww.google.com%252F
        raw 10 is 0x2B. raw10 is what the camera is outputting.

    PGEN_LINE_SIZE
        set up pattern generator line size (2 bytes)
        3280x2464 at 21fps
        line length for the camera is decimal 3448 and that is what is being set. Units are pixels.
        need to convert to bytes. 
        5 bytes per 4 pixels.
        3448 pixels / 4 pixels * 5 bytes = 4310 bytes
        10D6 in hex

    PGEN_BAR_SIZE
        // When programming the Pattern Generator, software should compute the required bar size in bytes based on
        // the line size and the number of bars. For the standard eight color bar pattern, that would require the following
        // algorithm:
        // • Select the desired datatype, and a valid length for that datatype (in pixels).
        // • Convert pixels/line to blocks/line (by dividing by the number of pixels/block, as defined in the datatype
        // specification).
        // • Divide the blocks/line result by the number of color bars (8), giving blocks/bar
        // • Round result down to the nearest integer
        // • Convert blocks/bar to bytes/bar and program that value into the PGEN_BAR_SIZE register
        // As an alterrnative, the blocks/line can be computed by converting pixels/line to bytes/line and divide by bytes/
        // block.

        // (3448 pixels / line) * (1 block / 4 pixels) = 862 blocks / line
        // (862 blocks / line) * (1 line / 8 bars) = 107.75 blocks / bar. 
        // rounding down -> 107 blocks / bar
        // (107 blocks / bar) * (5 bytes / block) = 535 (0x217)

    PGEN_ACT_LPF & PGEN_TOT_LPF
        // program active lines per frame
        // looks like 2497 (0x9C1) is getting set on the imx for "FRM_LENGTH", reg 0x0160 and 0x0161
        // depends on binning mode, no binning so unit is 1 line. 
        // the image is only 2464 (0x9A0). so number above it likely total
        // program total lines per frame including vertical blanking
        // see above.

    PGEN_LINE_PD
        // line period, calculated in units of 10ns
        // Compute based on Frame Rate and total lines per frame
        // frame rate is 21 fps. lines per frame.. total or active? assume total for now
        // with some fiddling with units, line period in tens of nano seconds is 1907 (0x773)

    PGEN_VBP
        // vertical back porch
        // This value provides the vertical back porch portion of the
        // vertical blanking interval. This value provides the number of
        // blank lines between the FrameStart packet and the first video
        // data packet.
        // left default

    PGEN_VFP
        // This value provides the vertical front porch portion of the
        // vertical blanking interval. This value provides the number of
        // blank lines between the last video line and the FrameEnd
        // packet.
        // left default

Thanks for all the help.

1 Like
  1. Looks like the driver is different with tegracam framework, nv_imx219.c is tegracam sensor driver. I would suggest using nv_imx219.c to modify as your request.

  2. You can use r35.3.1 if data rate low than 1.5Gbps.

  3. No

1 Like

Hi Shane,

We plan on making another hardware board that will directly breakout CSI connection and bypass the deserializer. The design will have:

  • all the CSI lanes connected and the CSI CLK
  • a jumper-ed I2C option so it either come from output of serializer or direct from Orin
  • a jumper-ed m_clock so it can either come from serializer or come from the Orin
  • a jumper-ed power enable for the camera sensor so it either come directly from the Orin or other location (I think our default hardware just has it on all the time.)

Can you think of any other helpful hardware add-ons to assist in debugging, whether it be for the direct CSI connection and also the FPD Link SerDes? Is there plans in the future to add FPD LInk 3 drivers to Jetpack?

Don’t have plan now. However lots of user and camera partner able to bring this kind of design up, so I think this shouldn’t be a very difficult problem.

1 Like

Sounds good. Question about the nv_imx219 driver. Does the driver care about the data rate per CSI lane into the Jetson? Or as long as it below 1.5 Gbps, it should see the stream? Is this handled by the CSI_CLK?

Thanks.

Suppose all current mode are less than 1.5Gbps due to need configure sensor send deskew word when data bigger than 1.5Bbps

Hi Shane,

Is there any documentation on the current nv_imx219 driver and the supported device tree settings?

Particularly, I am looking to change the sensor’s mode. I see the modes defined in imx219_mode_tbls.h but looks setting the mode via the device tree is not supported according to the comment in the imx219_frmfmt struct towards the bottom of that file.

Without digging through all the code, I was wondering if there is any documentation on what is supported via the device tree with nv_imx219 module?

Sorry to tell there’s no any document for this.

Hi ShaneCCC,

I’m trying to test lower bandwidth options on 2-lane, particularly imx219_mode_1280x720_60fps, since I am worried I might be running into bandwidth options on the serializer. Right now, I am testing on a Orin dev kit without Serdes (direct connection between Orin and imx219).

I noticed with nvarguscamerasrc, I can specify sensor_mode=4 and it will correctly select this 60fps mode (4th index in the modes array in the driver). Is there any way to do this with v4l2?

I tried the following but it doesn’t work.
v4l2-ctl -d /dev/video0 --set-ctrl=sensor_mode=4
v4l2-ctl -d /dev/video0 --stream-mmap > still reports 21fps corresponding to the imx219_mode_3280x2464_21fps mode.

The sensor_mode option seems to be a valid camera control when running v4l2-ctl -d /dev/video0 --all, it’s the second line under “Camera Controls”:

Driver Info:
	Driver name      : tegra-video
	Card type        : vi-output, imx219 10-0010
	Bus info         : platform:tegra-capture-vi:2
	Driver version   : 5.10.104
	Capabilities     : 0x84200001
		Video Capture
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x04200001
		Video Capture
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : tegra-camrtc-ca
	Model            : NVIDIA Tegra Video Input Device
	Serial           : 
	Bus info         : 
	Media version    : 5.10.104
	Hardware revision: 0x00000003 (3)
	Driver version   : 5.10.104
Interface Info:
	ID               : 0x03000037
	Type             : V4L Video
Entity Info:
	ID               : 0x00000035 (53)
	Name             : vi-output, imx219 10-0010
	Function         : V4L2 I/O
	Pad 0x01000036   : 0: Sink
	  Link 0x0200003b: from remote pad 0x1000006 of entity '13e40000.host1x:nvcsi@15a00000-': Data, Enabled
Priority: 2
Video input : 0 (Camera 2: ok)
Format Video Capture:
	Width/Height      : 3280/2464
	Pixel Format      : 'RG10' (10-bit Bayer RGRG/GBGB)
	Field             : None
	Bytes per Line    : 6560
	Size Image        : 16163840
	Colorspace        : sRGB
	Transfer Function : Default (maps to sRGB)
	YCbCr/HSV Encoding: Default (maps to ITU-R 601)
	Quantization      : Default (maps to Full Range)
	Flags             : 

Camera Controls

                     group_hold 0x009a2003 (bool)   : default=0 value=0 flags=execute-on-write
                    sensor_mode 0x009a2008 (int64)  : min=0 max=5 step=1 default=0 value=3 flags=slider
                           gain 0x009a2009 (int64)  : min=16 max=170 step=1 default=16 value=16 flags=slider
                       exposure 0x009a200a (int64)  : min=13 max=683709 step=1 default=2495 value=13 flags=slider
                     frame_rate 0x009a200b (int64)  : min=2000000 max=21000000 step=1 default=21000000 value=2000000 flags=slider
           sensor_configuration 0x009a2032 (u32)    : min=0 max=4294967295 step=1 default=0 [22] flags=read-only, volatile, has-payload
         sensor_mode_i2c_packet 0x009a2033 (u32)    : min=0 max=4294967295 step=1 default=0 [1026] flags=read-only, volatile, has-payload
      sensor_control_i2c_packet 0x009a2034 (u32)    : min=0 max=4294967295 step=1 default=0 [1026] flags=read-only, volatile, has-payload
                    bypass_mode 0x009a2064 (intmenu): min=0 max=1 default=0 value=0
				0: 0 (0x0)
				1: 1 (0x1)
                override_enable 0x009a2065 (intmenu): min=0 max=1 default=0 value=0
				0: 0 (0x0)
				1: 1 (0x1)
                   height_align 0x009a2066 (int)    : min=1 max=16 step=1 default=1 value=1
                     size_align 0x009a2067 (intmenu): min=0 max=2 default=0 value=0
				0: 1 (0x1)
				1: 65536 (0x10000)
				2: 131072 (0x20000)
               write_isp_format 0x009a2068 (int)    : min=1 max=1 step=1 default=1 value=1
       sensor_signal_properties 0x009a2069 (u32)    : min=0 max=4294967295 step=1 default=0 [30][18] flags=read-only, has-payload
        sensor_image_properties 0x009a206a (u32)    : min=0 max=4294967295 step=1 default=0 [30][16] flags=read-only, has-payload
      sensor_control_properties 0x009a206b (u32)    : min=0 max=4294967295 step=1 default=0 [30][36] flags=read-only, has-payload
              sensor_dv_timings 0x009a206c (u32)    : min=0 max=4294967295 step=1 default=0 [30][16] flags=read-only, has-payload
               low_latency_mode 0x009a206d (bool)   : default=0 value=0
               preferred_stride 0x009a206e (int)    : min=0 max=65535 step=1 default=0 value=0
                   sensor_modes 0x009a2082 (int)    : min=0 max=30 step=1 default=30 value=5 flags=read-only

Where does v4l2-ctl get the information under “Format Video Capture”? Any way to change this or anyway to change the default value for sensor_mode so it isnt using the imx219_mode_3280x2464_21fps mode?

Similarly when running gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM), width=(int)1280, height=(int)720' ! nvvidconv ! queue ! nv3dsink -v, where is GST_ARGUS getting the sensor mode information from? Is this from some driver or from the device tree?

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/Gstnvvconv:nvvconv0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(string)RGBA
/GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(string)RGBA
/GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(string)RGBA
/GstPipeline:pipeline0/GstNv3dSink:nv3dsink0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(string)RGBA
/GstPipeline:pipeline0/Gstnvvconv:nvvconv0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, format=(string)NV12, framerate=(fraction)30/1
GST_ARGUS: Creating output stream
CONSUMER: Waiting until producer is connected...
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 3280 x 2464 FR = 21.000000 fps Duration = 47619048 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 3280 x 1848 FR = 28.000001 fps Duration = 35714284 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1920 x 1080 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1640 x 1232 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1280 x 720 FR = 59.999999 fps Duration = 16666667 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: Running with following settings:
   Camera index = 0 
   Camera mode  = 4 
   Output Stream W = 1280 H = 720 
   seconds to Run    = 0 
   Frame Rate = 59.999999 
GST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.

Thank you!

Add below to the command line to select desire sensor mode.

--set-fmt-video=width=1280,height=7200

Hi @ShaneCCC,

Thank you, that worked!

Back on the FPDLink Serdes setup, with the lower bandwidth and a device tree modification, I was finally able to get v4l2-ctl to report an fps.

Using the command v4l2-ctl -d /dev/video0 --set-ctrl=sensor_mode=4 --set-fmt-video=width=1280,height=720 --stream-mmap:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 60.12 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 60.12 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 60.12 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 60.12 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 60.12 fps

Now when I try to stream, with the command gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM), width=(int)1280, height=(int)720' ! nvvidconv ! queue ! nv3dsink -v

I get the following:

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:751 No cameras available
/GstPipeline:pipeline0/GstNvArgusCameraSrc:nvarguscamerasrc0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/Gstnvvconv:nvvconv0.GstPad:src: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(string)RGBA
/GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(string)RGBA
/GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(string)RGBA
/GstPipeline:pipeline0/GstNv3dSink:nv3dsink0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, framerate=(fraction)30/1, format=(string)RGBA
/GstPipeline:pipeline0/Gstnvvconv:nvvconv0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, format=(string)NV12, framerate=(fraction)30/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = video/x-raw(memory:NVMM), width=(int)1280, height=(int)720, format=(string)NV12, framerate=(fraction)30/1
Got EOS from element "pipeline0".
Execution ended after 0:00:00.002493841
Setting pipeline to NULL ...
Freeing pipeline ...

Checking the daemon with journalctl -u nvargus-daemon.service, I see:

Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: === gst-launch-1.0[5058]: CameraProvider initialized (0xffff986cff40)=== gst-launch-1.0[5058]: CameraProvider destroyed (0xffff986cff40)=== gst-launch-1.0[5058]: Connection closed (FFFF9ED2C900)=== gst-launch-1.0[5058]: Connection cleaned up (FFFF9ED2C900)=== gst-launch-1.0[10652]: Connection established (FFFF9ED2C900)OFParserListModules: module list: /proc/device-tree/tegra-camera-platform/modules/module0
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: OFParserGetVirtualDevice: NVIDIA Camera virtual enumerator not found in proc device-tree
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: ---- imager: No override file found. ----
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: (NvOdmDevice) Error SymbolNotFound:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function loadModeProperties(), line 791)
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: (NvOdmDevice) Error SymbolNotFound:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function loadModeList(), line 578)
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: (NvOdmDevice) Error SymbolNotFound:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function initialize(), line 124)
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: NvPclDriverInitializeData: Unable to initialize driver v4l2_sensor
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: NvPclInitializeDrivers: error: Failed to init camera sub module v4l2_sensor
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: NvPclStartPlatformDrivers: Failed to start module drivers
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: NvPclDriver_V4L2_Focuser_Stub_Close: Invalid NULL input pPclDriver
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: NvPclStateControllerOpen: Failed ImagerGUID 0. (error 0x30009)
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: NvPclOpen: PCL Open Failed. Error: 0xf
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: SCF: Error BadParameter: Sensor could not be opened. (in src/services/capture/CaptureServiceDeviceSensor.cpp, function getSourceFromGuid(), line 689)
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: SCF: Error BadParameter:  (propagating from src/services/capture/CaptureService.cpp, function addSourceByGuid(), line 453)
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function addSourceByIndex(), line 333)
Nov 30 16:32:41 gecko-desktop nvargus-daemon[973]: SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function getSource(), line 505)

I am assuming OFParserGetVirtualDevice: NVIDIA Camera virtual enumerator not found in proc device-tree is the issue. Any suggestions? I have attached my latest device tree.

kernel_tegra234-p3767-0000-p3768-0000-a0-custom-direct-write.txt (414.1 KB)

Hi @ShaneCCC,

As a quick update to my previous post, I also ran the gstreamer command on the dev kit with the same command just to see what the nvargus logs looked like.

The logs from nvargus-daemon are:

Nov 30 14:24:20 nvidia nvargus-daemon[973]: === gst-launch-1.0[3491]: CameraProvider destroyed (0xffff8c6be600)=== gst-launch-1.0[3491]: Connection closed (FFFF90C41900)=== gst-launch-1.0[3491]: Connection cleaned up (FFFF90C41900)=== gst-launch-1.0[3551]: Connection established (FFFF90C41900)OFParserListModules: module list: /proc/device-tree/tegra-camera-platform/modules/module0
Nov 30 14:24:20 nvidia nvargus-daemon[973]: OFParserListModules: module list: /proc/device-tree/tegra-camera-platform/modules/module1
Nov 30 14:24:20 nvidia nvargus-daemon[973]: OFParserGetVirtualDevice: NVIDIA Camera virtual enumerator not found in proc device-tree
Nov 30 14:24:20 nvidia nvargus-daemon[973]: ---- imager: No override file found. ----
Nov 30 14:24:20 nvidia nvargus-daemon[973]: (NvCamV4l2) Error ModuleNotPresent: V4L2Device not available (in /dvs/git/dirty/git-master_linux/camera/utils/nvcamv4l2/v4l2_device.cpp, function findDevice(), line 256)
Nov 30 14:24:20 nvidia nvargus-daemon[973]: (NvCamV4l2) Error ModuleNotPresent:  (propagating from /dvs/git/dirty/git-master_linux/camera/utils/nvcamv4l2/v4l2_device.cpp, function initialize(), line 60)
Nov 30 14:24:20 nvidia nvargus-daemon[973]: (NvOdmDevice) Error ModuleNotPresent:  (propagating from dvs/git/dirty/git-master_linux/camera-partner/imager/src/devices/V4L2SensorViCsi.cpp, function initialize(), line 107)
Nov 30 14:24:20 nvidia nvargus-daemon[973]: NvPclDriverInitializeData: Unable to initialize driver v4l2_sensor
Nov 30 14:24:20 nvidia nvargus-daemon[973]: NvPclInitializeDrivers: error: Failed to init camera sub module v4l2_sensor
Nov 30 14:24:20 nvidia nvargus-daemon[973]: NvPclStartPlatformDrivers: Failed to start module drivers
Nov 30 14:24:20 nvidia nvargus-daemon[973]: NvPclDriver_V4L2_Focuser_Stub_Close: Invalid NULL input pPclDriver
Nov 30 14:24:20 nvidia nvargus-daemon[973]: NvPclStateControllerOpen: Failed ImagerGUID 1. (error 0xA000E)
Nov 30 14:24:20 nvidia nvargus-daemon[973]: NvPclOpen: PCL Open Failed. Error: 0xf
Nov 30 14:24:20 nvidia nvargus-daemon[973]: SCF: Error BadParameter: Sensor could not be opened. (in src/services/capture/CaptureServiceDeviceSensor.cpp, function getSourceFromGuid(), line 689)
Nov 30 14:24:20 nvidia nvargus-daemon[973]: SCF: Error BadParameter:  (propagating from src/services/capture/CaptureService.cpp, function addSourceByGuid(), line 453)
Nov 30 14:24:20 nvidia nvargus-daemon[973]: SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function addSourceByIndex(), line 333)
Nov 30 14:24:20 nvidia nvargus-daemon[973]: SCF: Error BadParameter:  (propagating from src/api/CameraDriver.cpp, function getSource(), line 505)
Nov 30 14:24:20 nvidia nvargus-daemon[973]: ---- imager: No override file found. ----

This is a link to the difference between the two logs. The logs that say nvidia after the date are the logs from the dev kit and the logs that say gecko-desktop are the logs from the Serdes setup.

It seems like both setups have the camera virtual enumerator not found so maybe this is a non-issue.

The differences I noticed is the use of NvCamV4l2 on the dev kit verses NvOdmDevice on the serdes setup. I also noticed that the dev kit seems to default to module1 under tegra-camera-platform, however in my device tree, I removed module1 in tegra-camera-platform.

Also could you explain what the __symbols__section in the device tree is? Is this automatically generated? Do I have to add / modify symbols if I move stuff around, delete, or add items to the device tree directly (without the use of dsti’s or overlays)?

Thanks again.

This tell the context incorrect of tegra-camera-platform{} like devname, badgeinfo …

Hi @ShaneCCC ,

I double checked tegra-camera-platform and am not seeing any issues.

Here’s my version:

tegra-camera-platform {
		compatible = "nvidia, tegra-camera-platform";
		num_csi_lanes = <0x02>;
		max_lane_speed = <0x16e360>;
		min_bits_per_pixel = <0x0a>;
		vi_peak_byte_per_pixel = <0x02>;
		vi_bw_margin_pct = <0x19>;
		max_pixel_rate = <0x3a980>;
		isp_peak_byte_per_pixel = <0x05>;
		isp_bw_margin_pct = <0x19>;
		phandle = <0x493>;

		modules {

			module0 {
				badge = "jakku_front_RBP194";
				position = "front";
				status = "okay";
				orientation = [31 00];

				drivernode0 {
					pcl_id = "v4l2_sensor";
					devname = "imx219 1-0010";
					proc-device-tree = "/proc/device-tree/i2c@c240000/rbpcv2_imx219_a@10";
					status = "okay";
				};

				drivernode1 {
					pcl_id = "v4l2_lens";
					proc-device-tree = "/proc/device-tree/lens_imx219@RBPCV2/";
					status = "okay";
				};
			};
		};
	};

Here’s the version of the original device tree:

tegra-camera-platform {
		compatible = "nvidia, tegra-camera-platform";
		num_csi_lanes = <0x04>;
		max_lane_speed = <0x16e360>;
		min_bits_per_pixel = <0x0a>;
		vi_peak_byte_per_pixel = <0x02>;
		vi_bw_margin_pct = <0x19>;
		max_pixel_rate = <0x3a980>;
		isp_peak_byte_per_pixel = <0x05>;
		isp_bw_margin_pct = <0x19>;
		phandle = <0x493>;

		modules {

			module0 {
				badge = "jakku_front_RBP194";
				position = "front";
				orientation = [31 00];
				phandle = <0x494>;

				drivernode0 {
					pcl_id = "v4l2_sensor";
					devname = "imx219 9-0010";
					proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@0/rbpcv2_imx219_a@10";
					phandle = <0x495>;
				};

				drivernode1 {
					pcl_id = "v4l2_lens";
					proc-device-tree = "/proc/device-tree/lens_imx219@RBPCV2/";
					phandle = <0x496>;
				};
			};

			module1 {
				badge = "jakku_rear_RBP194";
				position = "rear";
				orientation = [31 00];
				phandle = <0x497>;

				drivernode0 {
					pcl_id = "v4l2_sensor";
					devname = "imx219 10-0010";
					proc-device-tree = "/proc/device-tree/cam_i2cmux/i2c@1/rbpcv2_imx219_c@10";
					phandle = <0x498>;
				};

				drivernode1 {
					pcl_id = "v4l2_lens";
					proc-device-tree = "/proc/device-tree/lens_imx219@RBPCV2/";
					phandle = <0x499>;
				};
			};
		};
	};

I also did :

v4l2-ctl --list-devices
NVIDIA Tegra Video Input Device (platform:tegra-camrtc-ca):
	/dev/media0

vi-output, imx219 1-0010 (platform:tegra-capture-vi:2):
	/dev/video0

and you can see the dev-name matches (mine: imx219 1-0010 and above: imx219 1-0010).

Dump the device tree to confirm.

sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree

Hi @ShaneCCC,

I attached the device tree using your command.

extracted_proc.txt (411.4 KB)

I will continue reviewing but everything looks good to me.

Here is the tegra-camera-platform node from the DT:

	tegra-camera-platform {
		vi_bw_margin_pct = <0x19>;
		max_lane_speed = <0x16e360>;
		vi_peak_byte_per_pixel = <0x02>;
		num_csi_lanes = <0x02>;
		max_pixel_rate = <0x3a980>;
		compatible = "nvidia, tegra-camera-platform";
		min_bits_per_pixel = <0x0a>;
		isp_bw_margin_pct = <0x19>;
		isp_peak_byte_per_pixel = <0x05>;
		phandle = <0x493>;

		modules {

			module0 {
				badge = "jakku_front_RBP194";
				position = "front";
				status = "okay";
				orientation = [31 00];

				drivernode0 {
					devname = "imx219 1-0010";
					proc-device-tree = "/proc/device-tree/i2c@c240000/rbpcv2_imx219_a@10";
					pcl_id = "v4l2_sensor";
					status = "okay";
				};

				drivernode1 {
					proc-device-tree = "/proc/device-tree/lens_imx219@RBPCV2/";
					pcl_id = "v4l2_lens";
					status = "okay";
				};
			};
		};
	};

Using media-ctl -p, I get the following. You can see that the devname matches.

Media controller API version 5.10.104

Media device information
------------------------
driver          tegra-camrtc-ca
model           NVIDIA Tegra Video Input Device
serial          
bus info        
hw revision     0x3
driver version  5.10.104

Device topology
- entity 1: 13e40000.host1x:nvcsi@15a00000- (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
	pad0: Sink
		<- "imx219 1-0010":0 [ENABLED]
	pad1: Source
		-> "vi-output, imx219 1-0010":0 [ENABLED]

- entity 4: imx219 1-0010 (1 pad, 1 link)
            type V4L2 subdev subtype Sensor flags 0
            device node name /dev/v4l-subdev1
	pad0: Source
		[fmt:SRGGB10_1X10/1280x720 field:none colorspace:srgb]
		-> "13e40000.host1x:nvcsi@15a00000-":0 [ENABLED]

- entity 6: vi-output, imx219 1-0010 (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
	pad0: Sink
		<- "13e40000.host1x:nvcsi@15a00000-":1 [ENABLED]

One thing I noticed is that I get two v4l sub devices, v4l-subdev0 and v4l-subdev1. Is that an issue? Also, media-ctl -p -d /dev/video0 seems to give me a segmentation fault but media-ctl -p works just fine.

Hi @ShaneCCC ,

After enabling more debug messages using

sudo service nvargus-daemon stop
sudo su
export enableCamPclLogs=5
export enableCamScfLogs=5
/usr/sbin/nvargus-daemon

I found an issue in the device tree in the camera sensor node. I am now able to stream 1280 x 720 video in the 2 lane configuration using SerDes.

Due to bandwidth limitations, I would like to be able to stream video using 4 lanes and at higher resolution. Do you have any advice or documentation for modifying nv_imx219 to use 4 lanes?