Multi Virtual Channel Implementation in a CSI port using Xavier NX

Hi JerryChang,
Thanks for your support. Here I have attached kernel message of tegra194-vi5

[ 2.904924] tegra194-vi5 15c10000.vi: using default number of vi channels, 36
[ 2.911488] tegra194-vi5 15c10000.vi: initialized
[ 2.915569] tegra194-vi5 15c10000.vi: tegra_channel_csi_init:Fail to parse port info
[ 2.915790] tegra194-vi5 15c10000.vi: channel init failed
[ 2.915926] tegra194-vi5 15c10000.vi: tegra_channel_csi_init:Fail to parse port info
[ 2.916095] tegra194-vi5 15c10000.vi: channel init failed
[ 2.916217] tegra194-vi5 15c10000.vi: all channel init failed
[ 2.916344] tegra194-vi5 15c10000.vi: Init channel failed
[ 2.916606] tegra194-vi5 15c10000.vi: tegra_vi_media_controller_init: failed
[ 2.916791] tegra194-vi5 15c10000.vi: media controller init failed
Could please suggest some idea to debug it and It doesn’t created any sub device info from VI driver.

Thanks for your time

hello PaulEnoch,

please review the Port Binding session and review your device tree configurations.
you’ll need to assign correct port information in the DT to let VI driver register video nodes.
thanks

Hi JerryChang,
Thanks for your support. I have successfully register imx30 driver in Xavier NX board. When am read data it’s generating error.

