Commit 4a81656c8e ("arm64: dts: mediatek: mt8188: Address binding
warnings for MDP3 nodes") caused a regression on the MDP functionality
when it removed the MT8195 compatibles from the MDP3 nodes, since the
MT8188 compatible was not yet listed as a possible MDP component
compatible in mdp_comp_dt_ids. This resulted in an empty output
bitstream when using the MDP from userspace, as well as the following
errors:
mtk-mdp3 14001000.dma-controller: Uninit component inner id 4
mtk-mdp3 14001000.dma-controller: mdp_path_ctx_init error 0
mtk-mdp3 14001000.dma-controller: CMDQ sendtask failed: -22
Add the missing compatible to the array to restore functionality.
Fixes: 4a81656c8e ("arm64: dts: mediatek: mt8188: Address binding warnings for MDP3 nodes")
Cc: stable@vger.kernel.org
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d24 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping locks in atomic contexts.
Switch to the regular pointer formatting which is safer and
easier to reason about.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The v4l2_fh associated with an open file handle is now guaranteed
to be available in file->private_data, initialised by v4l2_fh_add().
Access the v4l2_fh, and from there the driver-specific structure,
from the file * in all ioctl handlers.
While at modify mtk_vcodec_enc_get_chip_name() to accept a ctx instead
of a raw void *.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Co-developed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Multiple drivers that use v4l2_fh and call v4l2_fh_del() manually reset
the file->private_data pointer to NULL in their video device .release()
file operation handler. Move the code to the v4l2_fh_del() function to
avoid direct access to file->private_data in drivers. This requires
adding a file pointer argument to the function.
Changes to drivers have been generated with the following coccinelle
semantic patch:
@@
expression fh;
identifier filp;
identifier release;
type ret;
@@
ret release(..., struct file *filp, ...)
{
<...
- filp->private_data = NULL;
...
- v4l2_fh_del(fh);
+ v4l2_fh_del(fh, filp);
...>
}
@@
expression fh;
identifier filp;
identifier release;
type ret;
@@
ret release(..., struct file *filp, ...)
{
<...
- v4l2_fh_del(fh);
+ v4l2_fh_del(fh, filp);
...
- filp->private_data = NULL;
...>
}
@@
expression fh;
identifier filp;
identifier release;
type ret;
@@
ret release(..., struct file *filp, ...)
{
<...
- v4l2_fh_del(fh);
+ v4l2_fh_del(fh, filp);
...>
}
Manual changes have been applied to Documentation/ to update the usage
patterns, to drivers/media/v4l2-core/v4l2-fh.c to update the
v4l2_fh_del() prototype and reset file->private_data, and to
include/media/v4l2-fh.h to update the v4l2_fh_del() function prototype
and its documentation.
Additionally, white space issues have been fixed manually in
drivers/usb/gadget/function/uvc_v4l2.c
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
All the drivers that use v4l2_fh and call v4l2_fh_add() manually store a
pointer to the v4l2_fh instance in file->private_data in their video
device .open() file operation handler. Move the code to the
v4l2_fh_add() function to avoid direct access to file->private_data in
drivers. This requires adding a file pointer argument to the function.
Changes to drivers have been generated with the following coccinelle
semantic patch:
@@
expression fh;
identifier filp;
identifier open;
type ret;
@@
ret open(..., struct file *filp, ...)
{
<...
- filp->private_data = fh;
...
- v4l2_fh_add(fh);
+ v4l2_fh_add(fh, filp);
...>
}
@@
expression fh;
identifier filp;
identifier open;
type ret;
@@
ret open(..., struct file *filp, ...)
{
<...
- v4l2_fh_add(fh);
+ v4l2_fh_add(fh, filp);
...
- filp->private_data = fh;
...>
}
Manual changes have been applied to Documentation/ to update the usage
patterns, to drivers/media/v4l2-core/v4l2-fh.c to update the
v4l2_fh_add() prototype set file->private_data, and to
include/media/v4l2-fh.h to update the v4l2_fh_add() function prototype
and its documentation.
Additionally, white space issues have been fixed manually in
drivers/media/platform/nvidia/tegra-vde/v4l2.c,
drivers/media/platform/rockchip/rkvdec/rkvdec.c,
drivers/media/v4l2-core/v4l2-fh.c and
drivers/staging/most/video/video.c.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Accessing file->private_data manually to retrieve the v4l2_fh pointer is
error-prone, as the field is a void * and will happily cast implicitly
to any pointer type.
Replace all remaining locations that read the v4l2_fh pointer directly
from file->private_data and cast it to driver-specific file handle
structures with driver-specific functions that use file_to_v4l2_fh() and
perform the same cast.
No functional change is intended, this only paves the way to remove
direct accesses to file->private_data and make V4L2 drivers safer.
Other accesses to the field will be addressed separately.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Accessing file->private_data manually to retrieve the v4l2_fh pointer is
error-prone, as the field is a void * and will happily convert
implicitly to any pointer type. To avoid direct access to
file->private_data, introduce a new inline function that retrieves the
v4l2_fh pointer, and use it to replace common access patterns through
the kernel.
Changes to drivers have been generated with the following coccinelle
semantic patch:
@@
struct file *filp;
identifier fh;
@@
- struct v4l2_fh *fh = filp->private_data;
+ struct v4l2_fh *fh = file_to_v4l2_fh(filp);
Manual changes have been applied to Documentation/ to update the usage
patterns, and to include/media/v4l2-fh.h to add the new function.
While at it, fix a typo in the title of v4l2-fh.rst: the file describes
the "file handles" API, not "file handlers".
No functional change is intended, this only paves the way to remove
direct accesses to file->private_data and make V4L2 drivers safer.
Other accesses to the field will be addressed separately.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The HW iommu is able to support a 34-bit iova address-space (16GB),
enable this feature for the encoder/decoder driver by shifting the
address by two bits and setting the extended address registers.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Mediatek devices that support HEVC also support the main still picture
profile, but today, the main still picture profile is excluded.
This removes the skip mask for HEVC, and enables the main still
picture profile decoding.
Signed-off-by: Nathan Hebert <nhebert@chromium.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The vsi (video shared information) struct needs to be synchronized
between firmware and host, as a change that is only done in the host
version of the struct but isn't synchronized to the firmware. This can
lead to decoding issues with H264 bitstreams. Highlight this requirement
within the struct descriptions.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Add a new extended vsi_ext struct besides the existing vsi struct, to
enable calculating the end of the address range of the current working
buffer for architectures, where simply adding the buffer size to the
start of the address range isn't sufficient.
Additionally, on extended architectures, the NAL information can be
fetched directly from the firmware, which allows skipping the parsing
step within the kernel.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Extend the VSI (video shared information) struct to allow sending slice
parameters to SCP, as the parameters have changed on MT8188 architecture.
Remove VSI related information from the common interface to ensure that
the interface is usable by architectures with and without the extended
parameters. The new VSI extensions will be introduced in later patches.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The framebuffer size for decoder instances was being incorrectly set -
inst->vsi_core->fb.y.size was assigned twice consecutively.
Assign the second picinfo framebuffer size to the C framebuffer instead,
which appears to be the intended target based on the surrounding code.
Fixes: 2674486aac ("media: mediatek: vcodec: support stateless hevc decoder")
Cc: stable@vger.kernel.org
Signed-off-by: Fei Shao <fshao@chromium.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
On Mediatek devices with a system companion processor (SCP) the mtk_scp
structure has to be removed explicitly to avoid a resource leak.
Free the structure in case the allocation of the firmware structure fails
during the firmware initialization.
Fixes: 53dbe08504 ("media: mtk-vcodec: potential null pointer deference in SCP")
Cc: stable@vger.kernel.org
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
This is one of three clang warnings about incompatible enum types
in a conditional expression:
drivers/media/platform/mediatek/vcodec/encoder/venc/venc_h264_if.c:597:29: error: conditional expression between different enumeration types ('enum scp_ipi_id' and 'enum ipi_id') [-Werror,-Wenum-compare-conditional]
597 | inst->vpu_inst.id = is_ext ? SCP_IPI_VENC_H264 : IPI_VENC_H264;
| ^ ~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~
The code is correct, so just rework it to avoid the warning.
Fixes: 0dc4b32861 ("media: mtk-vcodec: venc: support SCP firmware")
Cc: stable@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@google.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Pull media updates from Mauro Carvalho Chehab:
- Sensor driver fixes
- remove dead TI wl128x FM radio driver
- Add support for the imx462 sensor at the IMX290 binding
- V4L2 pixel data transmitter and receiver documentation improvements
- Add support for MIPI Discovery and Configuration for C-PHY line
orders
- imx8-isi fixes and improvements
- stm32: dcmipp: add core support for the stm32mp25
- qcom: camss: Add sc7280 support
- Various fixes and enhancements
* tag 'media/v6.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (152 commits)
media: nuvoton: Fix an error check in npcm_video_ece_init()
media: dvb-usb-v2: af9035: fix ISO C90 compilation error on af9035_i2c_master_xfer
media: platform: rzg2l-cru: rzg2l-video: Fix the comment in rzg2l_cru_start_streaming_vq()
media: fix secfeed undefined when filter alloc fail
media: dt-bindings: trivial white-space and example cleanup
MAINTAINERS: repair file entry in MEDIA DRIVERS FOR STM32 - CSI
media: solo6x10: Use const 'struct bin_attribute' callback
media: saa7164: Remove unused values
staging: media: imx: fix OF node leak in imx_media_add_of_subdevs()
media: platform: exynos4-is: Remove unused __is_get_frame_size
media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread
media: mmp: Bring back registration of the device
media: cec: include linux/debugfs.h and linux/seq_file.h where needed
Revert "media: qcom: camss: Restructure camss_link_entities"
media: venus: Remove unused hfi_core_ping()
media: dt-bindings: qcom-venus: Deprecate video-decoder and video-encoder where applicable
media: venus: Populate video encoder/decoder nodename entries
media: venus: Add support for static video encoder/decoder declarations
media: venus: match instance creation and destruction order
media: venus: destroy hfi session after m2m_ctx release
...
With KASAN enabled, clang fails to optimize the inline version of
vdec_vp9_slice_map_counts_eob_coef() properly, leading to kilobytes
of temporary values spilled to the stack:
drivers/media/platform/mediatek/vcodec/decoder/vdec/vdec_vp9_req_lat_if.c:1526:12: error: stack frame size (2160) exceeds limit (2048) in 'vdec_vp9_slice_update_prob' [-Werror,-Wframe-larger-than]
This seems to affect all versions of clang including the latest (clang-20),
but the degree of stack overhead is different per release.
Marking the function as noinline_for_stack is harmless here and avoids
the problem completely.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Just like was done with MM_REG_WRITE, remove the mask from the
MM_REG_POLL macro, leaving MM_REG_POLL_MASK to be used when a mask is
required, and update the call sites accordingly. In this case, all calls
require a mask, so MM_REG_POLL remains unused, but at least this makes
the MM_REG_POLL macros consistent with the MM_REG_WRITE ones.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are two macros to issue a cmdq write: MM_REG_WRITE_MASK and
MM_REG_WRITE, but confusingly, both of them take a mask parameter. The
difference is that MM_REG_WRITE additionally checks whether the mask
passed in contains the register mask, in which case, the 0xffffffff mask
is passed to cmdq_pkt_write_mask(), effectively disregarding the mask
and calling cmdq_pkt_write() as an optimization.
Move that optimization to the MM_REG_WRITE_MASK macro and make
MM_REG_WRITE the variant that doesn't take a mask, directly calling to
cmdq_pkt_write().
Change the call sites to MM_REG_WRITE whenever a mask wasn't necessary
(ie 0xffffffff or a <register>_MASK was passed as mask) and in other
cases to MM_REG_WRITE_MASK.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The platform compatibility checks for MT8183 and
MT8195 in mdp_cmdq_prepare() are redundant as they are
done in __get_config_offset() itself. Furthermore
there are two if-else branch in __get_config_offset()
which have similar conditions and are redundant.
To address this, remove the check in mdp_cmdq_prepare()
and combine the two if-else branch into one in
__get_config_offset().
Signed-off-by: Mohammed Anees <pvmohammedanees2003@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Since commit 88785982a1 ("media: vb2: use lock if wait_prepare/finish
are NULL") it is no longer needed to set the wait_prepare/finish
vb2_ops callbacks as long as the lock field in vb2_queue is set.
Since the vb2_ops_wait_prepare/finish callbacks already rely on that field,
we can safely drop these callbacks.
This simplifies the code and this is a step towards the goal of deleting
these callbacks.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> # for meson-ge2d
Acked-by: Andrzej Pietrasiewicz <andrzejtp2010@gmail.com>
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/media to use .remove(), with
the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
"struct vb2_ops" are not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
18059 3096 16 21171 52b3 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateful.o
After:
=====
text data bss dec hex filename
18171 2968 16 21155 52a3 drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateful.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
MT8195 and MT8188 share a similar MDP3 macro-block, with minor
differences - as in, the latter supports a subset of the number
of components supported by the former, but are otherwise handled
in the same way.
Add driver data for MT8188, reusing the already present MT8195
data where possible.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Fei Shao <fshao@chromium.org>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
As talked about in commit 14d3ae2efe ("ARM: 8507/1: dma-mapping: Use
DMA_ATTR_ALLOC_SINGLE_PAGES hint to optimize alloc"), it doesn't
really make sense to try to allocate contiguous chunks of memory for
video encoding/decoding. Let's switch the Mediatek vcodec driver to
pass DMA_ATTR_ALLOC_SINGLE_PAGES and take some of the stress off the
memory subsystem.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Fei Shao <fshao@chromium.org>
Reviewed-by: Fei Shao <fshao@chromium.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Both 'bs_dma' and 'dma_addr' are integers. No need to convert the
type from dma_addr_t to uint64_t again.
Fixes: d353c3c34a ("media: mediatek: vcodec: support 36 bits physical address")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The supported decoder commands are different for stateless and
stateful architectures. Add stateless decoder commands to fix
the v4l2-compliance test error below.
Codec ioctls:
VIDIOC_ENCODER_CMD returned -1 (Inappropriate ioctl for device)
VIDIOC_TRY_ENCODER_CMD returned -1 (Inappropriate ioctl for device)
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
VIDIOC_G_ENC_INDEX returned -1 (Inappropriate ioctl for device)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
VIDIOC_DECODER_CMD returned -1 (Invalid argument)
VIDIOC_TRY_DECODER_CMD returned -1 (Invalid argument)
VIDIOC_TRY_DECODER_CMD returned -1 (Invalid argument)
fail: v4l2-test-codecs.cpp(126): ret
test VIDIOC_(TRY_)DECODER_CMD: FAIL
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Pull media updates from Mauro Carvalho Chehab:
- New V4L2 ioctl VIDIOC_REMOVE_BUFS
- experimental support for using generic metaformats on V4L2 core
- New drivers: Intel IPU6 controller driver, Broadcom BCM283x/BCM271x
- More cleanups at atomisp driver
- Usual bunch of driver cleanups, improvements and fixes
* tag 'media/v6.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (328 commits)
media: bcm2835-unicam: Depend on COMMON_CLK
Revert "media: v4l2-ctrls: show all owned controls in log_status"
media: ov2740: Ensure proper reset sequence on probe()
media: intel/ipu6: Don't print user-triggerable errors to kernel log
media: bcm2835-unicam: Fix driver path in MAINTAINERS
media: bcm2835-unicam: Fix a NULL vs IS_ERR() check
media: bcm2835-unicam: Do not print error when irq not found
media: bcm2835-unicam: Do not replace IRQ retcode during probe
media: bcm2835-unicam: Convert to platform remove callback returning void
media: media: intel/ipu6: Fix spelling mistake "remappinp" -> "remapping"
media: intel/ipu6: explicitly include vmalloc.h
media: cec.h: Fix kerneldoc
media: uvcvideo: Refactor iterators
media: v4l: async: refactor v4l2_async_create_ancillary_links
media: intel/ipu6: Don't re-allocate memory for firmware
media: dvb-frontends: tda10048: Fix integer overflow
media: tc358746: Use the correct div_ function
media: i2c: st-mipid02: Use the correct div function
media: tegra-vde: Refactor timeout handling
media: stk1160: Use min macro
...
Use an API that resembles more the actual use of job_count.
Found by cocci:
drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c:527:5-24: WARNING: atomic_dec_and_test variation before object free at line 541.
drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c:578:6-25: WARNING: atomic_dec_and_test variation before object free at line 581.
Link: https://lore.kernel.org/linux-media/20240429-fix-cocci-v3-12-3c4865f5a4b0@chromium.org
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
It is possible that mtk_vcodec_enc_pw_on fails, and in that scenario
the PM counter is not incremented, and subsequent call to
mtk_vcodec_enc_pw_off decrements the counter, leading to a PM imbalance.
Fix by bailing out of venc_if_encode in the case when mtk_vcodec_enc_pw_on
fails.
Fixes: 4e855a6efa ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver")
Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly
called only when the buffer to free exists, there are some instances
that didn't do the check and triggered warnings in practice.
We believe those checks were forgotten unintentionally. Add the checks
back to fix the warnings.
Signed-off-by: Fei Shao <fshao@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
In mtk_vcodec_mem_free(), there are two cases where a NULL VA is passed:
- mem->size == 0: we are called to free no memory. This may happen when
we call mtk_vcodec_mem_free() twice or the memory has never been
allocated.
- mem->size > 0: we are called to free memory but without VA. This means
that we failed to free the memory for real.
Both cases are not expected to happen, and we want to have clearer error
messages to describe which one we just encountered.
Update the error messages to include more information for that purpose.
Signed-off-by: Fei Shao <fshao@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
In mtk_vcodec_mem_alloc() and mtk_vcodec_mem_free(), the value of
mem->size is not expected to change before and when using the DMA APIs
and debug print, so there's no point in keeping local copies of it.
Drop the local variable "size" in the mentioned functions, and update
printk format identifiers accordingly.
This makes the code slightly more visually consistent, and retrieve a
small amount of memory that is used for no real purpose.
Signed-off-by: Fei Shao <fshao@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
