linux_dsm_epyc7002/drivers/media/platform/rcar-vin
Niklas Söderlund 23689ab1ad media: rcar-vin: sync which hardware buffer to start capture from
When starting the VIN capture procedure we are not guaranteed that the
first buffer written to is VnMB1 to which we assigned the first buffer
queued. This is problematic for two reasons. Buffers might not be
dequeued in the same order they where queued for capture. Future
features planed for the VIN driver is support for outputting frames in
SEQ_TB/BT format and to do that it's important that capture starts from
the first buffer slot, VnMB1.

We are guaranteed that capturing always happens in sequence (VnMB1 ->
VnMB2 -> VnMB3 -> VnMB1). So drop up to two frames when starting
capturing so that the driver always returns buffers in the same order
they are queued and prepare for SEQ_TB/BT output.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2018-06-28 07:24:54 -04:00
..
Kconfig media: Remove depends on HAS_DMA in case of platform dependency 2018-05-28 16:17:08 -04:00
Makefile media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver 2018-05-28 13:44:55 -04:00
rcar-core.c media: rcar-vin: add support for MEDIA_BUS_FMT_UYVY8_1X16 2018-05-05 10:27:45 -04:00
rcar-csi2.c media: rcar-csi2: set default format if a unsupported one is requested 2018-05-28 13:46:48 -04:00
rcar-dma.c media: rcar-vin: sync which hardware buffer to start capture from 2018-06-28 07:24:54 -04:00
rcar-v4l2.c media: rcar-vin: fix crop and compose handling for Gen3 2018-05-11 11:39:51 -04:00
rcar-vin.h media: rcar-vin: sync which hardware buffer to start capture from 2018-06-28 07:24:54 -04:00