Multi Virtual Channel Implementation in a CSI port using Xavier NX

Hello JerryChang,
Thanks for your support. I updated my libnvscf.so as you mentioned above, still having same problem that can’t read data in below 850 Mbps data rate. I am not getting any idea because I can’t see the status of register and if I gave any settle time data reading above 900Mbps data rate. Sorry is any other solution to debug it.

         Is there anyway to read and check register(NVCSI & VI5) status.

Thanks for your time.

hello PaulEnoch,

please access Xavier Series SoC Technical Reference Manual via download center.
please refer to Chapter-7.2.1 for the CSI chapter, and please refer to [7.2.1.4 NVCSI Registers] for register offsets.
you may use 3rdparty tools, such as devmem2 to access the registers for checking its values.
please note that, you should enable the camera stream to dump register values.
thanks

Hello JerryChang,
Thanks for your support. I will check my registers.If you have any suggestion about this error means please share it.

Thanks for your time

Hello JerryChang,
I have try to read NVCSI_PHY_0_NVCSI_CIL_A_CONTROL_0 register, it’s showing following error. I enable camera streaming using V4l2-ctl command.
sudo devmem2 0x00441c
/dev/mem opened.
Memory mapped at address 0x7fb30f4000.
Bus error

Thanks for your time.

hello PaulEnoch,

you should also note that each of the stream-id having different register offsets.
please confirm you’re checking correct registers.

Hello JerryChang,
Thanks for your support. I want to check whether settle time is changing, so that I have checked all the register related to settle time which is provided in document. Am getting bus error or segmentation fault. Is in kernel source any header file hold these register offset details, Because when am looking Csi5_fops.c file am not getting details about register offset.
Is any way to read the register by calling some function in csi5_fops.c file.

Thanks for your time

hello PaulEnoch,

FYI, settle time is read via device tree property settings, it’s auto calculated if you’d configure the value to zero.

Hello JerryChang,
Thanks for your support. I have calculated settletime and converted to xavierNx as per TRM details and configure in dtsi file (30 - 60). In all settle time above 900 Mbps working fine but it’s not working below 800Mbps, So that I thought read and check register . I checked cil_config.t_hs_settle in csi5_fops.c through debug print its changing. I am not getting that when am changing settletime how it’s reading only above 900Mbps always.

Do you have any Idea where the error is.

Thanks for your time.

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.