The timestamp of vi5 capture dqueue is always two frames later than capture enqueue

We currently use AGX xavier for image acquisition, and the software version is Jetpack4.4. We use serdes camera, a total of four, and use the trigger signal for synchronization, we obtained the trigger timestamp through interrupt,and update the image timestamp in the vi5_capture_enqueue function in vi5_fops.c with trigger timestamp . then the timestamp output with the image data by vi5_fops.c/vi5_capture_dqueue. Our image acquisition scheme is v4l2. During use, it is found that there is a large difference between the timestamp after VIDIOC_DQBUF and the timestamp of the image data output by dqbuf that is 140ms. After further investigating, it is found that dqueue is always two frames later than enque in the vi5 driver.

The picture below shows the details:

as you can see ,three different colors represent different three frames of images. The right side of the picture is the kernel log (vi5), where dqueue time is the execution time of the function vi5_capture_dqueue, and enqueue time is the execution time of the function vi5_capture_enqueue; the left of the picture is the log of the APP, where app ts Is the execution time of VIDIOC_DQBUF, ker ts is the timestamp of the image obtained by dqbuf, pic_capture_delay is the difference between those two, it’s about 140ms.
The box in the figure is the timestamp of dqbuf. You can see that those are very close. The underline is the timestamp of the image. You can see that the timestamp output on the left is very close to the enqueue time of the two frames before on the right, which is about 5ms, and every frame It’s all so.
Our current analysis results are: the program first uses VIDIOC_QBUF to enqueue the requested empty buffer, and then starts dqbuf. When dqbuf has not processed all the previous empty buffers, the latest image data has already been enqueueed at this time. Cause a constant delay between enqueue and dqueue, and there is currently no good solution.
May I ask whether our analysis is correct or there is a problem with the configuration of our program in some places.
our program is based on the below file:
yavta.c (29.2 KB)

It’s known behavior due to the ring buffer queues is define as 3 and need to fill it then report back to user space.