We have 2 GMSL camera and MIPI output 2 lane to AGX Orin CSI-0 and CSI2, as below block diagram:
I could see /dev/video0 and /dev/video1, and topology is:
Q1.But I only could capture /dev/video0, and can’t capture /dev/video1.
Q2. I could capture /dev/video0, but can’t capture /dev/video1 everytime.
The success rate are 20%.
May I to know how to analyze these issue?
Did you confirm with Max to confirm if Max9296 able support connect to different lanes?
I think Max9296 should connect to either CSI0 or CSI2 and output support different camera by virtual channel ID.
We have another MAX9296 on AGX Xavier, and it works.
1st MAX9296 output 2 lane *2, and to CSI0, CSI1 on AGX Xavier.
2nd MAX9296 output 2 lane *2, and to CSI2, CSI3 on AGX Xavier.
3rd MAX9296 output 2 lane *2, and to CSI4, CSI5 on AGX Xavier.
If I use one MAX9296 output 2 lane * 2, and our current shematic layout to CSI0, CSI2 on AGX Orin, and set tegra_sinterface in device tree:
CSI0:
tegra_sinterface = “serial_a”;
CSI2:
tegra_sinterface = “serial_c”;
Is it correct? or any other setting need to check?
The set tegra_sinterface configure is correct if one Max9296 able support this kind of use case.
How about the port-index?
Here are my device tree setting:
tegra234-p3737-max9296_two_lane.dtsi (5.7 KB)
sensor_mode.dtsi (2.8 KB)
The configure looks fine.
Maybe check the trace log.
Here are my enable trace command:
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/rateecho 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/traceecho 2 > /sys/class/video4linux/video0/dev_debug
echo file vi2_fops.c +p > /sys/kernel/debug/dynamic_debug/control
echo file csi2_fops.c +p > /sys/kernel/debug/dynamic_debug/control
echo file vi4_fops.c +p > /sys/kernel/debug/dynamic_debug/control
echo file csi.c +p > /sys/kernel/debug/dynamic_debug/control
echo file csi4_fops.c +p > /sys/kernel/debug/dynamic_debug/control
echo file csi5_fops.c +p > /sys/kernel/debug/dynamic_debug/control
echo file nvcsi.c +p > /sys/kernel/debug/dynamic_debug/control
echo file v4l2-compat-ioctl32.c +p > /sys/kernel/debug/dynamic_debug/control
echo file tegracam_v4l2.c +p > /sys/kernel/debug/dynamic_debug/control
echo file channel.c +p > /sys/kernel/debug/dynamic_debug/controlv4l2-ctl -d /dev/video1 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=3
The attached trace log file:
cat /sys/kernel/debug/tracing/trace > trace_log_v4l-ctl_video1_20220826_01.txt
trace_log_v4l-ctl_video1_20220826_01.txt (8.2 MB)
CHANSEL_FAULT = 0x0000000000000200
kworker/7:0-50 [007] … 126.768012: rtcpu_vinotify_event: tstamp:4426422839 cch:0 vi:1 tag:CHANSEL_FAULT channel:0x23 frame:0 vi_tstamp:141645397920 data:0x0000000000000200
bit 9 PIXEL_SHORT_LINE = 1000000000
CHANSEL_NOMATCH = 0x00000000000003c9
kworker/7:0-50 [007] … 126.768014: rtcpu_vinotify_error: tstamp:4426679895 cch:0 vi:1 tag:CHANSEL_NOMATCH channel:0x04 frame:0 vi_tstamp:141653734784 data:0x00000000000003c9
bit 0 no_match = 1
bit 1-4 CTYPE = 100 = LS (0x4)
bit 5-10 DTYPE = 11110 = NvCsiDataType_YUV422_8 (0x1E)
Also have tag:CHANSEL_SHORT_FRAME message that tell the output size doesn’t as expect.
This MAX9296 setting is working on AGX Xavier, but porting to AGX Orin, and get CHANSEL_SHORT_FRAME.
Does it any parameter need to adjust on AGX Orin?
It’s no any different with Xavier.
Does the PHY Phase of MAX9296 need to adjust for AGX Orin?
Maybe check below Note if the output data rate >= 1.5G.
Skew calibration is required if sensor or deserializer is using DPHY, and the output data rate is > 1.5Gbps.
An initiation deskew signal should be sent by sensor or deserializer to perform the skew calibration. If the deskew signals is not sent, the receiver will stall, and the capture will time out.
You can calculate the output data rate with the following equation:
I had been capture video0 and video1 all OK now, but It can’t capture success every boot up.
The resolution is 1280x720xP120, and output data rate < 1.5Gbps.
Could you give some suggeation?
Then how do you make it work after every boot up?
The video0 and video1 had been capture OK, but it doesn’t work after evey boot up.
So we need your suggesation to improve it on Orin.
Sorry I don’t understand.
How does it capture OK after every boot up?
I capture video0 or video1 OK this time, but it can’t capture video0 or video1 OK next time, and it may be capture OK, and it may be capture fail.
I don’t change any device tree setting, and I just turn off Orin and turn on Orin.
The success rate are 10%.
Looks like it could be the MIPI timing issue.
Please have probe to make sure the settle time.
Should be find the timing by D-PHY spec.
Hi, @ShaneCCC :
We probe the settle time, and the timing look meet the D-PHY spec.
In the other hand, Is the pixel_clk_hz of device tree same on AGX Orin and AGX Xavier platform?