Here I have attached my trace log below and screen shot of dmesg
v4l2-ctl-10518 [000] … 431.327688: tegra_channel_open: vi-output, imx390 30-001c
v4l2-ctl-10518 [000] … 431.329000: tegra_channel_set_power: imx390 30-001c : 0x1
v4l2-ctl-10518 [000] … 431.329014: camera_common_s_power: status : 0x1
v4l2-ctl-10518 [000] … 431.329312: tegra_channel_set_power: 15a00000.nvcsi–1 : 0x1
v4l2-ctl-10518 [000] … 431.329316: csi_s_power: enable : 0x1
v4l2-ctl-10518 [001] … 431.338137: tegra_channel_capture_setup: vnc_id 0 W 1920 H 1080 fmt 5
v4l2-ctl-10518 [000] … 431.346758: tegra_channel_set_stream: enable : 0x1
v4l2-ctl-10518 [000] … 431.348747: tegra_channel_set_stream: 15a00000.nvcsi–1 : 0x1
v4l2-ctl-10518 [000] … 431.348752: csi_s_stream: enable : 0x1
v4l2-ctl-10518 [000] … 431.348798: tegra_channel_set_stream: imx390 30-001c : 0x1
kworker/0:3-1931 [000] … 431.352226: rtos_queue_peek_from_isr_failed: tstamp:13882721126 queue:0x0bcbcf78
kworker/0:3-1931 [000] … 431.352231: rtcpu_start: tstamp:13882723701
kworker/0:3-1931 [000] … 431.352233: rtos_queue_send_from_isr_failed: tstamp:13882733442 queue:0x0bcb41f8
kworker/0:3-1931 [000] … 431.352235: rtos_queue_send_from_isr_failed: tstamp:13882733592 queue:0x0bcb8a60
kworker/0:3-1931 [000] … 431.352236: rtos_queue_send_from_isr_failed: tstamp:13882733748 queue:0x0bcba5e0
kworker/0:3-1931 [000] … 431.352237: rtos_queue_send_from_isr_failed: tstamp:13882733894 queue:0x0bcbb3a0
kworker/0:3-1931 [000] … 431.352238: rtos_queue_send_from_isr_failed: tstamp:13882734046 queue:0x0bcbc160
kworker/0:3-1931 [000] … 431.352240: rtcpu_string: tstamp:13882743050 id:0x04010000 str:“vi5_hwinit: firmware CL2018101701 protocol versi”
kworker/0:3-1931 [000] … 431.352242: rtcpu_string: tstamp:13882743171 id:0x04010000 str:"on 2.2
"
kworker/0:3-1931 [000] … 431.352266: rtos_queue_send_from_isr_failed: tstamp:13882838539 queue:0x0bcb41f8
kworker/0:3-1931 [000] … 431.352267: rtos_queue_send_from_isr_failed: tstamp:13882838710 queue:0x0bcb8a60
kworker/0:3-1931 [000] … 431.352268: rtos_queue_send_from_isr_failed: tstamp:13882838866 queue:0x0bcba5e0

 kworker/0:0-4     [000] ....   434.263789: rtos_queue_send_from_isr_failed: tstamp:13973225917 queue:0x0bcba5e0
 kworker/0:0-4     [000] ....   434.263791: rtos_queue_send_from_isr_failed: tstamp:13973226063 queue:0x0bcbb3a0
 kworker/0:0-4     [000] ....   434.263792: rtos_queue_send_from_isr_failed: tstamp:13973226210 queue:0x0bcbc160
 kworker/0:0-4     [000] ....   434.431786: rtos_queue_peek_from_isr_failed: tstamp:13977721489 queue:0x0bcbcf78
 kworker/0:0-4     [000] ....   434.543804: rtos_queue_peek_from_isr_failed: tstamp:13982721488 queue:0x0bcbcf78
 kworker/0:0-4     [000] ....   434.711772: rtos_queue_peek_from_isr_failed: tstamp:13987721489 queue:0x0bcbcf78
 kworker/0:0-4     [000] ....   434.879773: rtos_queue_peek_from_isr_failed: tstamp:13992721481 queue:0x0bcbcf78
 kworker/0:0-4     [000] ....   435.047774: rtos_queue_peek_from_isr_failed: tstamp:13997721489 queue:0x0bcbcf78
 kworker/0:0-4     [000] ....   435.215827: rtos_queue_peek_from_isr_failed: tstamp:14002721489 queue:0x0bcbcf78
    v4l2-ctl-10518 [000] ....   435.256050: tegra_channel_close: vi-output, imx390 30-001c
 kworker/0:0-4     [000] ....   435.271813: rtos_queue_send_from_isr_failed: tstamp:14004735074 queue:0x0bcb41f8
 kworker/0:0-4     [000] ....   435.271818: rtos_queue_send_from_isr_failed: tstamp:14004735226 queue:0x0bcb8a60
 kworker/0:3-1931  [000] ....   435.383864: rtos_queue_peek_from_isr_failed: tstamp:14007721489 queue:0x0bcbcf78
 kworker/0:0-4     [000] ....   435.551818: rtos_queue_peek_from_isr_failed: tstamp:14012721489 queue:0x0bcbcf78
 kworker/0:0-4     [000] ....   435.663764: rtos_queue_peek_from_isr_failed: tstamp:14017721488 queue:0x0bcbcf78
 kworker/0:0-4     [000] ....   435.831766: rtos_queue_peek_from_isr_failed: tstamp:14022721490 queue:0x0bcbcf78
 kworker/0:0-4     [000] ....   435.999761: rtos_queue_peek_from_isr_failed: tstamp:14027721488 queue:0x0bcbcf78
 kworker/0:0-4     [000] ....   436.167754: rtos_queue_peek_from_isr_failed: tstamp:14032721488 queue:0x0bcbcf78
    v4l2-ctl-10518 [001] ....   436.255902: tegra_channel_set_stream: enable : 0x0
    v4l2-ctl-10518 [001] ....   436.255906: tegra_channel_set_stream: imx390 30-001c : 0x0
    v4l2-ctl-10518 [001] ....   436.255918: tegra_channel_set_stream: 15a00000.nvcsi--1 : 0x0
    v4l2-ctl-10518 [001] ....   436.255920: csi_s_stream: enable : 0x0
    v4l2-ctl-10518 [000] ....   436.261468: tegra_channel_set_power: imx390 30-001c : 0x0
    v4l2-ctl-10518 [000] ....   436.261483: camera_common_s_power: status : 0x0
    v4l2-ctl-10518 [000] ....   436.261617: tegra_channel_set_power: 15a00000.nvcsi--1 : 0x0
    v4l2-ctl-10518 [000] ....   436.261620: csi_s_power: enable : 0x0
 kworker/0:0-4     [000] ....   436.279807: rtos_queue_send_from_isr_failed: tstamp:14036251427 queue:0x0bcb41f8
 kworker/0:0-4     [000] ....   436.279823: rtos_queue_send_from_isr_failed: tstamp:14036251581 queue:0x0bcb8a60
 kworker/0:0-4     [000] ....   436.279825: rtos_queue_send_from_isr_failed: tstamp:14036251737 queue:0x0bcba5e0
 kworker/0:0-4     [000] ....   436.279826: rtos_queue_send_from_isr_failed: tstamp:14036251882 queue:0x0bcbb3a0

