Missing Argus support for low frame resolution cameras

Here some log files, from trace buffer, dmesg and “journalctl -u nvargus-daemon”

isp-issue-trace-buffer-log.txt (94.2 KB)
isp-issue-dmesg-log.txt (75.6 KB)
isp-issue-dmesg-log-human-timestamps.txt (94.2 KB)
isp-issue-nvargus-daemon-journalctl-log.txt (9.5 KB)

As soon as the VC0 stream (device “irs10x0c 9-003d”) is started by v4l2-ctl, the running VC1 stream stops. There are frame start timeouts, continuously reported.

  1. From the trace log looks like after launch second camera NVCSI/VI didn’t receive any validate data from MIPI bus.
    Could you probe the MIPI signal to check?

  2. Looks like the VI mode(v4l2-ctl) capture failed and try to recovery loops. Could you try to modify the vi5_fops.c/csi5_fops.c/csi.c to remove the recovery to check if argus still failed.

  1. I’ve double checked and already verified that the second camera generates valid MIPI signal, before opening this forum thread. The FPD-Link III deserializer for VC0 camera detects valid frames (verified via register dump of LINE_COUNT_* and LINE_LEN_* registers) and the deserializer also detects valid data on the appropriate RX port. I’ve also measured the clock signal on the deserializer clock lane, the clock signal is still present after I disable frozen 1280x800 (VC1) stream (MIPI clock is still okay after killing blocked gst-launch-1.0). Only if I interrupt v4l2-ctl for VC0 stream, the clock signal stops. So, I’m sure that the MIPI signal from deserializer is valid.
    Another observation: if I start VC0 stream by v4l2-ctl first and then start the VC1 stream with gst-launch-1.0, then both streams are running and I get valid camera data:
# v4l2-ctl -d /dev/video1  -c bypass_mode=0 --stream-mmap --stream-count=1000
<<<<<<<<<<<<<<<<<<<<<< 20.01 fps
<<<<<<<<<<<<<<<<<<<< 20.01 fps
<<<<<<<<<<<<<<<<<<<< 20.01 fps
...

# gst-launch-1.0 -e nvarguscamerasrc sensor-id=1 "video/x-raw(memory:NVMM),width=1280,height=800,format=NV12,framerate=20/1" ! nvv4l2h264enc bitrate=8000000 profile=2 ! h264parse ! rtph264pay mtu=1400 ! udpsink host=192.168.10.40 port=5000 sync=false async=false
Setting pipeline to PAUSED ...
Failed to query video capabilities: Inappropriate ioctl for device
Opening in BLOCKING MODE 
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
NvMMLiteOpen : Block : BlockType = 4 
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4 
H264: Profile = 77, Level = 0 

(gst-launch-1.0:4766): GStreamer-CRITICAL **: 23:08:31.354: gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size' failed

(gst-launch-1.0:4766): GStreamer-CRITICAL **: 23:08:31.402: gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size' failed

(gst-launch-1.0:4766): GStreamer-CRITICAL **: 23:08:31.451: gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size' failed
...

Now, if I stop the VC1 stream (by killing gst-launch-1.0), then the VC0 stream freezes and in dmesg log I see:

...
[ 2926.038371] video4linux video1: vi_notify_wait: vi4 got SOF syncpt buf[ffffffc0e2c1dc00]
[ 2926.088568] video4linux video1: vi_notify_wait: vi4 got SOF syncpt buf[ffffffc0e2c1c800]
[ 2926.155912] ov9782d3 10-0060: camera_common_dpd_enable: csi 0
[ 2926.155917] ov9782d3 10-0060: camera_common_dpd_enable: csi 1
[ 2926.155921] ov9782d3 10-0060: camera_common_mclk_disable: disable MCLK
[ 2928.089116] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 2928.095486] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[ 2928.105176] nvcsi 150c0000.nvcsi: settle time reading from props
[ 2928.105181] nvcsi 150c0000.nvcsi: discontinuous_clk = 1 reading from props
[ 2928.105184] nvcsi 150c0000.nvcsi: settle time reading from props
[ 2928.105223] nvcsi 150c0000.nvcsi: settle time reading from props
[ 2928.105225] nvcsi 150c0000.nvcsi: discontinuous_clk = 1 reading from props
[ 2928.105227] nvcsi 150c0000.nvcsi: settle time reading from props
[ 2928.116593] tegra-vi4 15700000.vi: Create Surface with imgW=224, imgH=173, memFmt=32
[ 2930.137152] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11
[ 2930.143516] tegra-vi4 15700000.vi: tegra_channel_error_recovery: attempting to reset the capture channel
[ 2930.153249] nvcsi 150c0000.nvcsi: settle time reading from props
[ 2930.153253] nvcsi 150c0000.nvcsi: discontinuous_clk = 1 reading from props
[ 2930.153255] nvcsi 150c0000.nvcsi: settle time reading from props
[ 2930.153293] nvcsi 150c0000.nvcsi: settle time reading from props
[ 2930.153296] nvcsi 150c0000.nvcsi: discontinuous_clk = 1 reading from props
[ 2930.153298] nvcsi 150c0000.nvcsi: settle time reading from props
[ 2930.164650] tegra-vi4 15700000.vi: Create Surface with imgW=224, imgH=173, memFmt=32
[ 2932.185202] tegra-vi4 15700000.vi: PXL_SOF syncpt timeout! err = -11

