vi5 channel timeout control to change default 2.5s

[dmipx]

This commit adds vi5 option to change default timeout of 2500ms for capture channel via v4l controls. We have a bug where capture stalled for 2.5 seconds and recovers automatically. We can reduce that delay as possible workaround but still need to find root cause for stall.

Usage example: Read current timeout (2500 ms default) v4l2-ctl -d /dev/video2 --get-ctrl=capture-timeout Set 500ms timeout: v4l2-ctl -d /dev/video2 --set-ctrl=capture-timeout=500

The timeout value is separate for all video nodes.

Reference ticket: DSO-18070 https://rsjira.intel.com/browse/DSO-18070

[xzhangxa]

I'm fine with the code change, but reducing the timeout value may cause other issue, maybe in some cases the reduced timeout is not long enough so that we may trigger reset too soon. Is there any clue of timing info if we enable all the VI debug logs?

[dmipx]

That is the reason this control is optional and default is still 2500. We have constant timeout issue with direct camera mipi connection so still on path to investigate this. BTW, chan->timeout used in vi4 with 200 default.

[ev-mp]

@d1ntel , one unwanted yet predictale outcome is that this change is not transparent to existing code. I.e user must invoke additional v4l call in order to activate the w/a. What about embedding this data somehow into the I2C ds5_start_stream(... command ? Is it possible to override the default timeout value per stream in DTS ? (like 500 msec for Depth/IR/RGB and 200msec for IMU)

[dmipx]

@d1ntel , one unwanted yet predictale outcome is that this change is not transparent to existing code. I.e user must invoke additional v4l call in order to activate the w/a. What about embedding this data somehow into the I2C ds5_start_stream(... command ? Is it possible to override the default timeout value per stream in DTS ? (like 500 msec for Depth/IR/RGB and 200msec for IMU)

it's complicated, will add dependencies and will break kernel coding rules..

[dmipx]

500 is enough for RGB which slowest one (~460ms), This will be fine for our platform Channel reset is not something harmful for the channel and it not affecting other channels.

[ev-mp]

@dmipx , based on the Validation feedback ,the 500 timeout is incompatible with streaming at 5FPS, as I believe the internal FW setup time in this case exceed this interval. We may still find it usable, specifically for IMU as I see that the responses there are much shorter that Depth/RGB. So let's keep this PR for a while and maybe we'll later use it to modify default timeout for IMU only