Hello,
When the driver was converted from soc_camera emulated support for
V4L2_FIELD_SEQ_TB and V4L2_FIELD_SEQ_BT where added. This was done by
capturing twice to the same VB2 buffer, but at different offsets.
This trend out to be a bad idea and the wrong place to try and emulate
this kind of thing. Further more it is fragile when it comes to things
like suspend/resume and scaling. Just how fragile it was have been made
more apparent when more features where added to the driver for things
the hardware really can do.
If user-space really want to capture things in a SEQ_{TB,BT} fashion
this emulation of capturing twice to the same buffer with a different
offset can be emulated their instead of the kernel, where it always
should have been.
This series removes this emulation in patch 1/5 and then proceeds to
remove a lot of cruft code needed to support it. The primary cleanups in
patch 2/5 - 4/5 revolve around simplifying the VIN internal state
tracking from 5 to 2 states needed to support the emulation.
Finally patch 5/5 removes a hack in the R-Car CSI-2 driver which was
added to support this emulation, and is no longer needed.
I have tested this on Gen2, Gen3 and Gen4 without hitting any
regressions or other issues, other then of course SEQ_{TB,BT} are no
longer enumerated as output formats.
For changelog see individual patches.
Niklas Söderlund (5):
media: rcar-vin: Remove emulated SEQ_{TB,BT}
media: rcar-vin: Remove superfluous suspended state
media: rcar-vin: Remove superfluous starting state
media: rcar-vin: Simplify the shutdown process
media: rcar-csi2: Remove hack to detect NTSC content
drivers/media/platform/renesas/rcar-csi2.c | 8 +-
.../platform/renesas/rcar-vin/rcar-core.c | 6 +-
.../platform/renesas/rcar-vin/rcar-dma.c | 132 ++++--------------
.../platform/renesas/rcar-vin/rcar-v4l2.c | 7 -
.../platform/renesas/rcar-vin/rcar-vin.h | 40 +-----
5 files changed, 33 insertions(+), 160 deletions(-)
--
2.48.1