If I start VC0 stream first (v4l2-ctl), then start VC1 stream (gst-launch-1.0), both streams are running.
Now if I stop VC0 stream, the VC1 stream freezes and dmesg log shows different behaviour:
isp-issue-dmesg-log_v4l2-ctl-stopped_gst-launch-1.0-stream-frozen.txt (130.0 KB)

  1. For Jetson TX2 the recovery is in vi4_fops.c. I’ve isolated the recovery by patching VI driver with:
diff --git a/nvidia/drivers/media/platform/tegra/camera/vi/vi4_fops.c b/nvidia/drivers/media/platform/tegra/camera/vi/vi4_fops.c
index 97a81d25562e..e03d1574a712 100644
--- a/nvidia/drivers/media/platform/tegra/camera/vi/vi4_fops.c
+++ b/nvidia/drivers/media/platform/tegra/camera/vi/vi4_fops.c
@@ -889,6 +889,8 @@ static void tegra_channel_error_recovery(struct tegra_channel *chan)
 
        dev_warn(chan->vi->dev,
                "%s: attempting to reset the capture channel\n", __func__);
+       dev_warn(chan->vi->dev, "%s: SKIPPED...\n", __func__);
+       return;
 
        /* Find connected NvCsi stream subdev */
        csi_subdev = find_linked_csi_subdev(csi, chan);

The behaviour didn’t change, the new log with modified VI driver is attached:
isp-issue-dmesg-log_tegra_channel_error_recovery_disabled.txt (55.9 KB)

Please note that for the above logs I’ve also increased the timeout in VI driver by patch:

diff --git a/nvidia/drivers/media/platform/tegra/camera/vi/vi4_fops.c b/nvidia/drivers/media/platform/tegra/camera/vi/vi4_fops.c
index e395089e694b..5357b0d023b9 100644
--- a/nvidia/drivers/media/platform/tegra/camera/vi/vi4_fops.c
+++ b/nvidia/drivers/media/platform/tegra/camera/vi/vi4_fops.c
@@ -1097,7 +1097,7 @@ static int vi4_channel_start_streaming(struct vb2_queue *vq, u32 count)
        }
 
        chan->sequence = 0;
-       chan->timeout = msecs_to_jiffies(200);
+       chan->timeout = msecs_to_jiffies(2000);
        if (!chan->low_latency)
                tegra_channel_init_ring_buffer(chan);

For your experience it could be the sensor driver not implement well to impact each VC.
You may need to narrow down which driver function cause the freeze like power_on/power_on/_start_streaming …

Well, if it would be the sensor driver causing issues here, then I would expect that the same problem will appear when starting/stopping both VC0/VC1 streams by v4l2-ctl. But with v4l2-ctl it works in any order.

I.e. I can start VC0 stream with v4l2-ctl and let it running for longer time:

# v4l2-ctl -d /dev/video1 -c bypass_mode=0 --stream-mmap --stream-count=100000
<<<<<<<<<<<<<<<<<<<<<< 20.01 fps
<<<<<<<<<<<<<<<<<<<< 20.01 fps
<<<<<<<<<<<<<<<<<<<< 20.01 fps
...

and while this VC0 stream is running, I can start and stop VC1 stream repeatedly, and this does not affect the active VC0 stream:

# v4l2-ctl -d /dev/video0 -c bypass_mode=0 --stream-mmap --stream-count=100000
<<<<<<<<<<<<<<<<<<<<<^C
# v4l2-ctl -d /dev/video0 -c bypass_mode=0 --stream-mmap --stream-count=100000
<<<<<<<<<<<<<<<<<<<<<< 20.12 fps
<<<<<<<<<<<<<<<<<<<< 20.12 fps
<<<<<<<<<<<<<<^C
# v4l2-ctl -d /dev/video0 -c bypass_mode=0 --stream-mmap --stream-count=100000
<<<<<<<<<<<<<<<<<<<^C
# v4l2-ctl -d /dev/video0 -c bypass_mode=0 --stream-mmap --stream-count=100000
<<<<<<<<<<<<<<<<<<<<<< 20.12 fps
<^C
# v4l2-ctl -d /dev/video0 -c bypass_mode=0 --stream-mmap --stream-count=100000
<<<<<<<<<<<<<<<<<<<<<^C

Or the other way around. If the VC1 stream is running, I can start/stop VC0 stream and it does not affect the running VC1 stream. Only if ISP/libargus is involved, there is a freezy.

OK, but the the clock signal on the deserializer clock lane was control by sensor driver.

Can you provide nvargus-daemon and libargus source so that we can debug this issue further? It is really a show stopper for us. Our product development is totally blocked by this issue.

Sorry, we don’t provide the source code for the libnvargus but you can download the daemon source code from download center. Also you may need apply the patch from below link.

https://developer.nvidia.com/embedded/L4T/r32_Release_v4.4/r32_Release_v4.4-GMC3/T186/Tegra186_Linux_R32.4.4_aarch64.tbz2

https://elinux.org/Jetson/L4T/r32.3.x_patches

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.