- 30 Sep, 2021 40 commits
-
-
Alexandre Courbot authored
Firmwares for decoders newer than MT8173 will include an ABI version number in their initialization ack message. Add the capacity to manage it and make initialization fail if the firmware ABI is of a version that we don't support. For MT8173, this ABI version field does not exist ; thus ignore it on this chip. There should only be one firmware version available for it anyway. Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Yunfei Dong authored
We are planning to add support for stateless decoders to this driver. Part of the driver will be shared between stateful and stateless codecs, but a few ops need to be specialized for both. Extract the stateful part of the driver and move it into its own file, accessible through ops that the common driver parts can call. This patch only moves code around and introduces a set of abstractions ; the behavior of the driver should not be changed in any way. Changes to code styling has been done to accommodate 'checkpatch.pl --strict'. [acourbot: refactor, cleanup and split] [tzungbi: fix errors from 'checkpatch.pl --strict'] Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Co-developed-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Alexandre Courbot authored
The V4L2 encoder specification requires encoders to support the V4L2_ENC_CMD_START and V4L2_ENC_CMD_STOP commands. Add support for these to the mtk-vcodec encoder by reusing the same flush buffer as used by the decoder driver. [hsinyi: fix double-free issue if flush buffer was not dequeued by the time streamoff is called] Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Alexandre Courbot authored
The flush buffer is a special buffer that tells the decoder driver to send an empty CAPTURE frame to the client with V4L2_BUF_FLAG_LAST set. We need similar functionality for the encoder ; however currently the flush buffer depends on decoder-specific structures and thus cannot be reused with the encoder. Fix this by testing for this buffer by its VB2 address, and not through a dedicated flag stored in a higher-level decoder structure. This also allows us to remove said flag and simplify the code a bit. Since the flush buffer should never be used in the stateless decoder, also add safeguards to check against it. Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Alexandre Courbot authored
Calling S_FMT or TRY_FMT on the OUTPUT queue should adjust the resolution to the limits supported by the hardware. Until now this was only done on the CAPTURE queue, which could make clients believe that unsupported resolutions can be used when they set the coded size on the OUTPUT queue. In the case of the stateless decoder, the problem was even bigger since subsequently calling G_FMT on the CAPTURE queue would result in the unclamped resolution being returned, further inducing the client into error. Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Alexandre Courbot authored
Let's use the dedicated helpers to make sure we get the expected behavior and remove redundant code. Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hirokazu Honda authored
Add H264 profiles supported by the MediaTek 8173 decoder. [acourbot: fix commit log a bit, move to mtk_vcodec_dec.c] Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
lijian authored
Removed unnecessary 'return'. Signed-off-by: lijian <lijian@yulong.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Evgeny Novikov authored
ttusb_dec_send_command() invokes mutex_lock_interruptible() that can fail but then it releases the non-acquired mutex. The patch fixes that. Found by Linux Driver Verification project (linuxtesting.org). Fixes: dba328ba ("media: ttusb-dec: cleanup an error handling logic") Signed-off-by: Evgeny Novikov <novikov@ispras.ru> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Colin Ian King authored
Currently the null pointer check on dvb_spi->vcc_supply is inverted and this leads to only null values of the dvb_spi->vcc_supply being passed to the call of regulator_disable causing null pointer dereferences. Fix this by only calling regulator_disable if dvb_spi->vcc_supply is not null. Addresses-Coverity: ("Dereference after null check") Fixes: dcb01458 ("media: cxd2880-spi: Fix an error handling path") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sean Young authored
The receiver resolution is not populated. The resolution can be used to for various purposes like calculating the margins the decoder should use. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Sean Young authored
The receiver resolution is not populated. The resolution can be used to for various purposes like calculating the margins the decoder should use. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Ezequiel Garcia authored
Add more information about V4L2_PIX_FMT_NV12MT and V4L2_PIX_FMT_NV12M_16X16, so it's clearer for driver authors and users. Also, group the two pixel formats with the other tiled formats, for clarity. Unlike the recently introduced tiled formats (V4L2_PIX_FMT_NV12_4L4, etc) these formats have remained Samsung-specific until now. Therefore, and although the NV12MT and NV12MT_16X16 nomenclatures are less clear, we are keeping them as-is. 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>
-
Ezequiel Garcia authored
This format is produced by VeriSilicon Hantro G2 and VC8000D cores. It is a simple 4x4 tiling layout in a linear way. The pixel format was introduced by GStreamer using FourCC VT12, so let's stick to it. Link: https://gstreamer.freedesktop.org/documentation/video/video-format.htmlSigned-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>
-
Ezequiel Garcia authored
The V4L2_PIX_FMT_HM12 format is actually a simple NV12 tiled format, with 16x16 linear tiles. Rename the format and move its documentation together with the other tiled NV12 formats. Keep V4L2_PIX_FMT_HM12 for application compatibility. 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>
-
Ezequiel Garcia authored
The V4L2_PIX_FMT_SUNXI_TILED_NV12 format is actually a fairly common NV12 tiled format, with 32x32 linear tiles. Rename the format and move its documentation together with the other tiled NV12 formats. Keep V4L2_PIX_FMT_SUNXI_TILED_NV12 for application compatibility. 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>
-
Irui Wang authored
Add MT8195 venc driver's compatible and device private data. Signed-off-by: Irui Wang <irui.wang@mediatek.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Irui Wang authored
Updates binding document for mt8195 encoder driver. Signed-off-by: Irui Wang <irui.wang@mediatek.com> Acked-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>
-
Irui Wang authored
The supported capture/output formats don't depend on models, clean redundant definitions and naming with type instead. Signed-off-by: Irui Wang <irui.wang@mediatek.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Pete Hemery authored
If you image search "microdia sonix webcam", or SN9C120, you can find examples of the type of webcam I have. It has 6 built-in LEDs. It's ancient (2006 maybe?) but in 2020 it was the only USB webcam I had. It doesn't perform well, especially in low light. The Windows XP drivers had the ability to toggle the LEDs, as well as "Auto" mode which would read and adjust the exposure and turn them on when it got "too dark", along with other nice features, like smoothing dead pixels, funky filters, effects and face tracking. Watching Wireshark usbmon with the Windows driver I was able to discover which values are required to toggle the LEDs. Reading ext-ctrls-flash.rst, V4L2_FLASH_LED_MODE_TORCH seems to describe mostly what I want it to do. Ideally the control would be boolean/checkbox, but the existing implementation seems to require a menu. This patch implements the ability to control the LEDs, attempting to minimise changes to external files and other webcams. Review by anyone more familiar with the code base for unintended side effects would be welcome and appreciated. First kernel submission. Signed-off-by: Pete Hemery <petehemery@hotmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Christophe JAILLET authored
There is likely a typo here. To be consistent, we should compare 'fmt.height' with 'ctx->out.pix_fmt.height', not 'ctx->out.pix_fmt.width'. Instead of fixing the test, just remove it and copy 'fmt' unconditionally. Fixes: 59a63532 ("media: meson: Add M2M driver for the Amlogic GE2D Accelerator Unit") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Krzysztof Hałasa authored
TDA1997x driver tried to hold two values in a single variable: device's "client data" pointer was first set to "sd" in v4l2_i2c_subdev_init(), then it was overwritten explicitly using dev_set_drvdata() with "state". This caused tda1997x_remove() to fail badly. Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Pavel Skripkin authored
If em28xx dev has ->dev_next pointer, we need to delete ->dev_next list node from em28xx_extension_devlist on disconnect to avoid UAF bugs and corrupted list bugs, since driver frees this pointer on disconnect. Reported-and-tested-by: syzbot+a6969ef522a36d3344c9@syzkaller.appspotmail.com Fixes: 1a23f81b ("V4L/DVB (9979): em28xx: move usb probe code to a proper place") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
The combination of supports_requests == 1 and min_buffers_needed > 0 is not allowed, WARN on that and return an error. Also check that if vb2_core_qbuf() is called from req_queue, that it doesn't return an error, unless it is -EIO. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
Currently vivid supports the Request API, but it also sets min_buffers_needed in the vb2 queue. But the combination of support_requests and min_buffers_needed is not allowed due to the fact that vb2_core_qbuf() isn't supposed to fail when called from the request framework. And if min_buffers_needed > 0, then is can call start_streaming() which definitely can fail. With the new module option you can control if requests are not allowed (min_buffers_needed is 2 in that case), optionally allowed or are required. In the latter two cases min_buffers_needed is set to 0. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hans Verkuil authored
There is no reason for the cedrus driver to set min_buffers_needed. A non-zero min_buffers_needed can cause problems with the Request API if start_streaming fails when queueing a buffer from a request. Since it is not needed for this driver, just remove it. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Jernej Skrabec authored
HEVC frames may use scaling list feature. Add support for it. Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Benjamin Gaignard authored
If the bitstream embedded scaling lists allow the driver to use them for decode the frames. The scaling lists are expected to be in raster scan order (i.e. not up right diagonal scan order) Allocate the memory needed to store lists. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil: add missing @scaling kernel doc description in hantro_hw.h] Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Benjamin Gaignard authored
HEVC scaling lists are used for the scaling process for transform coefficients. V4L2_HEVC_SPS_FLAG_SCALING_LIST_ENABLED has to set when they are encoded in the bitstream. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-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>
-
Robert Foss authored
Expose the VFE version by returning the value read from the HW_VERSION register. Secondly, change the name of this function to conform with the CSID equivalent. Signed-off-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Robert Foss authored
The device argument is not needed, since it is accessible through the vfe_device argument already. Signed-off-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Robert Foss authored
The HW Version can in no case represent an error, so change the print priority to 'dbg'. Signed-off-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Robert Foss authored
vfe_set_power() is invoked a few times, which causes a lot of VFE HW version prints. Secondly there is no real reason for calling hw_version_read() from this location specifically, since it does nothing more than print the VFE HW version. A better location for the hw_version_read() call would be somewhere which is only executed once per VFE unit. Signed-off-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Heiko Stuebner authored
The px30 uses a V12 isp block so add compatible and matchdata for it. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Heiko Stuebner authored
Add the compatible for the px30-variant of the rkisp Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.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>
-
Heiko Stuebner authored
The rkisp1 evolved over soc generations and the rk3326/px30 introduced the so called v12 - probably meaning v1.2. Add the new register definitions. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Heiko Stuebner authored
The rkisp1 evolved over soc generations and the rk3326/px30 introduced the so called v12 - probably meaning v1.2. In a first step adapt the affected v10 parts to give them a matching suffix to enable us to add v12 variants later on. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Heiko Stuebner authored
The isp block evolved in subsequent socs, so some functions will behave differently on newer variants. Therefore make it possible to override the needed stats functions. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> 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>
-
Heiko Stuebner authored
The isp block evolved in subsequent socs, so some functions will behave differently on newer variants. Therefore make it possible to override the needed params functions. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> 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>
-
Heiko Stuebner authored
Depending on the per-soc implementation there can be one interrupt for isp, mipi and capture events or separate per-event interrupts. So simply check for the presence of a named "mi" interrupt to differentiate between the two cases. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-