According to stateful Codec API the decoder will process all
remaining buffers from before the source change event in
dynamic-resolution-change state and mark the last buffer with
V4L2_BUF_FLAG_LAST.

In Venus case the firmware doesn't mark that last buffer and
some mechanism have to be created in v4l decoder driver.
Fortunately the firmware interface (HFI) claims that the
decoder output buffers will be returned to v4l decoder
driver before it send the insufficient event.

In order to do that we save last queued in the driver capture
buffer in the event_notify and issue flush on output firmware
buffers queue. Once the saved buffer is returned (as a result of
flush command) we mark it as LAST. For all that possible we
extend HFI flush command with one more argument and one more
flush_done HFI driver callback.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Presently the list initialization is done only in
dynamic-resolution-change state, which leads to list corruptions
and use-after-free. Init list_head unconditionally in
vdec_stop_capture called by vb2 stop_streaming without takeing
into account current codec state.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Once the hfi_session_flush is issued by the vdec all queued
buffers to firmware should be returned to the v4l driver. Some
of those buffers are not processed at the time of flush command,
those buffers has filled len zero (no data). Catch that in
buffer_done callback and mark not filled capture buffers with
error state so that client can discard them.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Currently calling venus_helper_buffers_done() will return buffers to
user for both capture and output queues in the same call. This is
wrong because both queues are really separate and calling
stop_streaming on one queue shouldn't return buffers for the other.
Solve this by add a new queue type argument and fix the clients of
the helper function.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The array is not changed in the code, so make it const.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The hfi_destroy function is called too early in remove method. It
destroys a mutex which is used later in the .remove from pmruntime.
Solve the issue by moving hfi_destroy after last usage of the mutex.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

This adds missing mutex_destroy in remove method of venus core driver.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

It was not sufficiently clear how to create and use p_def.
Improve the documentation.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

gpiod_get_value() can return negative values if an error occurs.
In several places this error code was ignored.

Ensure that errors codes are handled correctly throughout the CEC
pin framework and CEC pin drivers.

The return code of the cec_pin_ops read() callback had to be changed
from 'bool' to 'int', which mean the prototype of that callback in the
sun4i drm driver also had to be changed.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

