charles
September 22, 2020, 11:38pm
1
I have a custom sensor and driver which support streaming to memory via v4l2:
v4l2-ctl --set-fmt-video=width=2880,height=1089,pixelformat=RG10 --stream-mmap --set-ctrl=sensor_mode=3,bypass_mode=0 -d /dev/video0
Infrequently the serdes link is lost, but is quickly reacquired. This causes my streaming application to fail hard and I see a warning in my dmesg log. I would like to know what my deserializer driver should be communicating to v4l2 when the link is lost to prevent this from happening and recover gracefully.
------------[ cut here ]------------#2
1 Like
Looks like the driver report the pixelformat have problem.
Looks like the driver report the pixelformat have problem.
charles
September 23, 2020, 8:22pm
5
NOTE: we only observe this issue when our serdes link goes down and comes back up again, which happens infrequently, but we need more robust handling of this event. I’m mostly unsure of how to notify v4l2 that the device is gone
ioctl: VIDIOC_ENUM_FMT
1 Like
I’m still trying to figure this out and made some progress by modifying my deserializer to clean up by removing the serializer and devices behind the serializer in the link down handler. After this the stack is more stable to link lost events, but still not perfect. I’m now seeing:
[ +0.005349] ------------[ cut here ]------------
[ +0.000063] CPU: 0 PID: 7467 Comm: python3 Tainted: G W 4.9.140-tegra #2
[ +0.000014] —[ end trace 97b489f98ac70502 ]—
The following is a trace around when I injected a link down event on the SerDes:
vi-output, tc_u-7493 [000] … 752.023402: tegra_channel_capture_frame: sof:751.913258224
How do you inject a link down event? Is this a v4l2 function call or a tegracam function call?
Neither, it’s out of band via hardware
I have the same type of problem you do so I’m interested in a solution also. It doesn’t seem like there is a graceful mechanism to inform the tegracam architecture or nvargus-daemon through either a Linux kernel call(s) or a userspace monitoring with IPC mechanism. It appears the system assumes a static configuration that will never have errors and cameras are never removed/added after initialization.
1 Like
So, the kernel crash if the serdes disconnect or stopping output data to MIPI?
I’ll only answer for my situation, the kernel does not crash. nvargus-daemon usually crashes or has an issue when the serdes has an issue. For my serdes driver, I have the ability to detect when an error/issue occurs. However, I don’t have anything in the tegracam or v4l2 APIs that I know to do when an error occurs. See Crashing camera stream brings down entire video pipeline for more details.
Is there a way to gracefully notify nvargus-daemon that there is an issue?
Are there improvements to the Linux kernel or nvargus-daemon so that when a single instance of a camera has an issue it does not bring down all of the rest of the camera streams?
I wouldn’t say the kernel crashes, but the vi driver and/or v4l2-core crashes.
For the argus crash current we have implement an error handling sample code in the userAutoExposure app, Please reference to it to add EVENT_TYPE_ERROR to terminal the APP.