JP5.1.3: Camera Sensors Ports Bindings: Something's wrong with port #2

[bsp_dev]

Hi,
We have a custom carrier board with 4 camera sensors (ser/des pairs) and JP5.1.3
csi port 0 - FPD Link ser/des
csi port 1 - FPD Link ser/des
csi port 2 - GMSL ser/des (aka GMSL_A)
csi port 3 - GMSL ser/des (aka GMSL_B)
We noticed that both GMSL_A and GMSL_B ser/des work when connected to port 3 but not when connected to port 2.

I wonder if there is an error with our port bindings?
final dt:
final_dt.txt (425.2 KB)
We took an example of two sensors dt and extended it into 4 sensors vi-nvcsi-ser/des-sensor system.

Thanks

[ShaneCCC]

Didn’t find any problem for the port-index for the CSI-C(port-2)

Maybe check the trace log if any clue for the failed.

Thanks

[bsp_dev]

Thank you for your answer.
@ShaneCCC , can you please instruct me how to produce informative debug messages for you that can be examined?

for now this is the media_ctl outpu:
media_ctl.log (951 Bytes)

[ShaneCCC]

Get the trace log.

https://elinux.org/Jetson/l4t/Camera_BringUp

[bsp_dev]

Hi,
Should I follow the TX1 instructions or the TX2?

I executed the following steps:
1.

• Boost the clock for debug.

sudo su echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/isp/rate cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate

and got the following output:

832000000
1011200000
642900000

then executed:

sudo su cd /sys/kernel/debug/dynamic_debug/ echo file csi2_fops.c +p > control

v4l2-ctl -d /dev/video0 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3

and recevied the same error (

[09:14:50:580] [ 236.462209] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms␍␊

)
without extended trace log.

Do I produce it right?

[ShaneCCC]

Get the trace log.

echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 2 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace
 
launch camera
get the trace log by below command.
cat /sys/kernel/debug/tracing/trace > t.log

[bsp_dev]

Thanks. This is the output:
trace.log (4.5 KB)

[ShaneCCC]

Does looks like receive any data from the sensor.
Could you probe the signal to confirm.

[bsp_dev]

The signal is good because if I connect the same sensor (ser/des in my case) to port 3 instead port 2 it works.

@ShaneCCC Would you mind for us to dig a little bit deeper to my current DT settings? Maybe I miss understand something in the configuration? Can I share it with you?

[ShaneCCC]

The tegra_sinterface are incorrect.

CSI-0 - serial_a
CSI-1 - serial_b
CSI-2 - serial_c
CSI-3 - serial_d

[bsp_dev]

Yes, you right. I already fixed that and didn’t send you the last version ( I apologise)

This is my current dt:
final_dt.txt (425.2 KB)

Current media-ctl output before loading sensors 2/3 (total 4 sensors 0-3) kernel modules:
media_ctl.log (924 Bytes)

Current media-ctl output after loading sensors 2/3 (total 4 sensors 0-3) kernel modules:
media_ctl_after_loding_kernel_modules.log (2.5 KB)

From some reason it seems that sensor 3 (the last sensor connected to CSI 3) and sensor 2 (connected to CSI 2) are conflict?

maybe I did a mistake in another place regarding the configuration?

my system:

PI = Device Tree Port Index Property

Sensor #	Pysical CSI	lanes #	Sensor PI	NVCSI PI	VI PI	tegra_sinterface	lane_polarity
0	0	2	0	0	0	serial_a	6
--------	---------	-----------	--------------	--------------	--------------	------------------	---------------
1	1	2	1	1	1	serial_b	1
--------	---------	-----------	--------------	--------------	--------------	------------------	---------------
2	2	2	2	2	2	serial_c	0
--------	---------	-----------	--------------	--------------	--------------	------------------	---------------
3	3	2	3	3	3	serial_d	0
--------	---------	-----------	--------------	--------------	--------------	------------------	---------------

Thank you for your patience!

[ShaneCCC]

Didn’t see any problem for the port configuration.
You can add message to print the port-index in csi5_fops.c to confirm and have HW to review the design if any HW problem.

[bsp_dev]

Thanks @ShaneCCC ,
Can you please elaborate regarding how to debug this issue?

what is the csi5_fops.c file and what I can do with it?
what do you mean to print the port-index? what this will be indicating?

Thanks

[ShaneCCC]

csi5_fops.c is kernel driver you can follow below command to download and build the kernel Image.

https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/Kernel.html

[bsp_dev]

Thanks @ShaneCCC .

Can you please instruct me to what to do with this kernel driver in order to examine my port 2/3 problem?
What this driver does? and how to modify it in order to generate helpful info for my problem?

[ShaneCCC]

csi5_fops.c is the NVCSI driver to configurate the NVCSI depend on the device tree configuration. You can print necessary message to make sure the port binding or any others configuration from dts.

Thanks

[bsp_dev]

Can I build and load it as a kernel module? Which kernel configuration I should disable in order to use it as a kernel module?

Thanks

[ShaneCCC]

For JP5 need huge modify but JP6.
JP6 was compile it as LKM already. Maybe you can reference to JP6 to modify it.

[bsp_dev]

Hi @ShaneCCC ,
Currently its not possible for me to move to JP6.

In order to try and identify the problem more easy I did the following:

I created a DT with almost identical i2c v4l2 device nodes:

1. i2c@3 node with max9288_des0@48 sub node
2. i2c@4 node with max9288_des1@68 sub node

I put the same settings in both nodes except for the port-index (and reg value)

If I plug my sensor to physical CSI2 it doesn’t work.
If I plug my sensor to physical CSI3 it works.

Both dt nodes use the same driver so the only difference are the port bindings.

This dt contains 4 sensors since this is what supposed to be in the system but right now we testing the problem with port 2.

We refer physical CSI2 and CSI3 according to this:

and assume port-index = 3 is suitable to physical CSI3 and port-index = 2 is suitable to physical CSI2

May this approach be helpful to debug the problem?
this is the dt:
final_dt.txt (425.1 KB)

Thanks again for you pateince!

[ShaneCCC]

Didn’t find any problem for the dts configuration.
Maybe check the HW to confirm.