Device tree for 4-lane MIPI CSI-2 camera on Auvidea JN30

Has anyone successfully configured one of the 4-lane MIPI CSI-2 interfaces on the Auvidea JN30 carrier board with the older Jetson Nano devkit SOM? I’m following the rbpi-imx219 device tree examples and have working I2C communication to my sensor (through the 4-lane MIPI connector labeled ‘CSI-2 AB’), but when I attempt to start streaming I see the I2C driver stop_stream function being called shortly after the start_stream, and libargus reports no camera found.

In the device tree I’ve set bus_width and num_csi_lanes to 4, and nvcsi is set up to expect data on channel@0 and port@0/port@1. Can anyone confirm the mapping of nvcsi channels/ports to the 4-lane CSI connectors on the JN30 carrier board, or share details how to map the I2C connection through the 4-lane MIPI connector labeled ‘CSI-2 CD’?

Thanks

Did you get the 4 lane sensor configure from the SONY? The native imx219 driver is 2 lane configure if you want 4 lanes configure you need get the correct configure from the vendor.

I’m connecting another 4-lane Sony sensor, for which I have a working device tree and kernel driver on the Jetson TX2. I’ve ported the dtsi and driver to the Jetson Nano, following the rbpi-imx219 files for reference. I only want to connect a single sensor, on one of the 4-lane CSI-2 ports. I assumed the dual camera rbpi-imx219 example would be appropriate for the two 4-lane MIPI connections on the JN30 so I mapped my sensor under i2c@0 of cam_i2cmux. I see that I2C is working (write and read back is identical) and that the sensor responds to the start sequence (MIPI bus activity is visible on oscilloscope briefly). However the stop_streaming function is called some 50ms after the start sequence.

Are there some methods you could suggest to instrument in the CSI drivers to check if any signal is detected? Thanks

By situating my sensor’s device tree node underneath the i2c@7000c000 branch I am able to perform I2C communication to the image sensor connected to the Auvidea JN30 connector labeled ‘(CD) CSI-2’.

However I still see the same problem whereby libargus cannot find any camera devices and the sensor driver stop_streaming function is called shortly after start_streaming. In my device tree I’ve tried mapping my sensor, once at a time, under all three different 4-lane csi channel options (0, 1, and 2), with corresponding port indices (0, 2, and 4). Based on some bit of documentation from Auvidea it seems the ‘(CD) CSI-2’ connector connects to the CSI4_* pins of the Nano SOM, which I expect to map to CSI channel 2 under port-index 4. Can anyone confirm if this information is accurate? Thanks

Have you check if v4l2-ctl working?

v4l2-ctl -d /dev/video0 --set-fmt-video=width=1920,height=1080,pixelformat=RG10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1

When I run v4l2-ctl (with resolution arguments for my sensor) the command gets stuck until I ctrl-c. I see the following in dmesg:

[ 2336.192926] imxsensor 0-001a: imxsensor_stop_streaming
[ 2336.228553] imxsensor 0-001a: imxsensor_power_off
[ 2363.052526] imxsensor 0-001a: imxsensor_power_on
[ 2363.087579] imxsensor 0-001a: imxsensor_set_mode
[ 2363.104445] imxsensor 0-001a: imxsensor_start_streaming
[ 2363.153483] imxsensor 0-001a: imxsensor_stop_streaming
[ 2363.169087] imxsensor 0-001a: imxsensor_power_off
[ 2363.173406] imxsensor 0-001a: imxsensor_power_on
[ 2363.257715] imxsensor 0-001a: imxsensor_set_mode
[ 2363.274422] imxsensor 0-001a: imxsensor_start_streaming
[ 2363.523771] video4linux video0: frame start syncpt timeout!0
[ 2363.732155] video4linux video0: frame start syncpt timeout!0
[ 2363.939563] video4linux video0: frame start syncpt timeout!0
[ 2364.151862] video4linux video0: frame start syncpt timeout!0
.
. frame start syncpt timeout repeating... 
.

The ‘imxsensor’ prints are from my sensor driver’s methods.

This is the output from media-ctl:

[sudo] password for nvidia: 
Media controller API version 0.1.0

Media device information
------------------------
driver          vi
model           NVIDIA Tegra Video Input Device
serial          
bus info        
hw revision     0x3
driver version  0.0.0

Device topology
- entity 1: nvcsi--3 (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
        pad0: Sink
                <- "imxsensor 6-001a":0 [ENABLED]
        pad1: Source
                -> "vi-output, imxsensor 6-001a":0 [ENABLED]

- entity 4: imxsensor 6-001a (1 pad, 1 link)
            type V4L2 subdev subtype Sensor flags 0
            device node name /dev/v4l-subdev1
        pad0: Source
                [fmt:SRGGB12_1X12/[width]x[height] field:none colorspace:srgb]
                -> "nvcsi--3":0 [ENABLED]

- entity 6: vi-output, imxsensor 6-001a (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
        pad0: Sink
                <- "nvcsi--3":1 [ENABLED]

This is with the device tree endpoints set to point to CSI port 0, and the sensor connected to the ‘AB CSI-2’ connector of the Auvidea JN30 board, which is supposed to be mapped to the CSI_A_* and CSI_B_* pins of the original development kit SOM. Can you confirm if CSI port 0/1 is the correct device tree port to connect for the CSI_A_* and CSI_B_* pins?

Alternatively if I connect the sensor to the port labeled ‘CD CSI-2’, which is supposed to expose the CSI_C_* and CSI_D_* pins, am I supposed to set my sensor output endpoint to the device tree CSI port 2 or to port 4? Note that this is for a 4-lane sensor.

Looks like your sensor output signal may have problem. You may need to probe to confirm it.

In case anyone runs by this, I was able to receive frames through the 4-lane connector labeled “(CD) CSI-2” by:

  1. Setting up sensor underneath i2c@7000c000 in device tree files (outside of host1x, unlike examples involving i2c@546c0000)
  2. Configuring sensor output, csi, vi devices to use channel@1 (port-index = <0x2>) in device tree files
  3. Using the v4l2-ctl command (sensor isn’t working under libargus at the moment) with appropriate arguments for sensor size and data type (i needed to set pixelformat=RG12)
1 Like

Hi,
I am working on the same platform Auvidea JN30B and I am able to capture with a sensor Sony IMX415 from the CSI CD or AB, 4 lanes.

v4l2-ctl -d /dev/video0 --set-fmt-video=width=3872,height=2192,pixelformat=GB10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1

Unfortunately I get in trouble when I am trying to use libargus (nvgstcapture):

  1. if I use the CSI CD connected to VI port-index 2 bus-witdh 4 I always get a timeout after streaming is started
  2. if I use the CSI AB connected to VI port-index 0 bus-width 4 the CPU is halted and a watchdog is triggered

The same situation happens on Jetson Nano Dev kit when the same sensor is connected.
I am really wondering how I can debug this situation.

Thanks

Have a check if v4l2-ctl can capture continuous by --stream-count=100

Yes sure, it can capture contiuously.

v4l2-ctl -d /dev/video0 --set-fmt-video=width=3872,height=2192,pixelformat=GB10 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 60.00 fps
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

I have also posted a trace debug on another post here:

https://devtalk.nvidia.com/default/topic/1068895/jetson-nano/mipi-csi-4-lanes-cause-cpu-halt-on-auvidea-jn30b/post/5414468/#5414468

Could you please boost the nvcsi/vi/isp clock to try.

https://elinux.org/Jetson_TX2_Camera_BringUp

This link is not applicable on my case since I am on Jetson Nano (Auvidea carrier), not on Jetson TX2.
What I am really wondering is that I have the same device tree settings (sensor operating modes) and the same device driver code (with operating mode register tables) and the same nvgstcapture software.
On Jetson TX2 it works, on Jetson Nano it doesn’t.
Which could be the difference ?

Could you configure the sensor output 30fps also set the argus frame rate range to 30 to confirm is bandwidth cause the problem.

I have forced only one mode for the sensor and a fixed data rate of 594 Mbps per lane in a 4 lanes configuration

So the pix clk will be:

pix_clk_hz = 594 Mbps * 4 lanes / 10 bits_per_pixel = 237600000

Line width is taken from the sensor datasheet HMAX register set to 1320, so x 4 is 5280.

mode0 { //
                    mclk_khz = "37125";
                    num_lanes = "4";
                    tegra_sinterface = "serial_a";
                    discontinuous_clk = "no";
                    cil_settletime = "0";
                    active_w = "3864";
                    active_h = "2192";

                    dynamic_pixel_bit_depth = "10";
                    csi_pixel_bit_depth = "10";
                    mode_type = "bayer";
                    pixel_phase = "gbrg";

                    readout_orientation = "0";
                    line_length = "5280";
                    inherent_gain = "1";
                    pix_clk_hz = "237600000";

                    min_gain_val = "1.0";
                    max_gain_val = "72.0";
                    min_hdr_ratio = "1";
                    max_hdr_ratio = "64";
                    min_framerate = "1.462526";
                    max_framerate = "25";
                    min_exp_time = "1";
                    max_exp_time = "65535";
                    embedded_metadata_height = "1";
                };

The dmesg confirms register settings are correct but the capture is still timing out

[  117.828084] imx415_s_ctrl
[  117.828086] imx415_set_storage_time_register
[  117.828246] imx415 0-001a: imx415_write_reg: i2c write OK, 3003 = 0
[  117.828251] imx415 0-001a: imx415_set_operation_mode: operation mode XMASTER reg set to 0
[  117.828396] imx415 0-001a: imx415_write_reg: i2c write OK, 30ce = 0
[  117.828400] imx415 0-001a: imx415_set_sync_mode: operation mode EXTMODE set to 0
[  117.828404] imx415 0-001a: imx415_configure_triggering_pins: Sensor is in Internal sync Master mode
[  117.828548] imx415 0-001a: imx415_write_reg: i2c write OK, 30c1 = 0
[  117.828552] imx415 0-001a: imx415_configure_triggering_pins: XVS_XHS driver register: 0
[  117.828554] imx415_set_data_rate:
[  117.828555] imx415_set_mclk:
[  117.842780] imx415 0-001a: imx415_set_data_rate: Data rate: 6
[  117.842784] imx415 0-001a: imx415_adjust_hmax_register:++
[  117.842937] imx415 0-001a: imx415_write_reg: i2c write OK, 3001 = 1
[  117.843177] imx415 0-001a: imx415_write_reg: i2c write OK, 3028 = 28
[  117.843411] imx415 0-001a: imx415_write_reg: i2c write OK, 3029 = 5
[  117.843562] imx415 0-001a: imx415_write_reg: i2c write OK, 3001 = 0
[  117.843566] imx415 0-001a: imx415_adjust_hmax_register:  HMAX: 1320
[  117.843570] imx415 0-001a: imx415_is_pin_configuration_valid: XVS & XHS as output
[  117.886143] imx415_s_ctrl
[  117.886148] imx415_s_ctrl
[  117.886150] imx415_set_integration_time
[  117.886347] imx415 0-001a: imx415_read_reg: i2c read OK, 3024 value 202
[  117.886527] imx415 0-001a: imx415_read_reg: i2c read OK, 3025 value 8
[  117.886705] imx415 0-001a: imx415_read_reg: i2c read OK, 3026 value 0
[  117.886854] imx415 0-001a: imx415_write_reg: i2c write OK, 3001 = 1
[  117.887000] imx415 0-001a: imx415_write_reg: i2c write OK, 3050 = f0
[  117.887145] imx415 0-001a: imx415_write_reg: i2c write OK, 3051 = 2
[  117.887356] imx415 0-001a: imx415_write_reg: i2c write OK, 3052 = 0
[  117.887521] imx415 0-001a: imx415_write_reg: i2c write OK, 3001 = 0
[  117.887526] imx415_s_ctrl
[  117.928152] imx415_s_ctrl
[  117.928157] imx415_s_ctrl
[  117.928159] imx415_set_integration_time
[  117.928406] imx415 0-001a: imx415_read_reg: i2c read OK, 3024 value 202
[  117.928636] imx415 0-001a: imx415_read_reg: i2c read OK, 3025 value 8
[  117.928816] imx415 0-001a: imx415_read_reg: i2c read OK, 3026 value 0
[  117.928963] imx415 0-001a: imx415_write_reg: i2c write OK, 3001 = 1
[  117.929107] imx415 0-001a: imx415_write_reg: i2c write OK, 3050 = ef
[  117.929251] imx415 0-001a: imx415_write_reg: i2c write OK, 3051 = 2
[  117.929394] imx415 0-001a: imx415_write_reg: i2c write OK, 3052 = 0
[  117.929537] imx415 0-001a: imx415_write_reg: i2c write OK, 3001 = 0
[  117.929540] imx415_s_ctrl
[  119.393050] fence timeout on [ffffffc0b2d676c0] after 1500ms
[  119.393057] name=[nvhost_sync:20], current value=0 waiting value=1
[  119.393062] ---- mlocks ----
[  119.393065] fence timeout on [ffffffc0b2d67540] after 1500ms
[  119.393069] name=[nvhost_sync:21], current value=0 waiting value=1
[  119.393073] ---- mlocks ----

[  119.393077] ---- syncpts ----

[  119.393084] id 1 (disp0_a) min 39 max 39 refs 1 (previous client : )
[  119.393085] ---- syncpts ----
[  119.393089] id 2 (disp0_b) min 3 max 3 refs 1 (previous client : )
[  119.393092] id 3 (disp0_c) min 3 max 3 refs 1 (previous client : )
[  119.393095] id 4 (disp0_d) min 3 max 3 refs 1 (previous client : )
[  119.393102] id 9 (gm20b_507) min 434 max 434 refs 1 (previous client : )
[  119.393106] id 11 (gm20b_506) min 22 max 22 refs 1 (previous client : )
[  119.393110] id 12 (gm20b_505) min 376 max 376 refs 1 (previous client : gm20b_505)
[  119.393113] id 13 (gm20b_504) min 6 max 6 refs 1 (previous client : )
[  119.393121] id 20 (54600000.isp_0) min 0 max 3 refs 4 (previous client : )
[  119.393124] id 21 (54600000.isp_1) min 0 max 3 refs 4 (previous client : )
[  119.393128] id 22 (54600000.isp_2) min 7 max 15 refs 10 (previous client : )
[  119.393132] id 23 (54600000.isp_3) min 0 max 3 refs 4 (previous client : )
[  119.393137] id 26 (vblank0) min 6813 max -6 refs 1 (previous client : )
[  119.393142] id 30 (gm20b_503) min 686 max 686 refs 1 (previous client : )
[  119.393146] id 31 (gm20b_502) min 2 max 2 refs 1 (previous client : )
[  119.393150] id 32 (gm20b_501) min 2 max 2 refs 1 (previous client : )
[  119.393153] id 33 (gm20b_500) min 2 max 2 refs 1 (previous client : )
[  119.393157] id 34 (gm20b_499) min 4 max 4 refs 1 (previous client : )
[  119.393160] id 35 (54080000.vi_0) min 0 max 3 refs 4 (previous client : 54080000.vi_0)
[  119.393165] id 37 (54080000.vi_2) min 2 max 7 refs 7 (previous client : 54080000.vi_2)
[  119.393170] id 40 (54080000.vi_4) min 0 max 3 refs 4 (previous client : 54080000.vi_4)
[  119.393175] id 43 (gm20b_498) min 6 max 6 refs 1 (previous client : )
[  119.393178] id 44 (gm20b_497) min 8 max 8 refs 1 (previous client : )
[  119.393182] id 45 (gm20b_496) min 6 max 6 refs 1 (previous client : )
[  119.393185] id 46 (gm20b_495) min 6 max 6 refs 1 (previous client : )
[  119.393189] id 47 (gm20b_494) min 6 max 6 refs 1 (previous client : )
[  119.393192] id 48 (gm20b_493) min 6 max 6 refs 1 (previous client : )

[  119.393278] ---- channels ----
[  119.393280] id 1 (disp0_a) min 39 max 39 refs 1 (previous client : )
[  119.393283] id 2 (disp0_b) min 3 max 3 refs 1 (previous client : )
[  119.393286] 
               channel 0 - 54600000.isp

[  119.393287] id 3 (disp0_c) min 3 max 3 refs 1 (previous client : )
[  119.393289] id 4 (disp0_d) min 3 max 3 refs 1 (previous client : )
[  119.393293] 0-54600000.isp (18): 
[  119.393296] id 9 (gm20b_507) min 434 max 434 refs 1 (previous client : )
[  119.393296] active class 01, offset 0050, val 00000014
[  119.393298] DMAPUT 00000198, DMAGET 00000110, DMACTL 00000000
[  119.393300] id 11 (gm20b_506) min 22 max 22 refs 1 (previous client : )
[  119.393301] CBREAD 00000014, CBSTAT 00010050
[  119.393304] id 12 (gm20b_505) min 376 max 376 refs 1 (previous client : gm20b_505)
[  119.393305] 
               ffffffc0eb82a400: JOB, syncpt_id=20, syncpt_val=1, first_get=00000090, timeout=10000, num_slots=3, num_handles=1
[  119.393308] id 13 (gm20b_504) min 6 max 6 refs 1 (previous client : )
[  119.393312]     GATHER at ffe30000+4490, 8 words
[  119.393315] 20000001 
[  119.393315] id 20 (54600000.isp_0) min 0 max 3 refs 4 (previous client : )
[  119.393318] 00000414 
[  119.393318] id 21 (54600000.isp_1) min 0 max 3 refs 4 (previous client : )
[  119.393320] 20000001 
[  119.393321] id 22 (54600000.isp_2) min 7 max 15 refs 10 (previous client : )
[  119.393323] 00000515 
[  119.393324] id 23 (54600000.isp_3) min 0 max 3 refs 4 (previous client : )
[  119.393325] 20000001 
[  119.393328] 00000617 
[  119.393328] id 26 (vblank0) min 6813 max -6 refs 1 (previous client : )
[  119.393330] 200c0001 
[  119.393332] 00000005 
[  119.393333] id 30 (gm20b_503) min 686 max 686 refs 1 (previous client : )

[  119.393335] id 31 (gm20b_502) min 2 max 2 refs 1 (previous client : )
[  119.393339]     GATHER at ffe30000+44b0, 2 words
[  119.393339] id 32 (gm20b_501) min 2 max 2 refs 1 (previous client : )
[  119.393342] 20000001 
[  119.393342] id 33 (gm20b_500) min 2 max 2 refs 1 (previous client : )
[  119.393345] 00000016 
[  119.393345] id 34 (gm20b_499) min 4 max 4 refs 1 (previous client : )

[  119.393348] id 35 (54080000.vi_0) min 0 max 3 refs 4 (previous client : 54080000.vi_0)

[  119.393352] id 37 (54080000.vi_2) min 2 max 7 refs 7 (previous client : 54080000.vi_2)
[  119.393352] 
               channel 1 - 54680000.isp

[  119.393357] id 40 (54080000.vi_4) min 0 max 3 refs 4 (previous client : 54080000.vi_4)
[  119.393357] 1-54680000.isp (1): 
[  119.393359] inactive

[  119.393362] id 43 (gm20b_498) min 6 max 6 refs 1 (previous client : )
[  119.393362] 
               channel 2 - 54080000.vi

[  119.393365] id 44 (gm20b_497) min 8 max 8 refs 1 (previous client : )
[  119.393367] 2-54080000.vi (13): 
[  119.393369] id 45 (gm20b_496) min 6 max 6 refs 1 (previous client : )
[  119.393370] active class 01, offset 0050, val 00000023
[  119.393372] DMAPUT 00000100, DMAGET 00000100, DMACTL 00000000
[  119.393373] id 46 (gm20b_495) min 6 max 6 refs 1 (previous client : )
[  119.393375] CBREAD 00000023, CBSTAT 00010050
[  119.393376] id 47 (gm20b_494) min 6 max 6 refs 1 (previous client : )
[  119.393379] id 48 (gm20b_493) min 6 max 6 refs 1 (previous client : )
[  119.393381] 
               ffffffc0ea8f3c00: JOB, syncpt_id=35, syncpt_val=1, first_get=00000018, timeout=10000, num_slots=7, num_handles=1
[  119.393386]     GATHER at ffe38000+0000, 39 words
[  119.393388] 10620001 
[  119.393390] 0000001f 
[  119.393392] 10630002 
[  119.393394] 00000000 
[  119.393396] 00000000 
[  119.393398] 103a0001 
[  119.393400] 10100010 
[  119.393402] 103c0001 
[  119.393404] 10101010 
[  119.393406] 10420001 
[  119.393408] 00000001 
[  119.393410] 10430006 
[  119.393412] 00000000 
[  119.393414] 001c984c 
[  119.393416] 00000000 
[  119.393418] 00000000 
[  119.393420] 00000000 
[  119.393422] 00000000

Here also the output of nvgstcapture

bitrate = 4000000
Encoder Profile = High
Encoder control-rate = 1
Encoder EnableTwopassCBR = 0
Opening in BLOCKING MODE 
** Message: 10:35:34.319: <main:4599> iterating capture loop ....
NvMMLiteOpen : Block : BlockType = 4 
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4 
GST_ARGUS: Creating output stream
CONSUMER: Waiting until producer is connected...
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 3864 x 2192 FR = 25.000000 fps Duration = 40000000 ; Analog Gain range min 1.000000, max 72.000000; Exposure Range min 1000, max 65535000;

GST_ARGUS: Running with following settings:
   Camera index = 0 
   Camera mode  = 0 
   Output Stream W = 3864 H = 2192 
   seconds to Run    = 0 
   Frame Rate = 25.000000 
GST_ARGUS: PowerService: requested_clock_Hz=2016000
GST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.

I tried the same settings on Jetson TX2 and it works, but the output of nvgstcapture is different, saying:

GST_ARGUS: PowerService: requested_clock_Hz=4032000

This is double than the clock required by nvgstcapture on Jetson Nano, why ?

I hope this could be useful for debugging.
I added some debug messages in functions:

  • tegra_camera_update_clknbw
  • calculate_and_set_device_clock
    in file: kernel/nvidia/drivers/video/tegra/camera/tegra_camera_platform.c

Those functions are called when the streaming is operated in bypass mode.

Here is the result on Jetson Nano mounted on Auvidea JN30B carrier board:

[   43.972270] vi 54080000.vi: vi_channel_syncpt_init
[   43.972274] vi 54080000.vi: vi_channel_syncpt_init: vi port 0
[   43.972283] vi 54080000.vi: vi2_channel_start_streaming
[   43.972287] vi 54080000.vi: tegra_channel_ec_init: timeout 50
[   43.972291] tegra_camera_update_clknbw
[   43.972295] tegra_camera_update_clknbw: stream ON pixel rate 237600000, isobw 464062, active streams 1
[   43.972297] calculate_and_set_device_clock
[   43.972300] calculate_and_set_device_clock: VI
[   43.972302] calculate_and_set_device_clock: clock rate 237600001
[   43.972304] calculate_and_set_device_clock: clock rate requested 237600001, clock dev 0
[   43.972307] calculate_and_set_device_clock: set clock rate
[   43.972325] calculate_and_set_device_clock: set clock rate ok 793600000
[   43.972327] calculate_and_set_device_clock
[   43.972329] calculate_and_set_device_clock
[   43.972331] calculate_and_set_device_clock: ISPA or ISPB
[   43.972333] calculate_and_set_device_clock: clock rate 1
[   43.972335] calculate_and_set_device_clock: clock rate requested 1, clock dev 0
[   43.972337] calculate_and_set_device_clock: set clock rate
[   43.972345] calculate_and_set_device_clock: set clock rate ok 793600000
[   43.972347] calculate_and_set_device_clock
[   43.972349] calculate_and_set_device_clock: ISPA or ISPB
[   43.972351] calculate_and_set_device_clock: clock rate 1
[   43.972353] calculate_and_set_device_clock: clock rate requested 1, clock dev 0
[   43.972355] calculate_and_set_device_clock: set clock rate
[   43.973731] calculate_and_set_device_clock: set clock rate ok 307200000
[   43.973752] misc tegra_camera_ctrl: tegra_camera_update_isobw:Set iso bw 464062 kbyteps at 14502 KHz
[   43.973756] misc tegra_camera_ctrl: tegra_camera_isomgr_request++ bw=464062, lt=4
[   43.973787] misc tegra_camera_ctrl: tegra_camera_isomgr_request: tegra_camera isomgr latency is 4 usec

Here is the result on Jetson TX-2 mounted on Jetson TX2 Dev Kit

[   54.254201] tegra-vi4 15700000.vi: vi4_channel_start_streaming
[   54.254204] tegra-vi4 15700000.vi: vi4_channel_start_streaming: chan bypass
[   54.254207] tegra_camera_update_clknbw
[   54.254210] tegra_camera_update_clknbw: stream ON pixel rate 237600000, isobw 464062, active streams 1
[   54.254212] calculate_and_set_device_clock
[   54.254213] calculate_and_set_device_clock: VI
[   54.254215] calculate_and_set_device_clock: clock rate 32670001
[   54.254217] calculate_and_set_device_clock: clock rate requested 32670001, clock dev 0
[   54.254218] calculate_and_set_device_clock: set clock rate
[   54.254534] calculate_and_set_device_clock: set clock rate ok 115200000
[   54.254536] calculate_and_set_device_clock
[   54.254537] calculate_and_set_device_clock
[   54.254539] calculate_and_set_device_clock: CSI
[   54.254540] calculate_and_set_device_clock: clock rate 37125001
[   54.254542] calculate_and_set_device_clock: clock rate requested 37125001, clock dev 0
[   54.254543] calculate_and_set_device_clock: set clock rate
[   54.254818] calculate_and_set_device_clock: set clock rate ok 37500000
[   54.254819] calculate_and_set_device_clock
[   54.254821] calculate_and_set_device_clock: ISPA or ISPB
[   54.254822] calculate_and_set_device_clock: clock rate 138996001
[   54.254824] calculate_and_set_device_clock: clock rate requested 138996001, clock dev 0
[   54.254825] calculate_and_set_device_clock: set clock rate
[   54.255119] calculate_and_set_device_clock: set clock rate ok 140800000
[   54.255126] misc tegra_camera_ctrl: tegra_camera_update_isobw:Set iso bw 464062 kbyteps at 14502 KHz
[   54.255130] misc tegra_camera_ctrl: tegra_camera_isomgr_request++ bw=464062, lt=4
[   54.259025] misc tegra_camera_ctrl: tegra_camera_isomgr_request: tegra_camera isomgr latency is 20 usec

Clock settings are quite different and I am wondering if it is just because are different chips or if there is a bug.
I cannot find a reference example with Jetson Nano 4 lanes capture with CSI → VI → ISP

Could you try to have those function imx415_set_storage_time_register/imx415_set_integration_time as dummy function to try.

Hello

Sorry for troubling, I’m in the same situation like you experienced before, but I was confused a little bit, as imx219 work fine with i2c@546c0000, could you kindly explain some more for how you found the solution and why we should use i2c@7000c000 when creating a new sensor driver and device tree?

Thanks ahead!

You just need a new dtb only for the imx219 sensor.

I think there was a bit of guess and check involved, there wasn’t much in terms of schematics from auvidea to really confirm.

placing the sensor under the ‘i2c@7000c000’ device tree node informs kernel to communicate to the sensor through a different set of pins from the default. This is necessary because the default pins corresponding to i2c@546c0000 are connected to the AB port on the Auvidea board.

I had trouble getting argus (i.e. gstreamer, libargus) to work when connecting a sensor to the CD port, just be aware. Maybe there’s a way to get it to work (with NVIDIA’s help) but in the end we are using the i2c@546c0000 pins to connect to the sensor since we utilize libargus