I do already have that work around in place, but I am seeing problems with it. It seems that the vi_notify_wait portion of code after the nvhost_syncpt_wait_timeout_ext() is prone to delays. I haven’t figured out yet whether this is a kernel thread scheduling issue or something else.
I have 4 cameras synced together running at 60 fps. I can see the image is acquired at the same time on all 4 cameras. I used a chasing LED strobe with 100us between LED increment. When I use the timestamp from the RTCPU the values are really close across buffers (+/- 1us). But if I restamp the value in this function I have seen up to 84ms (yes milliseconds) delta between synchronized frames (the content is still synced).
I am thinking that since this code runs in a separate thread for each channel it is being delayed due to thread context switching.
We could probably work with this and just restamp each of the frames with the lowest of all 4 frames, but I am concerned that we are seeing 84ms between them. This means that we sometimes drop multiple frames (because the next acquisition in our code doesn’t start until all 4 frames have captured).