Multi Virtual Channel Implementation in a CSI port using Xavier NX

Hello JerryChang,
Actually I checked settle time using DSO, it’s 240ns for 600Mbps which is not working. For working condition the settle time for 900 and 1.3Gpbs is 220ns. I configure these value in 8 bit settle time register but still it’s populating same error. Could you please suggest any Idea.

thanks for your time

hello PaulEnoch,

may I know which PHY mode your camera sensor configured.
could you please have a try to hard-code the settle time in the driver instead of reading from device tree property.
for example,
$L4T_Sources/r32.4.4/Linux_for_Tegra/source/public/kernel/nvidia/drivers/media/platform/tegra/camera/nvcsi/csi5_fops.c

static int csi5_stream_set_config(struct tegra_csi_channel *chan, u32 stream_id, u32 csi_port, int csi_lanes)
{
...
        unsigned int cil_settletime = read_settle_time_from_dt(chan);

Hello JerryChang,
Thanks for your support, We are using D-phy mode. I check it.
Right now am trying to read 10FPS in 4channel parallely. but I can read only one frame per second in each channel . Could you please give any suggestion to debug it.

Thanks for your time

hello PaulEnoch,

please also refer to similar discussion thread, Topic 156867, even this based-on different Jetson platform.
you might also look into Virtual channel ID for some clues.
thanks

Hello JerryChang,
Thanks for your support, I am getting following error in trace and dmesg

when am reading. Could you please suggest any idea.

 kworker/0:1-9445  [000] ....  4156.591256: rtos_queue_peek_from_isr_failed: tstamp:130295441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4156.703205: rtos_queue_peek_from_isr_failed: tstamp:130300441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4156.871221: rtos_queue_peek_from_isr_failed: tstamp:130305441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4157.039197: rtos_queue_peek_from_isr_failed: tstamp:130310441020 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4157.207175: rtos_queue_peek_from_isr_failed: tstamp:130315441022 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4157.375171: rtos_queue_peek_from_isr_failed: tstamp:130320441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4157.543136: rtos_queue_peek_from_isr_failed: tstamp:130325441020 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4157.711150: rtos_queue_peek_from_isr_failed: tstamp:130330441018 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4157.823132: rtos_queue_peek_from_isr_failed: tstamp:130335441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4157.991137: rtos_queue_peek_from_isr_failed: tstamp:130340441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4158.159110: rtos_queue_peek_from_isr_failed: tstamp:130345441017 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4158.327170: rtos_queue_peek_from_isr_failed: tstamp:130350441017 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4158.495088: rtos_queue_peek_from_isr_failed: tstamp:130355441020 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4158.663091: rtos_queue_peek_from_isr_failed: tstamp:130360441020 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4158.831067: rtos_queue_peek_from_isr_failed: tstamp:130365441020 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4158.943099: rtos_queue_peek_from_isr_failed: tstamp:130370441018 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4159.111053: rtos_queue_peek_from_isr_failed: tstamp:130375441020 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4159.279082: rtos_queue_peek_from_isr_failed: tstamp:130380441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4159.447025: rtos_queue_peek_from_isr_failed: tstamp:130385441022 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4159.615013: rtos_queue_peek_from_isr_failed: tstamp:130390441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4159.783032: rtos_queue_peek_from_isr_failed: tstamp:130395441017 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4159.951032: rtos_queue_peek_from_isr_failed: tstamp:130400441017 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4160.062982: rtos_queue_peek_from_isr_failed: tstamp:130405441017 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4160.230979: rtos_queue_peek_from_isr_failed: tstamp:130410441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4160.398990: rtos_queue_peek_from_isr_failed: tstamp:130415441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4160.566960: rtos_queue_peek_from_isr_failed: tstamp:130420441018 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4160.734965: rtos_queue_peek_from_isr_failed: tstamp:130425441020 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4160.902945: rtos_queue_peek_from_isr_failed: tstamp:130430441022 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4161.070941: rtos_queue_peek_from_isr_failed: tstamp:130435441021 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4161.182927: rtos_queue_peek_from_isr_failed: tstamp:130440441016 queue:0x0bcbcf78
 kworker/0:1-9445  [000] ....  4161.350910: rtos_queue_peek_from_isr_failed: tstamp:130445085397 queue:0x0bcbcf78
   Mipi_Csi2-9686  [001] ....  4173.202921: tegra_channel_open: vi-output, radarV01 30-001b
   Mipi_Csi2-9686  [001] ....  4173.204345: tegra_channel_set_power: radarV01 30-001b : 0x1
   Mipi_Csi2-9686  [001] ....  4173.204356: camera_common_s_power: status : 0x1
   Mipi_Csi2-9686  [001] ....  4173.204725: tegra_channel_set_power: 15a00000.nvcsi--4 : 0x1
   Mipi_Csi2-9686  [001] ....  4173.204729: csi_s_power: enable : 0x1
   Mipi_Csi2-9686  [001] ....  4173.208027: tegra_channel_capture_setup: vnc_id 0 W 4096 H 1 fmt 5
   Mipi_Csi2-9686  [001] ....  4173.225594: tegra_channel_set_stream: enable : 0x1
   Mipi_Csi2-9686  [001] ....  4173.227423: tegra_channel_set_stream: 15a00000.nvcsi--4 : 0x1
   Mipi_Csi2-9686  [001] ....  4173.227428: csi_s_stream: enable : 0x1
   Mipi_Csi2-9686  [001] ....  4173.227474: tegra_channel_set_stream: radarV01 30-001b : 0x1

vi-output, rada-9688 [001] … 4173.231489: tegra_channel_capture_frame: sof:4186.146200832
vi-output, rada-9688 [001] … 4173.231493: tegra_channel_capture_frame: eof:4186.146213280
vi-output, rada-9688 [001] … 4175.933534: tegra_channel_capture_setup: vnc_id 0 W 4096 H 1 fmt 5
Mipi_Csi2-9686 [001] … 4175.933951: tegra_channel_set_stream: enable : 0x0
Mipi_Csi2-9686 [001] … 4175.933954: tegra_channel_set_stream: radarV01 30-001b : 0x0
Mipi_Csi2-9686 [001] … 4175.933964: tegra_channel_set_stream: 15a00000.nvcsi–4 : 0x0
Mipi_Csi2-9686 [001] … 4175.933966: csi_s_stream: enable : 0x0
Mipi_Csi2-9686 [001] … 4175.937749: tegra_channel_close: vi-output, radarV01 30-001b
Mipi_Csi2-9686 [001] … 4175.937795: tegra_channel_set_power: radarV01 30-001b : 0x0
Mipi_Csi2-9686 [001] … 4175.937800: camera_common_s_power: status : 0x0
Mipi_Csi2-9686 [001] … 4175.937934: tegra_channel_set_power: 15a00000.nvcsi–4 : 0x0
Mipi_Csi2-9686 [001] … 4175.937938: csi_s_power: enable : 0x0
kworker/0:0-9524 [000] … 4175.939888: rtos_queue_peek_from_isr_failed: tstamp:130816434890 queue:0x0bcbcf78
kworker/0:0-9524 [000] … 4175.939894: rtcpu_start: tstamp:130816437579
kworker/0:0-9524 [000] … 4175.939896: rtos_queue_send_from_isr_failed: tstamp:130816447674 queue:0x0bcb41f8
kworker/0:0-9524 [000] … 4175.939898: rtos_queue_send_from_isr_failed: tstamp:130816447825 queue:0x0bcb8a60
kworker/0:0-9524 [000] … 4175.939899: rtos_queue_send_from_isr_failed: tstamp:130816447976 queue:0x0bcba5e0
kworker/0:0-9524 [000] … 4175.939900: rtos_queue_send_from_isr_failed: tstamp:130816448124 queue:0x0bcbb3a0
kworker/0:0-9524 [000] … 4175.939901: rtos_queue_send_from_isr_failed: tstamp:130816448273 queue:0x0bcbc160
kworker/0:0-9524 [000] … 4175.939902: rtcpu_string: tstamp:130816457268 id:0x04010000 str:“vi5_hwinit: firmware CL2018101701 protocol versi”
kworker/0:0-9524 [000] … 4175.939904: rtcpu_string: tstamp:130816457403 id:0x04010000 str:"on 2.2

Thanks for your time

hello PaulEnoch,

according to your DT property settings, you’re having sensor mode with 256x1.
I’m wondering why tegra_channel_capture_setup() shows 4096x1,

please also access Jetson Virtual Channel with GMSL Framework Guide via download center; please have a try to enable virtual channel to distinguish them as 4 separate signals.
thanks

Hello JerryChang,
Thanks for your support, I have updated my dtsi file to 4096*1. I have enabled 4 VC separately.
Could you please give me any reference to read this 4VC data in parallel using v4l2 API in C. Is there any reference C code to read multi camera parallel. Is any multi thread programming reference is there for reading this data in parallel using C.

Thanks for your time

hello PaulEnoch,

according to CSI and USB Camera Features, it’s device tree property to add vc-id and vc_id for VC Supports.
you may check the reference drivers, and also the documentation in post #55 for more details.
for example,
$L4T_Sources/r32.4.3/Linux_for_Tegra/source/public/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-modules/tegra186-camera-imx390-a00.dtsi

Hello JerryChang,
Thanks for your support, Can I use libargus API for reading 4VC data parallel in RAW8 format. Which is the best API I to read multiple /dev/video* device in parallel .
Could you please suggest any Idea to do it.

Thanks for your time

hello PaulEnoch,

since we don’t such camera sensor to output single row data (4096x1) for validation.
my assumption is enable VC supports to make camera driver to recognize it as four separate steams;
you’ll also need to enable multi-cam application for testing, i.e. 13_multi_camera.

please also note that,
VI engine should recognize the start-of-frame and end-of-frame of each available sensor output frames for capture buffers.

BTW,
please also check similar discussion thread, Topic 156867 for reference,
thanks

Hello JerryChang,
Thanks for your support, I wil check it, Now I found a issue that when I connected csi port with empty mipi flex connection , My cap.ccap.c (19.2 KB) code is reading zero as RAW data instead of getting timeout. In v4l2-ctl it’s not reading anything(as I expected).
Here I have attached my v4l2 API C file.

Note:
Same setup I tried in jetson nano my cap.c code not reading any RAW data and print select timeout after time expired. I am not getting why it’s reading zero RAW data when sensor is not sending anything to xavier NX.
Could you please give me any Idea to debug it.
Thanks for your patient and time.

Current argus doesn’t support RAW8 input format.
The reading zero as RAW that tell the v4l2 framework return empty buffer back to user space.

Hello ShaneCCC,
Thanks for your support, When am reading using above cap.c file my raw file contain only repeating packets. And it’s not reading any new packetsn now only I found it. Could you please suggest any Idea. But in v4l2-ctl command I can able to read packet sequentially.

thanks for your time.

Try skip first 10 frames to check.

Hello ShaneCCC,
Thanks for your support, If I started my v4l2 application(cap.c) after my custom sensor start sending frame it’s reading . But If I start v4l2 application first and then my custom sensor sending data means it’s reading empty frame or repeating same packets. How to ignore these cases. But these issue is not coming in jetson Nano I am facing only in xavier NX.
Could you please suggest any solution.

Thanks for your support.

I think the sensor streaming should control by the xxx_stream_on function instead of control manually.

Hello ShaneCCC,
Thanks for your support, I am manually on the stream using the following api.
xioctl(fd, VIDIOC_STREAMON, &type);. could you please suggest any idea.

Thanks for your time

I think you can check the sequence of the v4l2-ctl and compare with your APP to check the problem.

Hi ShaneCCC,
Can you look this link : Increase VI5 queue size - #2 by PaulEnoch

thanks for your time.