Move away from the deprecated API.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Move away from the deprecated API and make use of the fact that
unregistering devices is NULL- and ERR_PTR-safe.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Convert Rockchip VPU (Hantro IP block) codec driver documentation to
json-schema.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Refactor how S_FMT and TRY_FMT are handled, and also make sure
internal initial format and format reset are done properly.

The latter is achieved by making sure the same hantro_{set,try}_fmt
helpers are called on all paths that set the format (which is
part of the driver state).

This commit removes the following v4l2-compliance warnings:

test VIDIOC_G_FMT: OK
	fail: v4l2-test-formats.cpp(711): Video Capture Multiplanar: TRY_FMT(G_FMT) != G_FMT
test VIDIOC_TRY_FMT: FAIL
	fail: v4l2-test-formats.cpp(1116): Video Capture Multiplanar: S_FMT(G_FMT) != G_FMT
test VIDIOC_S_FMT: FAIL
Reported-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Move the extra bytes calculation that are needed for H264
motion vector to a helper. This is just a cosmetic cleanup.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Since now .buf_prepare takes care of setting the
buffer payload size, we can get rid of this,
at least for decoders.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Let the core sort out the nuances of returning buffers
to userspace, by using the v4l2_m2m_buf_done_and_job_finish
helper.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Buffers' zeroth plane payload size is calculated at format
negotiation time, and so it can be set in .buf_prepare.

Keep in mind that, to make this change easier, hantro_buf_prepare
is refactored, using the cedrus driver as reference. This results
in cleaner code as byproduct.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

When the request API is used, typically an OUTPUT (src) buffer
will be part of a request. A userspace process will be typically
blocked, waiting on the request file descriptor.

Returning the OUTPUT (src) buffer will wake-up such processes,
who will immediately attempt to dequeue the CAPTURE buffer,
only to find it's still unavailable.

Therefore, change v4l2_m2m_buf_done_and_job_finish returning
the CAPTURE (dst) buffer first, to avoid signalling the request
file descriptor prematurely, i.e. before the CAPTURE buffer is done.

When the request API is not used, this change should have
no impact.
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Changing from "depends on" to "select" may cause some
side-effects. This patch is not ready to be merged yet,
as it requires some adjustments.

So, let's revert it.

This reverts commit a3b91d8b.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Now that everything got moved, we can get rid of the
old media directory.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are some uAPI stuff that are driver-specific. Add them
to the main media uAPI body.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Those documents don't really describe the driver API.

Instead, they contain development-specific information.

Yet, as the main index file describes the content of it as:

	"how specific kernel subsystems work
	 from the point of view of a kernel developer"

It seems to be the better fit.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Most of the driver-specific documentation is meant to help
users of the media subsystem.

Move them to the admin-guide.

It should be noticed, however, that several of those files
are outdated and will require further work in order to make
them useful again.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This file gives a hint about how fourcc should be named.

It is on a very weird place, as such kind of thing belongs to the
uAPI guide.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

All those documents describe the media driver API. So, move
them to the right place within the Kernel documentation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Since 2017, there is an space reserved for userspace API,
created by changeset 1d596dee ("docs: Create a user-space API guide").

As the media subsystem was one of the first subsystems to use
Sphinx, until this patch, we were keeping things on a separate
place.

Let's just use the new location, as having all uAPI altogether
will likely make things easier for developers.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This file contains both driver develompent documentation and
userspace API.

Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This file contains both driver develompent documentation and
userspace API.

Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This file contains both driver develompent documentation and
userspace API.

Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This file contains both driver develompent documentation and
userspace API.

Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This file contains both driver develompent documentation and
userspace API.

Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are two places inside this file that points to the
cx2341x documentation, with was split into two. Looking
at changeset dcc0ef88
("V4L/DVB (10442): cx18: Fixes for enforcing when Encoder Raw VBI params can be set")
with added those comments, it was originally pointing to:

	Documentation/video4linux/cx2341x/fw-encoder-api.txt

Well, the firmware details went to
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This file contains both driver develompent documentation
(basically, firmware documentation) and IVTV-specific
documentation about VBI and raw formats, focused on uAPI
development.

Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This file contains both	admin and development stuff. Split on
two, as	they're	usually	read by	different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This file contains both admin and development stuff. Split on
two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The vimc driver has some kerneldoc markups, plus admin info.
Split it into two files.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Instead of placing both info from admin PoV and uAPI at the
same place, split into two separate documents.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The ci.rst file contains two parts: the first one describing
how to use the CA high level interface; the second one with
uAPI internals.

Split this on two separate files, adding the uAPI bits
to the DVB ca.rst configuration.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

In order to be able to better organize the subsystem, split the
cpia2 information on two files: one user-facing and another one
from Kernel development PoV.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As the entire soc_camera driver is on staging to be removed
soon, let's place there its documentation too.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There's a table on this file, with aren't using the ReST
markups. Fix that.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

While making the menu invisible seemed a good idea, there's
a drawback: when the menu is not visible, it is not parsing
the "default" dependency.

So, instead, let's just avoid the items at the menu to be
prompted, by using the "prompt ... if" construction.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Right now, there are I2C drivers that don't depend on
camera support before and after those.

Move the camera support drivers to the end, and add
a notice at the "endif", in order to make easier to
maintain and to avoid adding extra dependencies at
the other i2c/*/Kconfig files.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

After this change, the menu is displayed like above.

1) When filtering is not active:

    --- Multimedia support
        [ ]   Filter devices by their types
        [*]   Autoselect ancillary drivers (tuners, sensors, i2c, spi, frontends)
              Media core support  --->
              Video4Linux options  --->
              Media controller options  --->
              Digital TV options  --->
              HDMI CEC options  --->
              Media drivers  --->

2) When filtering is active:

    --- Multimedia support
        [*]   Filter devices by their types
        [*]   Autoselect ancillary drivers (tuners, sensors, i2c, spi, frontends)
              Media device types  --->
              Video4Linux options  --->
              Media controller options  --->
              Digital TV options  --->
              HDMI CEC options  --->
              Media drivers  --->

The per-API menu will only be displayed if the corresponding
core support is enabled.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Advanced and embedded users know what to do, so, by default,
they will likely want to be able to open the entire set of
Kconfig media options.

Normal "poor" users usually needs more help when setting
stuff, so let's open an more simplified version to them by
default.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Let's place the sub-driver-autoselection option just below
the device filtering one, as it also controls a filter menu,
with is not even visible if !EXPERT && !EMBEDDED.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

That should make easier for people setting the media
subsystem config options, as they'll be split by the
type of functionality that will be enabled.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Let's place the main API selections at the media/Kconfig file,
as this way we can better organize things.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This option is part of V4L2 API extra functionality set.
Move it to be at the v4l2-core/Kconfig, where it belongs,
cleaning the main Kconfig file.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>