hello kamelkhaan,
may I know what’s the camera connections you’d configured.
could you please access Jetson TX2 Series OEM Product Design Guide,
you should refer to [Table 47. CSI Configurations] for details.
thanks
hello JerryChang,
camera1: CSI_0_D (2 lane)
camera2: CSI_1_D (2 lane)
camera3: CSI_2_D , CSI_3_D (4 lane)
The CSI Configurations is OK.
hello kamelkhaan,
could you please share device tree settings for reference?
thanks
The dts is attached.
tripleNode.dtsi (11.8 KB)
according to the formula,
pixel_clk_hz = sensor data rate per lane (Mbps) * number of lanes / bits per pixel
and also referring to your camera device tree.
camera2: 1920x1080, fr=25
camera3: 1920x1080, fr=50
for example,
i2c@1 {
cammod2cmp_b@10 {
mode0 { /* cammod2CMP_MODE_1920x1080_25FPS */
mclk_khz = "24000";
num_lanes = "2";
tegra_sinterface = "serial_b";
phy_mode = "DPHY";
active_w = "1920";
active_h = "1080";
pixel_t = "bayer_rggb";
pix_clk_hz = "307000000";
i2c@2 {
cammod2_c@10 {
mode0 { /* cammod2CMP_MODE_1920x1080_50FPS */
mclk_khz = "24000";
num_lanes = "4";
tegra_sinterface = "serial_c";
phy_mode = "DPHY";
active_w = "1920";
active_h = "1080";
pixel_t = "bayer_rggb";
pix_clk_hz = "307000000";
please review the pixel clock of your camera sensor,
btw, since camera3 have double data-rate of camera2, could you please just double the pix_clk_hz of camera3 to have quick verification.
thanks
We have this frame rate dropping in all node when capture only from one camera. this problem was solved for two other camera by change the pix_clk_hz,but for camera3, this solution does not work.
when set pix_clk_hz = "560800000"; we get this:
hello kamelkhaan,
please also review the settings in tegra-camera-platform{} to calculate max ISO bandwidth.
thanks
hello JerryChang,
we changed the settings in tegra-camera-platform{} , and the same message still appears.
hello kamelkhaan,
please boost the clock rates for testing,
for example,
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
you may also enable VI trace logs for more information,
for example,
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
I did not understand what you mean. please explain more.
hello kamelkhaan,
it’s using sysnodes to boost the clock rate to the maximum,
and also, there’re commands to enable VI tracing log, you should gather the trace log while issue frame drop issue reproduced.
The clock rate boosted to maximum. No change was seen and we still have a drop in frame rate.
output_log (118.0 KB)
hello kamelkhaan,
thanks for sharing VI tracing logs, here’s a bug of your frame-drop issue.
as you can see, it’s SOF and EOF to indicate one success captured frame,
when the issue happened, there’re only odd frames sending to VI engine. (i.e. frame:2275, 2277, 2279…)
for example,
rtcpu_vinotify_event: tstamp:20401385796 tag:CHANSEL_PXL_SOF channel:0x00 frame:2275 vi_tstamp:20401385472 data:0x00000001
rtcpu_vinotify_event: tstamp:20401985880 tag:CHANSEL_PXL_EOF channel:0x00 frame:2275 vi_tstamp:20401985337 data:0x04370002
...
rtcpu_vinotify_event: tstamp:20402635845 tag:CHANSEL_PXL_SOF channel:0x00 frame:2277 vi_tstamp:20402635516 data:0x00000001
rtcpu_vinotify_event: tstamp:20403235918 tag:CHANSEL_PXL_EOF channel:0x00 frame:2277 vi_tstamp:20403235382 data:0x04370002
...
rtcpu_vinotify_event: tstamp:20403885887 tag:CHANSEL_PXL_SOF channel:0x00 frame:2279 vi_tstamp:20403885560 data:0x00000001
rtcpu_vinotify_event: tstamp:20404485962 tag:CHANSEL_PXL_EOF channel:0x00 frame:2279 vi_tstamp:20404485427 data:0x04370002
could you please try the patch here, it has modify the TX2’s VI driver.
Only each of the second frame is captured on the CSI bus - #23 by ShaneCCC
thanks
hello JerryChang,
thanks for your reply.
I added this patch to my source and boost the clock rates to maximum.
the result did not change and the the frame rate dropped.
hello kamelkhaan,
is it only odd frames sending to VI engine for the frame-drop case?
please gather the VI tracing logs for 50-fps and 25-fps scenario to see my assumption correct or not.
thanks
Yes it is only odd frames sending to VI.
Your assumption for 50-fps and 25-fps scenario is correct.
In 50-fps scenario all frames sending to VI.
In 25 fps scenario only odd frames sending to VI if this scenario is repeated, in sometimes only even frames sending ti VI.
Hello,
There is no solution for this problem?