Problem: The NX system restarts when the trigger mode is waiting for the trigger signal because there is no data.
I have looked at NX Driver system layer implementation in detail, Nano uses VI2 channel, NX uses VI5 channel, Nano does not have this problem. The way the two channels drive the implementation is very different.
Because it is a trigger mode, the application layer does not know when there is a trigger signal, so it polls DQBUF. But the problem is that qdbuf still has the image data (the previous image) when there is no trigger signal. Later in the vi5_fop.c file vi5_capture_dequeue, I put the “vi_capture_status(chan->tegra_vi_channel, CAPTURE_TIMEOUT_MS)” and change “CAPTURE_TIMEOUT_MS ”to -1, problem solved. But a new problem is introduced: once the image is fetched, NX will restart after 2 minutes.
Later, “vi_capture_status” function is blocked,The system doesn’t reboot. But it’s not going to work.
How to solve the hardware trigger mode incompatibility problem?
Have a try modify the QUEUED_BUFFERS to 2 in kernel/nvidia/include/media/mc_common.h
BTW, current driver didn’t verify trigger mode.
The default value of QUEUED_BUFFERS is 4, change it to 2, what’s your reason? Can you tell me your understanding?
Vi5_fops.c corresponds to NX, and Vi2_fops.c corresponds to Nano.vi5_fops.c. I don’t understand why these two files are implemented so differently. And the Nano doesn’t have that problem.
They are different HW so the driver is much different.
Looks like the QUEUED_BUFFERS is for vi2/4_fops.c for vi5_fops.c should check nbuffers and modify it as 1 to return the captured buffer immediately.
*nbuffers = clamp(*nbuffers, CAPTURE_MIN_BUFFERS, CAPTURE_MAX_BUFFERS);
- My driver is based on the V4L2 framework, you mean:
//*nbuffers = clamp(*nbuffers, CAPTURE_MIN_BUFFERS, CAPTURE_MAX_BUFFERS);
*nbuffers=1;
Is it like this?
Yes, modify the ring buffers to 1 to try.
*nBuffers=1 after
video device opening error
*nBuffers must not be less than 2
*nBuffers=2 now turns on the device normally, but it does not resolve the previous issue
Any kernel panic/crash or system hang before restart?
- Before restarting, the kernel crashed and the mouse could not move
It could be the capture failed and sync point stuck cause system hang up and watchdog trigger to reboot.
I put the “wait_for_completion(&capture->capture_resp);” Change to" wait_event_interruptible(); " Solved the system waiting for a trigger signal to restart.
- But the program went backwards
What’s do you mean went backwards?
- Program cannot exit
Do you mean the APP can’t exit or NVCSI/VI driver can’t exit?
Do you send stream_off command before exit?
NVCSI/VI driver can’t exit
I send stream_off command before exit。
It feels like the program has died in “wait event interruptible（）；”