Thanks for your time.

Thanks for your time.

hello PaulEnoch,

it’s VI engine to setup the buffers for receiving the signal according to device tree properties, you should review those device tree properties settings.
those DT properties should match your actual sensor MIPI signaling.

according to your VI tracing messages, it looks VI engine did not receive frame signals.
for example, you should see PXL_SOF and PXL_EOF which indicate start-of-frame and end-of-frame.

I would suggest you to examine your Sensor Pixel Clock settings, it’s camera software uses the sensor pixel clock to calculate the exposure and frame rate of the sensor. you must configure pix_clk_hz correctly to avoid some potential issues.
thanks

Hi JerryChang,
Thanks for your support. I have checked my clock it’s fine and it’s working on imx219 driver but it’s throughing error in my imx390 driver. Is any other chances for populating error.

Thanks for your time

hello PaulEnoch,

according to Approaches for Validating and Testing the V4L2 Driver, could you please use V4L2 IOCTL to verify basic functionality during sensor bring-up.
thanks

Hi JerryChang,
Thanks for your support. Finally we able to receive 2 channel parallely using imx390 sensor. The issue in resolution and default image height macro. Thank you so much Jerry.
After receiving 4 channel packet I will update you.

Thanks for your time.

Hi JerryChang,
I have enabled 4 virtual channels and driver also successfully loaded. but sub dev and /dev/video2 and /dev/video3 is not registered. I have attached my dmesg log.

[ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.429603] DTS File Name: …/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t19x/jakku/kernel-dts/tegra194-p3668-all-p3509-0000.dts
[ 0.700706] DTS File Name: …/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t19x/jakku/kernel-dts/tegra194-p3668-all-p3509-0000.dts
[ 0.719456] iommu: Adding device 3180000.i2c to group 12
[ 0.788194] vdd-sdmmc1-sw: 3300 mV
[ 1.457135] t194-nvcsi 15a00000.nvcsi: initialized
[ 2.118946] tegra194_cpufreq_probe: platform driver Initialization: pass
[ 2.146144] misc nvmap: cvsram :dma coherent mem declare 0x0000000050000000,4194304
[ 2.993281] tegra194-isp5 14800000.isp: initialized
[ 2.999694] tegra194-vi5 15c10000.vi: using default number of vi channels, 36
[ 3.006886] tegra194-vi5 15c10000.vi: initialized
[ 3.010860] tegra194-vi5 15c10000.vi: subdev 15a00000.nvcsi–2 bound
[ 3.010929] tegra194-vi5 15c10000.vi: subdev 15a00000.nvcsi–1 bound
[ 5.429971] tegra194-vi5 15c10000.vi: subdev imx390 30-001b bound
[ 5.431616] tegra194-vi5 15c10000.vi: subdev imx390 30-001c bound
[ 0.573907] CPU4: Booted secondary processor [4e0f0040]
[ 5.429320] imx390 30-001b: probing v4l2 sensor.
[ 5.429919] imx390 30-001b: tegracam sensor driver:imx390_v2.0.6
[ 5.429971] tegra194-vi5 15c10000.vi: subdev imx390 30-001b bound
[ 5.431118] imx390 30-001b: Detected IMX390 sensor
[ 5.431185] imx390 30-001c: probing v4l2 sensor.
[ 5.431366] imx390 30-001c: couldn’t create debugfs
[ 5.431579] imx390 30-001c: tegracam sensor driver:imx390_v2.0.6
[ 5.431616] tegra194-vi5 15c10000.vi: subdev imx390 30-001c bound
[ 5.432205] imx390 30-001c: Detected IMX390 sensor
[ 5.432288] imx390 30-001d: probing v4l2 sensor.
[ 5.432466] imx390 30-001d: couldn’t create debugfs
[ 5.432664] imx390 30-001d: tegracam sensor driver:imx390_v2.0.6
[ 5.432700] imx390 30-001d: Detected IMX390 sensor
[ 5.432812] imx390 30-001e: probing v4l2 sensor.
[ 5.432950] imx390 30-001e: couldn’t create debugfs
[ 5.433124] imx390 30-001e: tegracam sensor driver:imx390_v2.0.6
[ 5.433154] imx390 30-001e: Detected IMX390 sensor

