On 10/15/19 9:42 AM, Fabio Estevam wrote:
On Tue, Oct 15, 2019 at 1:33 PM Tim Harvey <thar...@gateworks.com> wrote:
Right, because this re-creates the initial issue. Upon any signal lock
you would need to throw away the first few frames. I wish I knew the
proper way to deal with this.
I thought this was handled by drivers/staging/media/imx/imx-media-fim.c
On imx6-sabreauto we do have the input capture pins configured in the
pinctrl entries, but I don't see any driver handling it.
Also, drivers/staging/media/imx/imx-media-fim.c driver has a #ifdef
CONFIG_IMX_GPT_ICAP to deal with the input capture case, but such
config symbol does not exist in mainline.
It seems we still need the input capture support to be able to
measuring frame intervals.
Maybe Steve can shed some light on this?
I submitted the ICAP driver patch quite a while ago, it was ~2 yrs ago I
think. Can't seem to find the link unfortunately.
I'll work on updating the driver and retesting, and try resubmitting again.
Most of the hooks are present in imx-media-fim.c to use the hardware
input capture to measure frame intervals. The only missing piece is the
ICAP driver itself.
The FIM is explained in the imx.rst doc. It is configured and enabled
via v4l2 controls. It will report a v4l2_event to userspace during
streaming when a bad frame interval is detected. The rolling video /
vsync problem caused by the initial corrupt frames from the adv718x
produces bad frame intervals, thus the FIM event can be used to restart
streaming, which will correct vsync (as long as the bad initial frames
are skipped, which is the other piece of this problem that needs an
acceptable solution).
The FIM can still be used now, without input capture support, but it is
marking frame intervals using the monotonic time in the dma completion
irq handler, which is not always accurate due to irq latency, depending
on system load. So this method can sometimes report bad frame interval
events that aren't real.
Steve