any others capabilities -> any other capabilities
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Commit a8106818 ("media: move CEC USB drivers to a separate directory")
moved drivers/media/usb/{pulse8,rainshadow}-cec to
drivers/media/cec/usb/{rainshadow,pulse8}, but did not adjust the entries
in MAINTAINERS.

Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:

  warning: no file matches F: drivers/media/usb/pulse8-cec/*
  warning: no file matches F: drivers/media/usb/rainshadow-cec/*

Update the MAINTAINERS entries to the new file locations.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The colorspace reported by a video nodes should not be
V4L2_COLORSPACE_DEFAULT. Instead a default colorspace should be picked
by the driver if V4L2_COLORSPACE_DEFAULT is given by userspace to
{G,S,TRY}_FMT.

The colorspace V4L2_COLORSPACE_SRGB is arbitrary chosen as the vimc
default format to report as it's used for most webcams.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

smatch reports wait_status is uninitialized, because smatch cannot assume
the loop body is ever executed.

Clarify the code so that wait_status is retrieved at least once.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

One struct ir_raw_event_ctrl is allocated per raw IR device; reduce the
amount allocated if not all decoders are enabled.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Bail out if registers can not be updated.

Addresses-Coverity-ID: 1461655 ("Code maintainability issues")
Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
Fixes: e6089fec ("media: m88ds3103: Add support for ds3103b demod")
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are some tuners used by a few pure DVB boards that use
internally V4L2 function calls. Due to that, such drivers now
depends on v4l2 core support, and can't be auto-selected
if !VIDEO_V4L2:

	WARNING: unmet direct dependencies detected for DVB_RTL2832_SDR
	  Depends on [n]: MEDIA_SUPPORT [=y] && MEDIA_DIGITAL_TV_SUPPORT [=y] && DVB_CORE [=y] && I2C [=y] && I2C_MUX [=y] && VIDEO_V4L2 [=n] && MEDIA_SDR_SUPPORT [=y] && USB [=y]
	  Selected by [y]:
	  - DVB_USB_RTL28XXU [=y] && USB [=y] && MEDIA_SUPPORT [=y] && MEDIA_USB_SUPPORT [=y] && I2C [=y] && MEDIA_DIGITAL_TV_SUPPORT [=y] && DVB_USB_V2 [=y] && I2C_MUX [=y] && MEDIA_SUBDRV_AUTOSELECT [=y] && MEDIA_SDR_SUPPORT [=y]

	WARNING: unmet direct dependencies detected for MEDIA_TUNER_E4000
	  Depends on [n]: (MEDIA_ANALOG_TV_SUPPORT [=y] || MEDIA_DIGITAL_TV_SUPPORT [=y] || MEDIA_RADIO_SUPPORT [=y] || MEDIA_SDR_SUPPORT [=y]) && MEDIA_SUPPORT [=y] && I2C [=y] && VIDEO_V4L2 [=n]
	  Selected by [y]:
	  - DVB_USB_RTL28XXU [=y] && USB [=y] && MEDIA_SUPPORT [=y] && MEDIA_USB_SUPPORT [=y] && I2C [=y] && MEDIA_DIGITAL_TV_SUPPORT [=y] && DVB_USB_V2 [=y] && I2C_MUX [=y] && MEDIA_SUBDRV_AUTOSELECT [=y]

	WARNING: unmet direct dependencies detected for MEDIA_TUNER_FC2580
	  Depends on [n]: (MEDIA_ANALOG_TV_SUPPORT [=y] || MEDIA_DIGITAL_TV_SUPPORT [=y] || MEDIA_RADIO_SUPPORT [=y] || MEDIA_SDR_SUPPORT [=y]) && MEDIA_SUPPORT [=y] && I2C [=y] && VIDEO_V4L2 [=n]
	  Selected by [y]:
	  - DVB_USB_RTL28XXU [=y] && USB [=y] && MEDIA_SUPPORT [=y] && MEDIA_USB_SUPPORT [=y] && I2C [=y] && MEDIA_DIGITAL_TV_SUPPORT [=y] && DVB_USB_V2 [=y] && I2C_MUX [=y] && MEDIA_SUBDRV_AUTOSELECT [=y]

Detected via randconfig builds.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As detected by a randconfig:

	WARNING: unmet direct dependencies detected for VIDEO_OV7670
	  Depends on [n]: MEDIA_SUPPORT [=y] && I2C [=y] && VIDEO_V4L2 [=n]
	  Selected by [y]:
	  - VIDEO_VIA_CAMERA [=y] && MEDIA_SUPPORT [=y] && MEDIA_PLATFORM_SUPPORT [=y] && V4L_PLATFORM_DRIVERS [=y] && FB_VIA [=y]

There's a missing dependency on VIDEO_V4L2 for VIA_CAMERA.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are three tuners that depend on some functions inside
V4L2 core:

	$ git grep -l -E 'v4l2_[0-9a-zA-Z_]+\(' drivers/media/tuners/
	drivers/media/tuners/e4000.c
	drivers/media/tuners/fc2580.c
	drivers/media/tuners/msi001.c

Make them dependent of VIDEO_V4L2, as otherwise, this would happen:

	on x86_64:
	CONFIG_VIDEO_V4L2=m
	CONFIG_MEDIA_TUNER_E4000=y

	ld: drivers/media/tuners/e4000.o: in function `e4000_remove':
	e4000.c:(.text+0x34): undefined reference to `v4l2_ctrl_handler_free'
	ld: drivers/media/tuners/e4000.o: in function `e4000_probe':
	e4000.c:(.text+0x16c1): undefined reference to `v4l2_ctrl_handler_init_class'
	ld: e4000.c:(.text+0x16eb): undefined reference to `v4l2_ctrl_new_std'
	ld: e4000.c:(.text+0x1731): undefined reference to `v4l2_ctrl_new_std'
	ld: e4000.c:(.text+0x1762): undefined reference to `v4l2_ctrl_auto_cluster'
	ld: e4000.c:(.text+0x178c): undefined reference to `v4l2_ctrl_new_std'
	ld: e4000.c:(.text+0x17d6): undefined reference to `v4l2_ctrl_new_std'
	ld: e4000.c:(.text+0x1804): undefined reference to `v4l2_ctrl_auto_cluster'
	ld: e4000.c:(.text+0x182e): undefined reference to `v4l2_ctrl_new_std'
	ld: e4000.c:(.text+0x1878): undefined reference to `v4l2_ctrl_new_std'
	ld: e4000.c:(.text+0x18a6): undefined reference to `v4l2_ctrl_auto_cluster'
	ld: e4000.c:(.text+0x18d0): undefined reference to `v4l2_ctrl_new_std'
	ld: e4000.c:(.text+0x191a): undefined reference to `v4l2_ctrl_new_std'
	ld: e4000.c:(.text+0x1948): undefined reference to `v4l2_ctrl_auto_cluster'
	ld: e4000.c:(.text+0x1972): undefined reference to `v4l2_ctrl_new_std'
	ld: e4000.c:(.text+0x19a6): undefined reference to `v4l2_ctrl_handler_free'
	ld: e4000.c:(.text+0x1a2a): undefined reference to `v4l2_i2c_subdev_init'
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Some media entry attributes got out of the order after the
bug was split into 3. Also, as reported by Johan, the
Rockchip VPU entry also had their attributes at the wrong
order.

As those entries weren't merged yet upstream, let's reorder
them with:

	./scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS --order
Reported-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

It seems recent merges introduced a couple issues
here, so let's fix them all. Also, reorder Rockchip
video decoder as per parse-maintainers.pl script
and add linux-rockchip mailing list.
Reported-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There was one missing sensor->mbus.type to sensor->mbus_type
conversion which broke the build.

I suspect this was due to a merge conflict that was incorrectly resolved.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

In order to better organize the main admin-guide index,
place the driver-specific indexes on separate files.

This ensures a more consistent numbering at the main index.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Separate the generic documentation from the driver-specific
parts, and use a better title for the documentation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The old cards.rst file doesn't exist anymore. Also, it is not
the right reference there, as it should be pointing to the
bttv-specific cardlist.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

While test drivers is probably something that normal users
won't bother, it doesn't hurt to add them to the card list.

This way, all drivers, except for the ones under staging,
would be listed there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Document the supported radio devices, plus document the
firewire driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The SPI cards are also under the concept of "platform" drivers
as defined at the section introduction.

So, add a SPI card list there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

For completeness, let's add a list of I2C drivers.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There's no reason why to keep platform drivers out of the
card list. Add them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Having a table with a list of all USB drivers seems worth,
and it comes almost for free, as we can just use Kconfig
descriptions (with some adjustments).

So, add a table for that.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Instead of listing "other" PCI card list, just add a list with
the existing drivers (not including sub-drivers).
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The frontend drivers list is incomplete. Update it from
what's there at the Kernel Kconfig files.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The DVB cards.rst file is old and outdated. It also contains
data that are contained on other cardlists. Remove the
duplicated information and split frontends and PCI cards on
separate files.

As all USB cards already have their own card lists, just drop
the old USB data there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

There are several other USB cards. Most of them support just
one device. The only exception is the "pwc" driver. But, as
updates to it are not frequent, let's just place everything
manually into a single file.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The siano driver looks like em28xx, except that its cards
are split on 3 drivers.

Add a card list for it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Add documentation for the remaining dvb-usb boards.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Document the supported dib0300 boards.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Document the cards supported by dib0700 driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Include cardlist documentation for the sub-drivers supported by
dvb-usb-v2 core.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

The cardlist section is important for some boards, because they
may require extra modprobe parameters.

Improve the docs to mention that.

Thanks-to: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for providing me some PCI IDs
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>