Could you please suggest any idea to debug it.

Thanks for your time

Hello JerryChang,
Thanks for your time and support. Finally we able to read 4 VC packet the issue in channel_numbers in dtsi file. Now am reading my frame using v4l2 API in C that I can read data using memmap but when am using userprt concept it’s generating following. could you please suggest some document for this and any idea to debug it.

VIDIC_QBUF error 22, Invalid argument.
Here I have attached my c file.
Thanks for your timev4l2.c (19.0 KB)

Hi JerryChang,
We solved the issue. Thanks for your support.

hello PaulEnoch,

glad to know your use-case works,
to summarize, could you please share some information about your solutions. is it sensor driver issues?
thanks

Hello JerryChang,
Issue in memory copy. This Link helped me [closed]Slow copy: memcpy 26Mb = 190ms with MMAP. IO_METHOD_USERPTR now works. . Thanks for your time and support.

Hi JerryChang,
My driver is working properly in above 850Mbps. But its not working for below 850Mbps data rate. I have changed settle time, then also no improvement, Is there any limitation in Xavier NX datarate/pixel_clock. Could you please suggest some Idea to debug it.
Then one doubt JerryChang, How to read the status of register in csi5_fops.c and vi5_fops.c file for debugging. And also, Is any possibility there to check what is the error like LP error or SOT error or Start frame error or clock error.

Here I have attached dmesg

Thanks for your time

hello PaulEnoch,

that sensor data rate setting in device tree should be identical of your sensor outputs.
may I know what’s the scenario for setting data rate below 850-Mbps?
thanks

Hi JerryChang,
Thanks for your reply. My custom sensor can send data from 200 Mbps to 1.3Gbps by configuring. So that we tested different data rate by configuring sensor and dtsi (pixel clock and settle time) file in imx390. In that it’s working in 1.3Gbps and 900Mbps But When my sensor configured for 650, 450, 220 and 350 Mbps its not working. Could you please suggest any idea.

Thanks for your time.

hello PaulEnoch,

Xavier’s VI engine is timing sensitive, it should be timing issue for different sensor data rate settings.
please have a try to add set_mode_delay_ms property for increasing timeout values for 1st frame.
for example,

set_mode_delay_ms | Maximum wait time for the first frame after capture starts, in milliseconds.

Hi JerryChang,
Thanks for your reply, I have attached My dtsi file updated section for clarification. Could please check am added correctly.

Thanks for your time

hello PaulEnoch,

just for confirmation,
did you also modify the serdes_pix_clk_hz property for your lower sensor data rate configuration.

BTW,
may I know which JetPack release you’re working with.
you may check release tag for details, i.e. $ cat /etc/nv_tegra_release
thanks

Hello JerryChang,
Thanks for your reply. yes I modified serdes_pix_clk_hz as same as pixel_clk because I didn’t found method to calculate it.
I have tested upto CAPTURE_TIMEOUT_MS =25000ms but there is no change in error.
Here I have atttached the output of $ cat /etc/nv_tegra_release in below.
# R32 (release), REVISION: 4.4, GCID: 23942405, BOARD: t186ref, EABI: aarch64, DATE: Fri Oct 16 19:37:08 UTC 2020

    Could you please suggest any solution to debug it.

Thanks for your time

hello PaulEnoch,

could you please have a try by update the scf binary with the attachment, Topic160038_Dec01.zip (2.7 MB)
you may using scp to copy that binary to your target and overwrite the libnvscf.so binary.
thereafter, please perform a warm-reboot to have verification.
for example,

$ sudo cp /tmp/Topic160038_Dec01_libnvscf.so  /usr/lib/aarch64-linux-gnu/tegra/libnvscf.so
$ sudo reboot