8-bit SGBRG and SRGGB media bus formats are missing, as well as the
12-bit grey format. Add them.
Signed-off-by: NMichael Jones <michael.jones@matrix-vision.de>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The xmlto validation produced a number of errors that are now fixed.
Sadly, the DocBook/Makefile still adds --skip-validation to xmlto, so
these errors are missed during a normal compile.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add codes and documentation for the following media bus formats:

- V4L2_MBUS_FMT_SGBRG12_1X12
- V4L2_MBUS_FMT_SGRBG12_1X12
- V4L2_MBUS_FMT_SRGGB12_1X12
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add a userspace API to get, set and enumerate the media format on a
subdev pad.

The format at the output of a subdev usually depends on the format at
its input(s). The try format operation is thus not suitable for probing
format at individual pads, as it can't modify the device state and thus
can't remember the format tried at the input to compute the output
format.

To fix the problem, pass an extra argument to the get/set format
operations to select the 'try' or 'active' format.

The try format is used when probing the subdev. Setting the try format
must not change the device configuration but can store data for later
reuse. Data storage is provided at the file-handle level so applications
probing the subdev concurently won't interfere with each other.

The active format is used when configuring the subdev. It's identical to
the format handled by the usual get/set operations.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NStanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Acked-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>