[PATCH v4 13/36] [media] v4l2: add a frame timeout event

[Steve Longerbeam]

On 03/05/2017 02:41 PM, Russell King - ARM Linux wrote:
> On Sat, Mar 04, 2017 at 04:37:43PM -0800, Steve Longerbeam wrote:
>>
>>
>> On 03/04/2017 02:56 AM, Sakari Ailus wrote:
>>> That's a bit of a special situation --- still there are alike conditions on
>>> existing hardware. You should return the buffers to the user with the ERROR
>>> flag set --- or return -EIO from VIDIOC_DQBUF, if the condition will
>>> persist:
>>
>> On i.MX an EOF timeout is not recoverable without a stream restart, so
>> I decided to call vb2_queue_error() when the timeout occurs (instead
>> of sending an event). The user will then get -EIO when it attempts to
>> queue or dequeue further buffers.
>
> I'm not sure that statement is entirely accurate.  With the IMX219
> camera, I _could_ (with previous iterations of the iMX capture code)
> stop it streaming, wait a while, and restart it, and everything
> continues to work.

Hi Russell, did you see the "EOF timeout" kernel error message when you
stopped the IMX219 from streaming? Only a "EOF timeout" message
indicates the unrecoverable case.


>
> Are you sure that the problem you have here is caused by the iMX6
> rather than the ADV718x CVBS decoder (your initial description said
> it was the decoder.)

Actually yes I did say it was the adv718x, but in fact I doubt the
adv718x has abruptly stopped data transmission on the bt.656 bus.
I actually suspect the IPU, specifically the CSI. In our experience
the CSI is rather sensitive to glitches and/or truncated frames on the
bt.656 bus and can easily loose vertical sync, and/or lock-up.

Steve

>
> If it _is_ the decoder that's going wrong, that doesn't justify
> cripping the rest of the driver for one instance of broken hardware
> that _might_ be attached to it.
>