hello channinglan,
I don’t see SHORT_FRAME messages.
anyways…
could you please try disable sensor controls, such as gain/exposure/frame-length settings.
since you’ve mentioned it works occasionally, it doubts different register settings writing to sensor cause such failure.
My video source is FPGA
So no any gain/exposure/frame-length settings …
I don’t need to control the FPGA, the data will be automatically output when the power is turned on, and it can be displayed normally in r32.6.1 (although there is a SHORT_FRAME)… But it is difficult to display normally in r35.3.1. I would like to ask the difference between the two versions ??
the major difference is kernel version. as you can see… Camera Driver Porting, it’s now using kernel-5.10
you may check VI-5 driver, please configure a higher timeout value. #define CAPTURE_TIMEOUT_MS 2500
and… for your video source, is it possible to trigger a reset when you execute v4l pipeline?
I can’t control video soures (FPGA) …
modify CAPTURE_TIMEOUT_MS to 5500 … same error
v4l2-ctl-4097 [003] .... 1285.603084: camera_common_s_power: status : 0x1
v4l2-ctl-4097 [003] .... 1285.603119: tegra_channel_set_power: 13e10000.host1x:nvcsi@15a00000- : 0x1
v4l2-ctl-4097 [003] .... 1285.603122: csi_s_power: enable : 0x1
v4l2-ctl-4097 [003] .... 1285.603687: tegra_channel_capture_setup: vnc_id 0 W 400 H 400 fmt 9
v4l2-ctl-4097 [001] .... 1285.616384: tegra_channel_set_stream: enable : 0x1
v4l2-ctl-4097 [001] .... 1285.617865: tegra_channel_set_stream: 13e10000.host1x:nvcsi@15a00000- : 0x1
v4l2-ctl-4097 [001] .... 1285.617868: csi_s_stream: enable : 0x1
v4l2-ctl-4097 [001] .... 1285.618449: tegra_channel_set_stream: gen3 0-001e : 0x1
kworker/3:0-4003 [003] .... 1285.627927: rtcpu_string: tstamp:41020230581 id:0x04010000 str:"VM0 activating."
kworker/3:0-4003 [003] .... 1285.627932: rtcpu_vinotify_event: tstamp:41020665056 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1312651705184 data:0xcd9ce50010000000
kworker/3:0-4003 [003] .... 1285.627932: rtcpu_vinotify_event: tstamp:41020665196 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1312651710688 data:0x0000000031000001
kworker/3:0-4003 [003] .... 1285.627933: rtcpu_vinotify_event: tstamp:41020665350 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1312651769536 data:0xcd9ce20010000000
kworker/3:0-4003 [003] .... 1285.627933: rtcpu_vinotify_event: tstamp:41020665485 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1312651775104 data:0x0000000031000002
vi-output, gen3-4099 [001] .... 1288.357268: tegra_channel_capture_setup: vnc_id 0 W 400 H 400 fmt 9
kworker/3:0-4003 [003] .... 1288.371778: rtcpu_vinotify_event: tstamp:41106181206 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1315395718656 data:0xcd9ce50010000000
kworker/3:0-4003 [003] .... 1288.371781: rtcpu_vinotify_event: tstamp:41106181346 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1315395724192 data:0x0000000031000001
kworker/3:0-4003 [003] .... 1288.371782: rtcpu_vinotify_event: tstamp:41106181500 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1315395778784 data:0xcd9ce20010000000
kworker/3:0-4003 [003] .... 1288.371782: rtcpu_vinotify_event: tstamp:41106181635 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:1315395784352 data:0x0000000031000002
vi-output, gen
[ 116.675272] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 116.675690] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 116.675865] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 116.676120] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 116.676284] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 116.676770] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 122.328327] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 5500 ms
[ 122.328583] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 122.329725] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 122.329916] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 122.330167] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 122.330334] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 122.330785] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
Transplant r32.6.1 to r35.3.1, modify DTS … same driver, same hardware, don’t understand why r35.3.1 can’t display
r3261_tegra194-camera-gen3.dtsi (19.4 KB)
r3531_tegra194-camera-gen3.dtsi (20.3 KB)
hello channinglan,
it seems something wrong for your 2nd camera device tree setting.
please update tegra_sinterface accordingly.
for example,
gen3_b@2e { //0x2e take any address
mode0 {
mclk_khz = "37125";
num_lanes = "4";
tegra_sinterface = "serial_a"; <== it should be serial_b
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
ligen3_gen3_out1: endpoint {
port-index = <2>;
this looks incorrect. csi_pixel_bit_depth = "24"; and dynamic_pixel_bit_depth = "16";.
it’s Pixel bit depth [bit] for csi_pixel_bit_depth, and since it’s SDR sensor, you should have dynamic_pixel_bit_depth=csi_pixel_bit_depth.
this should be minor, please update position property as rear and front for your 2-cam in the system,
for example,
modules {
module0 {
status = "okay";
badge = "gen3_top_i2c0_b";
position = "front";
module1 {
status = "okay";
badge = "gen3_top_i2c1_b";
position = "centerleft"; <== to revise this as rear
1.my source is FPGA not SDR sensor
2.modify dynamic_pixel_bit_depth = "24"
and remove 2-cam
… same error
tegra194-camera-gen3_1ch.dtsi (20.6 KB)
The successfully displayed message is as follows
but the chances of a successful display are very low
20230531_r3531_400_ok.log (141.2 KB)
I see a similar wrong solution
(4) according to VI tracing logs… it’s driver side kept waiting for sensor frames. there’s no sensor related signaling, such as SOF, EOF…etc.
since you’ve image data will always be output, you might try issue a software reset (on the SerDes) to alignment with software. this reset event should trigger before s_stream() for capture engine waiting 1st start-of-frame of the MIPI signaling.
How to software reset ???
hello channinglan,
this reset is done by sender side. i.e. your FPGA device.
if you can’t control video sources (FPGA) for software reset, how about toggle the power supply off/on then capture the frames.
I just don’t understand that it can be displayed normally without any control in r32.6.1, why it needs more control in r35.3.1
hello channinglan,
>>Q1
as mentioned, there’s major kernel version update.
it’s kind of often seen issues when system update to new major release version.
>>Q2
it may due to CSI configurations.
may I know what’s your step in details to have the chances of a successful display?
The steps to success and failure are exactly the same,
Execute command after power on
gst-launch-1.0 v4l2src device=/dev/video0 ! video/x-raw, format=(string)BGRA, width=(int)400, height=(int)400 ! videoconvert ! xvimagesink -ev
hello channinglan,
it should be minor,
please have a try for sending an EoS (with -e options) when shutdown the pipeline.
for example,
gst-launch-1.0 -e v4l2src device=/dev/video0 ! video/x-raw, format=(string)BGRA, width=(int)400, height=(int)400 ! videoconvert ! xvimagesink -ev
please have a try for sending an EoS (with `-e` options) when shutdown the pipeline. ?
It will fail for the first time after starting up. Only after restarting the test for many times will there be a low probability that the screen can be successfully displayed. If it is successfully turned on, then close the program and then turn on the second time, it will fail.
… same error
hello channinglan,
let me double confirm that…
(1) you’re not sending a reset for your FPGA, but keep retrying this gst pipeline to have low probability to fetch the stream.
(2) may I know what’s the timeout property you’ve configured now?
(3) had you try below commands to boost the clocks to ignore system level config.
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
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/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
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate
please give it a try with below kernel patch,
for example,
diff --git a/drivers/platform/tegra/rtcpu/device-group.c b/drivers/platform/tegra/rtcpu/device-group.c
index fadae24d9..4dbd10edb 100644
--- a/drivers/platform/tegra/rtcpu/device-group.c
+++ b/drivers/platform/tegra/rtcpu/device-group.c
@@ -51,7 +51,7 @@ static int get_grouped_device(struct camrtc_device_group *grp,
if (pdev == NULL) {
dev_warn(dev, "%s[%u] node has no device\n", name, index);
- return 0;
+ return -EPROBE_DEFER;
}
still have this error!
v4l2src0:src-3179 [001] .... 186.299540: tegra_channel_set_power: 13e10000.host1x:nvcsi@15a00000- : 0x1
v4l2src0:src-3179 [001] .... 186.299544: csi_s_power: enable : 0x1
v4l2src0:src-3179 [001] .... 186.300122: tegra_channel_capture_setup: vnc_id 0 W 400 H 400 fmt 9
v4l2src0:src-3179 [002] .... 186.310547: tegra_channel_set_stream: enable : 0x1
v4l2src0:src-3179 [003] .... 186.315379: tegra_channel_set_stream: 13e10000.host1x:nvcsi@15a00000- : 0x1
v4l2src0:src-3179 [003] .... 186.315383: csi_s_stream: enable : 0x1
v4l2src0:src-3179 [003] .... 186.315824: tegra_channel_set_stream: gen3 0-001e : 0x1
kworker/3:6-159 [003] .... 186.341956: rtcpu_string: tstamp:6610085483 id:0x04010000 str:"VM0 activating."
kworker/3:6-159 [003] .... 186.341960: rtcpu_vinotify_event: tstamp:6610533572 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:211527547200 data:0xcd9ce50010000000
kworker/3:6-159 [003] .... 186.341961: rtcpu_vinotify_event: tstamp:6610533712 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:211527552672 data:0x0000000031000001
kworker/3:6-159 [003] .... 186.341962: rtcpu_vinotify_event: tstamp:6610533866 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:211527607104 data:0xcd9ce20010000000
kworker/3:6-159 [003] .... 186.341962: rtcpu_vinotify_event: tstamp:6610534001 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:211527612672 data:0x0000000031000002
[ 186.315932] [TEGRA-GEN3]gen3_start_streaming:
[ 186.315936] gen3 0-001e: gen3_start_streaming: Mode ID : 0
[ 191.965587] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 5500 ms
[ 191.965841] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 191.966354] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 191.966555] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 191.966754] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 191.966898] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 191.967362] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 197.601211] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 5500 ms
[ 197.601418] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 197.602304] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 197.602453] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 197.602657] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 197.602816] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 197.603318] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 197.603591] [TEGRA-V4L2]v4l2sd_stream:enable 0x0
[ 197.603599] [TEGRA-GEN3]gen3_stop_streaming:
hello channinglan,
let’s try putting some delay from VI driver side before FPGA power-on for sending frames.
it’s sensor devices should be stream-on after the tegra_channel_set_stream() is complete,
for example,
$public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/vi/channel.c
int tegra_channel_set_stream(struct tegra_channel *chan, bool on)
{
...
//to add schedule_delayed_work() to wait for 400ms here..
if (ret == 0)
atomic_set(&chan->is_streaming, on);
It doesn’t seem to work!
[ 176.284452] [TEGRA-GEN3]gen3_start_streaming:
[ 176.284456] gen3 0-001e: gen3_start_streaming: Mode ID : 0
[ 176.284460] [TEGRA-CHANNEL]tegra_channel_set_stream:dd1
[ 176.284466] [TEGRA-CHANNEL]tegra_channel_set_stream:dd2
[ 176.699648] defense_work_handler function.
[ 181.979394] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 5500 ms
[ 181.979606] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 181.980296] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 181.980445] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 181.980637] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 181.980780] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 0
[ 181.981292] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture
There is a situation found that the success rate of the first test after each power failure is higher…
Seems to be related to what you said earlier
this reset is done by sender side. i.e. your FPGA device.
if you can’t control video sources (FPGA) for software reset, how about toggle the power supply off/on then capture the frames.