Could the Falcon failure prevent the CPU cache sync/clean after a frame is written into a DMA memory buffer by NVCSI/VI?
I have noticed that the top parts of some frames (0-50 lines of pixel data) appear to be from an earlier frame that was in the same buffer. In my code I am using DMA_BUF_IOCTL_SYNC with DMA_BUF_SYNC_READ | DMA_BUF_SYNC_START before the file write and DMA_BUF_SYNC_READ | DMA_BUF_SYNC_END after the file write, but I’m still getting the glitch in the data written out.
This happens often even using dd or v4l2-ctl to capture raw data to a file. If I increase the number of buffers this problem does not seem to happen the first time a buffer is used, only when buffers are recycled. Example commands:
dd if=/dev/video0 of=testdd.raw bs=1060864 count=512
v4l2-ctl -d /dev/video0 --set-ctrl bypass_mode=0 --stream-mmap 16 --stream-count=512 --stream-to=testv4l2-ctl.raw
One possible cause of this symptom might be that the CPU cache (populated when the earlier frame was saved to the file) is not being invalidated when the new frame is written to the same buffer by NVCSI/VI.
I am ignoring a Falcon error in vi5_fops.c because I have not been able to mask the short first line & short frames from triggering the error that normally dumps the frame. If I was not ignoring this error then the frames would all be rejected, so maybe the logic might skip the CPU cache sync/clean.