I can confirm that the 1 second (actually 1.5 second or was it 1.5 FPS here?) timeout is quite irritating. At first I was wondering if there is something wrong with our driver when configured for low FPS (either due to lane count/high resolution/bitrate limitation) when I noticed that I could purposely trigger the timeouts with adding extra v-blank to an otherwise working system. This is one of the “features” that will haunt you one you start doing serious stuff with nvidia products.
Our use case would be to start multiple clients - prepare the streaming/processing/encoding path, with the sensors started in a later stage. It is impossible to guarantee that all the nodes will boot within 1 sec window to avoid these timeouts happening. Thus we have a workaround to start the sensors in advance, disable power management to keep them running, and the clients are started later. The drawback is, that each stream has a fixed offset from other streams and frames have to be dropped, e.g. based on a startup calibration with modifying black level on all sensors in sync or with an hardware embedded timestamp.
The reason for larger than 1 second timeout for us would be:
- support for low FPS because some applications just want to do regular snapshots
- support for long exposures without any special handling
- easy synchronous multi-sensor operation
But the ultimate solution would be to have no timeout occurring at all - because once the MIPI CSI encounters a timeout, it will not recover with another frame. That is still an unsolved issue and the CSI on Tegra is rather a toy than a hardened production quality thing, resilient from random signal integrity issues.