The VIDIOC_ENUM_FMT ioctl enumerates all formats supported by a video
node. For MC-centric devices, its behaviour has always been ill-defined,
with drivers implementing one of the following behaviours:
- No support for VIDIOC_ENUM_FMT at all
- Enumerating all formats supported by the video node, regardless of the
configuration of the pipeline
- Enumerating formats supported by the video node for the active
configuration of the connected subdevice
The first behaviour is obviously useless for applications. The second
behaviour provides the most information, but doesn't offer a way to find
what formats are compatible with a given pipeline configuration. The
third behaviour fixes that, but with the drawback that applications
can't enumerate all supported formats anymore, and have to modify the
active configuration of the pipeline to enumerate formats.
The situation is messy as none of the implemented behaviours are ideal,
and userspace can't predict what will happen as the behaviour is
driver-specific.
To fix this, let's extend the VIDIOC_ENUM_FMT with a missing capability:
enumerating pixel formats for a given media bus code. The media bus code
is passed through the v4l2_fmtdesc structure in a new mbus_code field
(repurposed from the reserved fields). With this capability in place,
applications can enumerate pixel formats for a given media bus code
without modifying the active configuration of the device.
The current behaviour of the ioctl is preserved when the new mbus_code
field is set to 0, ensuring compatibility with existing userspace. The
API extension is documented as mandatory for MC-centric devices (as
advertised through the V4L2_CAP_IO_MC capability), allowing applications
and compliance tools to easily determine the availability of the
VIDIOC_ENUM_FMT extension.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Replace initialization of static const v4l2_fmtdesc instances that
specify every struct member with designated initializers. This allows
not zeroing the reserved fields explicitly, and will avoid a need to
patch these drivers every time a reserved field is repurposed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a video device capability flag to indicate that its inputs and/or
outputs are controlled by the Media Controller instead of the V4L2 API.
When this flag is set, ioctl for enum inputs and outputs are
automatically enabled and programmed to call a helper function.
Suggested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The log_addrs->log_addr_type[i] value is a u8 which is controlled by
the user and comes from the ioctl. If it's over 31 then that results in
undefined behavior (shift wrapping) and that leads to a Smatch static
checker warning. We already cap the value later so we can silence the
warning just by re-ordering the existing checks.
I think the UBSan checker will also catch this bug at runtime and
generate a warning. But otherwise the bug is harmless.
Fixes: 9881fe0ca1 ("[media] cec: add HDMI CEC framework (adapter)")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
It is spurious to call 'clk_disable_unprepare()' when
'clk_prepare_enable()' has not been called yet.
Re-order the error handling path to avoid it.
Fixes: a4260ea495 ("media: sun4i: Add H3 deinterlace driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
[hverkuil-cisco@xs4all.nl: err_exlusive_rate -> err_exclusive_rate]
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add support for RGB888_*, BGR888_* and GBR888_* media bus formats on
the source pad of debayer subdevices.
Acked-by: Helen Koike <helen.koike@collabora.com>
Co-developed-by: Vitor Massaru Iha <vitor@massaru.org>
Signed-off-by: Vitor Massaru Iha <vitor@massaru.org>
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@protonmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add missing RGB888_*, BGR888_* and GBR888_* media bus codes in the
vimc_pix_map_list. Since there is no GBR24 pixelformat, use the RGB24
pixelformat for MEDIA_BUS_FMT_GBR888_1X24.
Acked-by: Helen Koike <helen.koike@collabora.com>
Co-developed-by: Vitor Massaru Iha <vitor@massaru.org>
Signed-off-by: Vitor Massaru Iha <vitor@massaru.org>
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@protonmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Change vimc_pix_map_list to allow multiple media bus codes to map to the
same pixelformat, making it possible to add media bus codes for which
there are no pixelformat.
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@protonmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
[hverkuil-cisco@xs4all.nl: fix sparse warning: const u32 -> u32]
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
gcc warns about empty array declarations, which we get in this driver
when compile-testing without CONFIG_OF:
drivers/media/platform/ti-vpe/cal.c:2194:34: warning: array 'cal_of_match' assumed to have one element
2194 | static const struct of_device_id cal_of_match[];
Since all users of this driver do need CONFIG_OF anyway, there is no
point in making the array definition conditional to save space, so
just remove the #ifdef and move the array up a little.
Fixes: 343e89a792 ("[media] media: ti-vpe: Add CAL v4l2 camera capture driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
According to latest H/W manual v1.50, the description of channel
number in the VCDT/VCDT2 register is decremented by one.
Therefore, this patch fixes it about comment.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
According to the v4l spec s_fmt must return EBUSY while the
particular queue is streaming. Add such check in encoder and
decoder s_fmt methods.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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>
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>
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: e6089feca4 ("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 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>
The USB_DEVICE() list contain some of the product names, but
some are missing, and others are different than the message
printed during device detection.
Update the comments in order to match what the driver prints.
That makes easier to discover what model matches what physical
device.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Instead of using USB_DEVICE() macro directly, use the
DVB_USB_DEVICE() one, as other dvb-usb-v2 devices.
The usage of the new macro makes cleaner and easier to
parse the supported device names in a way that it would
be easily parseable to generate cardlists.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently the encoder enables the rate control algorithms if the bitrate
control is non-zero. Implement the V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE
and V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE controls to allow userspace to
choose frame-level or macroblock-level rate control updates, or to
explicitly disable rate control. Both controls are initially enabled to
keep the current behavior.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Rather than creating new compound control helpers for each new
type, create one generic function and just create defines on
top.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
If the v4l2_ctrl_g_ctrl*() or __v4l2_ctrl_s_ctrl*() functions
are called for the wrong control type then they call WARN_ON
since that is a driver error. But they still continue, potentially
overwriting data. Change this to return an error (s_ctrl) or 0
(g_ctrl), just to be safe.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Since commit 4957133fe3 ("media: lirc: improve locking"), drivers
do not need to do any of their own locking.
During suspend and resume, no processes are running so no locking is
needed.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Remove vbi_regs_offset from a group of registers that are 888 specific,
include those registers names. Sources used for reference are 885 and 888
datasheets.
Add labels to some undocumented registers.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The CNR is already calculated, so populate DVBv5 CNR stat
during read_status.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add get_rf_strength callback to get RSSI from the tuner. DVBv5
stat cache is updated. get_rf_strength is called by tuner_core
for analog tuners and is also used by some bridge drivers to
obtain RSSI directly from the tuner.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The boards listed below use i2c device drivers and have
tuner_type equal TUNER_ABSENT. This means additional support
is required to enable the analog tuning capability, a case
statement is used to identify these models.
Models with analog tuning enabled:
- CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx (tested)
- CX231XX_BOARD_HAUPPAUGE_935C (tested)
- CX231XX_BOARD_HAUPPAUGE_955Q (tested)
- CX231XX_BOARD_HAUPPAUGE_975 (tested)
- CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD (untested)
The EvroMedia model was added, since it uses the si2157
tuner and the board profile claims it has analog inputs.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Hauppauge QuadHD/1265/5525 boards all use i2c device drivers and
have tuner_type equal TUNER_ABSENT. This means additional support
is required to enable the analog tuning capability, a case
statement is used to identify these models.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Enables the analog tuning frontend for Hauppauge HVR-5525.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Enables the analog tuning frontend for Hauppauge HVR-1265_K4.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add analog tuner frontend to 888 Hauppauge QuadHD boards
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In some debugging cases it is useful to know how long it took
signal lock to happen after tuning. This can help diagnose
line issues.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To detect errors in the tuning operation, this waits up 40ms for operation
completion status. This allows for error detection and prevents issuing
additional commands to the tuner before it is finished.
Tuning typically completes in 20-30ms.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Include set_analog_params, get_frequency, and get_bandwidth.
Tested with NTSC and PAL standards via ch3/4 generator. Other standards
are included, but are untested due to lack of generator.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Getting the Xtal trim property to check if running is less error prone.
Reset if_frequency if state is unknown.
Replaces the previous "garbage check".
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Check error status bit on command execute, if error bit is
set return -EAGAIN. Ignore -EAGAIN in probe during device check.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Enable flags to get status of commands sent to the tuner.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Building those list is a standard procedure described in section
'8.2.4 Decoding process for reference picture lists construction' of
the H264 specification.
We already have 2 drivers needing the same logic (hantro and rkvdec) and
I suspect we will soon have more.
Let's provide generic helpers to create those lists.
Signed-off-by: Boris Brezillon <boris.brezillon@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>
