- 07 Mar, 2022 35 commits
-
-
Dmitry Osipenko authored
Factor out H.264 hardware programming code into separate source file in a preparation to support V4L API by the Tegra video decoder driver. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Dmitry Osipenko authored
Add new V4L2_H264_DECODE_PARAM_FLAG_P/BFRAME flags that are needed by NVIDIA Tegra video decoder. Userspace will have to set these flags in accordance to the type of a decoded frame. Reviewed-by:
Nicolas Dufresne <nicolas@collabora.com> Signed-off-by:
-
Laurent Pinchart authored
The V4L2_PIX_FMT_BGR24 format is incorrectly described, with the B and G components swapped. Fix it. Fixes: 2ac9280c ("media: doc: pixfmt-rgb: Make 8 bits per component table more compact") Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Muhammad Usama Anjum authored
ret is constant in imx8mq_mipi_csi_pm_suspend(). This function cannot return error. Remove the return variable. Simplify other functions which are using this function. Signed-off-by:
Muhammad Usama Anjum <usama.anjum@collabora.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Colin Ian King authored
The static array fec_tab is read-only so it make sense to make it const. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Colin Ian King authored
The static arrays notch and sine are read-only so it make sense to make them const. Signed-off-by:
-
Colin Ian King authored
The static array DIB3000MC_I2C_ADDRESS is read-only so it make sense to make it const. Also add spaces to clean up checkpatch warnings. Signed-off-by:
-
Lad Prabhakar authored
CSI-2 (CSI4LNK0) on R-Car and RZ/G2 supports 4-lane mode which is already handled by rcar-csi2.c driver. This patch updates the data-lanes property to describe the same. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Christophe JAILLET authored
In [1], Christoph Hellwig has proposed to remove the wrappers in include/linux/pci-dma-compat.h. Some reasons why this API should be removed have been given by Julia Lawall in [2]. A coccinelle script has been used to perform the needed transformation. It can be found in [3]. [1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/ [2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/ [3]: https://lore.kernel.org/kernel-janitors/20200716192821.321233-1-christophe.jaillet@wanadoo.fr/Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Yang Li authored
Fix following includecheck warning: ./drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c: linux/pm_runtime.h is included more than once. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Dongliang Mu authored
hdpvr_register_videodev is responsible to initialize a worker in hdpvr_device. However, the worker is only initialized at hdpvr_start_streaming other than hdpvr_register_videodev. When hdpvr_probe does not initialize its worker, the hdpvr_disconnect will encounter one WARN in flush_work.The stack trace is as follows: hdpvr_disconnect+0xb8/0xf2 drivers/media/usb/hdpvr/hdpvr-core.c:425 usb_unbind_interface+0xbf/0x3a0 drivers/usb/core/driver.c:458 __device_release_driver drivers/base/dd.c:1206 [inline] device_release_driver_internal+0x22a/0x230 drivers/base/dd.c:1237 bus_remove_device+0x108/0x160 drivers/base/bus.c:529 device_del+0x1fe/0x510 drivers/base/core.c:3592 usb_disable_device+0xd1/0x1d0 drivers/usb/core/message.c:1419 usb_disconnect+0x109/0x330 drivers/usb/core/hub.c:2228 Fix this by moving the initialization of dev->worker to the starting of hdpvr_register_videodev Reported-by:
syzkaller <syzkaller@googlegroups.com> Signed-off-by:
Dongliang Mu <mudongliangabcd@gmail.com> Signed-off-by:
-
Bryan O'Donoghue authored
Reviewing the RB5 schematic its clear that we have missed out on defining both of the power-rails associated with the CSI PHY. Other PHYs such as the UFS, PCIe and USB connect to these rails and define each regulator individually. This means if we were to switch off the other various PHYs which enable these rails, the CAMSS would not appropriately power-on the CSI PHY. Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by:
-
Bryan O'Donoghue authored
Reviewing the RB3 schematic its clear that we have missed out on defining one of the power-rails associated with the CSI PHY. Other PHYs such as the UFS, PCIe and USB connect to these rails and define each regulator individually. This means if we were to switch off the other various PHYs which enable these rails, the CAMSS would not appropriately power-on the CSI PHY. Reviewed-by:
-
Bryan O'Donoghue authored
If a CAMSS block has no regulator set the regulator array to the empty set as opposed to setting the first element of the array to NULL. Suggested-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
-
Bryan O'Donoghue authored
Add the ability to enable or disable multiple regulators in bulk with camss. This is useful for sm8250, sdm845 and it looks like sdm660 where we have more than one CSI regulator to do at once. It should just work for standalone existing vdda regulators and parts which don't have an explicitly defined CSI regulator. [hverkuil: fix camss-csid.c:163:13: warning: 'ret' may be used uninitialized in this function] Reported-by:
Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by:
-
Bryan O'Donoghue authored
Add in missing vdda-phy-supply and vdda-pll-supply declarations. The sm8250 USB, PCIe, UFS, DSI and CSI PHYs use a common set of vdda rails. Define the CSI vdda regulators in the same way the qmp PHY does. Reviewed-by:
-
Bryan O'Donoghue authored
If we review the schematic for RB3 Thundercomm document Turbox-845 we see that the CAMSS CSI PHY has the same basic power-rail layout as UFS, PCIe and USB PHYs. We should therefore have two regulator declarations as is the case for UFS, PCIe and USB. Reviewed-by:
-
Lad Prabhakar authored
platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypasses the hierarchical setup and messes up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq_optional(). While at it, propagate error code in case devm_request_irq() fails instead of returning -EINVAL. Signed-off-by:
-
Jiasheng Jiang authored
As the possible failure of the vzalloc(), e->encoder_buf might be NULL. Therefore, it should be better to check it in order to guarantee the success of the initialization. If fails, we need to free not only 'e' but also 'e->name'. Also, if the allocation for ctx fails, we need to free 'e->encoder_buf' else. Fixes: f90cf607 ("media: vidtv: add a bridge driver") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by:
-
Xu Wang authored
'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. Signed-off-by:
Xu Wang <vulab@iscas.ac.cn> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Sergey Senozhatsky authored
Christoph suggests [1] that invalidating vmap range before direct mapping range makes more sense. [1]: https://lore.kernel.org/all/20220111085958.GA22795@lst.de/Signed-off-by:
Sergey Senozhatsky <senozhatsky@chromium.org> Acked-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
-
Dafna Hirschfeld authored
Replace the urb buffers allocation to use the noncontiguous API. This improves performance on ARM platforms where DMA coherent allocations produce uncached mappings. Note that the noncontiguous API requires the driver to handle synchronization. This commit is similar to this one for the uvc driver: https://lkml.org/lkml/2021/3/12/1506 Performance tests on rock-pi4 (Arm64) shows about 15x improvements: == DMA NONCONTIGUOUS == total durations: 20.63678480 sec urb processing durations: 0.286864889 sec uS/qty: 286864/2508 avg: 114.379 min: 0.583 max: 155.461 (uS) FPS: 24.92 lost: 0 done: 500 raw decode speed: 11.603 Gbits/s bytes 414831228.000 bytes/urb: 165403 == DMA COHERENT == total durations: 20.73551767 sec urb processing durations: 4.541559160 sec uS/qty: 4541559/2509 avg: 1810.107 min: 0.583 max: 2113.163 (uS) FPS: 24.90 lost: 0 done: 500 raw decode speed: 730.738 Mbits/s bytes 414785444.000 bytes/urb: 165319 Performance tests on x86 laptop show no significant difference: == DMA NONCONTIGUOUS == total durations: 20.220590102 sec urb processing durations: 0.63021818 sec uS/qty: 63021/2512 avg: 25.088 min: 0.138 max: 146.750 (uS) FPS: 24.72 lost: 0 done: 500 raw decode speed: 52.751 Gbits/s bytes 415421032.000 bytes/urb: 165374 == DMA COHERENT == total durations: 20.220475614 sec urb processing durations: 0.64751972 sec uS/qty: 64751/2512 avg: 25.777 min: 0.168 max: 132.250 (uS) FPS: 24.72 lost: 0 done: 500 raw decode speed: 51.927 Gbits/s bytes 415422794.000 bytes/urb: 165375 [hverkuil: incorporated Ezequiel's suggestions from his review] Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Dafna Hirschfeld authored
Instead of having two separated arrays, one for the urbs and one for their buffers, have one array of a struct containing both. In addition, the array is just 16 pointers, no need to dynamically allocate it. Signed-off-by:
-
Dafna Hirschfeld authored
If the callback 'start_streaming' fails, then all queued buffers in the driver should be returned with state 'VB2_BUF_STATE_QUEUED'. Currently, they are returned with 'VB2_BUF_STATE_ERROR' which is wrong. Fix this. This also fixes the warning: [ 65.583633] WARNING: CPU: 5 PID: 593 at drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.585027] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_soc_hdmi_codec dw_hdmi_i2s_audio saa7115 stk1160 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc crct10dif_ce panfrost snd_soc_simple_card snd_soc_audio_graph_card snd_soc_spdif_tx snd_soc_simple_card_utils gpu_sched phy_rockchip_pcie snd_soc_rockchip_i2s rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi cec drm_kms_helper drm rtc_rk808 rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchip_thermal pcie_rockchip_host ip_tables x_tables ipv6 [ 65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Tainted: G W 5.16.0-rc4-62408-g32447129cb30-dirty #14 [ 65.590293] Hardware name: Radxa ROCK Pi 4B (DT) [ 65.590696] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 65.591304] pc : vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.591850] lr : vb2_start_streaming+0x6c/0x160 [videobuf2_common] [ 65.592395] sp : ffff800012bc3ad0 [ 65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8 [ 65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612 [ 65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0 [ 65.594562] x20: ffff00000908a8c8 x19: 00000000fffffff4 x18: ffffffffffffffff [ 65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78 [ 65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce [ 65.596439] x11: 0000000000000028 x10: 0000000000000001 x9 : 0000000000000228 [ 65.597064] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78 [ 65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880 [ 65.598315] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0 [ 65.598940] Call trace: [ 65.599155] vb2_start_streaming+0xd4/0x160 [videobuf2_common] [ 65.599672] vb2_core_streamon+0x17c/0x1a8 [videobuf2_common] [ 65.600179] vb2_streamon+0x54/0x88 [videobuf2_v4l2] [ 65.600619] vb2_ioctl_streamon+0x54/0x60 [videobuf2_v4l2] [ 65.601103] v4l_streamon+0x3c/0x50 [videodev] [ 65.601521] __video_do_ioctl+0x1a4/0x428 [videodev] [ 65.601977] video_usercopy+0x320/0x828 [videodev] [ 65.602419] video_ioctl2+0x3c/0x58 [videodev] [ 65.602830] v4l2_ioctl+0x60/0x90 [videodev] [ 65.603227] __arm64_sys_ioctl+0xa8/0xe0 [ 65.603576] invoke_syscall+0x54/0x118 [ 65.603911] el0_svc_common.constprop.3+0x84/0x100 [ 65.604332] do_el0_svc+0x34/0xa0 [ 65.604625] el0_svc+0x1c/0x50 [ 65.604897] el0t_64_sync_handler+0x88/0xb0 [ 65.605264] el0t_64_sync+0x16c/0x170 [ 65.605587] ---[ end trace 578e0ba07742170d ]--- Fixes: 8ac45649 ("[media] stk1160: Stop device and unqueue buffers when start_streaming() fails") Signed-off-by:
-
Dafna Hirschfeld authored
In case we fail to allocate a transfer_buffer then we break the buffers creation loop and update the number of buffers to the number of successfully allocated which should be 'i' and not 'i - 1' nor 'i + 1' Signed-off-by:
-
Adam Ford authored
The i.MX8MM has a Hantro G1 video decoder similar to the imx8mq but lacks the post-processor present in the imx8mq. Add support in the driver for it with the post-processing removed. Signed-off-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
-
Adam Ford authored
The i.MX8M mini appears to have a similar G1 decoder but the post-processing isn't present, so different compatible flag is required. Since all the other parameters are the same with imx8mq, just add the new compatible flag to nxp,imx8mq-vpu.yaml. Signed-off-by:
-
Adam Ford authored
The VPU in the i.MX8MQ is really the combination of Hantro G1 and Hantro G2. With the updated vpu-blk-ctrl, the power domains system can enable and disable them separately as well as pull them out of reset. This simplifies the code and lets them run independently while still retaining backwards compatibility with older device trees for those using G1. Signed-off-by:
-
Adam Ford authored
The G1 and G2 are independent and separate decoder blocks that are enabled by the vpu-blk-ctrl power-domain controller, which now has a proper driver. Because these blocks only share the power-domain, and can be independently fused out, update the bindings to support separate nodes for the G1 and G2 decoders with vpu-blk-ctrl power-domain support. The new DT + old kernel isn't a supported configuration. Signed-off-by:
-
Ettore Chimenti authored
Newlines were missing in almost all regular and debug printk. Signed-off-by:
Ettore Chimenti <ek5.chimenti@gmail.com> Signed-off-by:
-
Pavel Skripkin authored
This reverts commit 2c98b8a3. Reverted patch causes problems with Hauppauge WinTV dualHD as Maximilian reported [1]. Since quick solution didn't come up let's just revert it to make this device work with upstream kernels. Link: https://lore.kernel.org/all/6a72a37b-e972-187d-0322-16336e12bdc5@elbmurf.de/ [1] Reported-by:
Maximilian Böhm <maximilian.boehm@elbmurf.de> Tested-by:
Pavel Skripkin <paskripkin@gmail.com> Signed-off-by:
-
Stanimir Varbanov authored
The HFI_PROPERTY_PARAM_VENC_HDR10_PQ_SEI HFI property is not supported on Venus v1 and v3. cc: stable@vger.kernel.org # 5.13+ Fixes: 9172652d ("media: venus: venc: Add support for CLL and Mastering display controls") Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
-
Stanimir Varbanov authored
During encoder driver open controls are initialized via a call to v4l2_ctrl_handler_setup which returns EINVAL error for V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM v4l2 control. The control default value is disabled and because of firmware limitations 8x8 transform cannot be disabled for the supported HIGH and CONSTRAINED_HIGH profiles. To fix the issue change the control default value to enabled (this is fine because the firmware enables 8x8 transform for high and constrained_high profiles by default). Also, correct the checking of profile ids in s_ctrl from hfi to v4l2 ids. cc: stable@vger.kernel.org # 5.15+ Fixes: bfee75f7 ("media: venus: venc: add support for V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM control") Signed-off-by:
-
Ameer Hamza authored
The venus_helper_alloc_dpb_bufs() implementation allows an early return on an error path when checking the id from ida_alloc_min() which would not release the earlier buffer allocation. Move the direct kfree() from the error checking of dma_alloc_attrs() to the common fail path to ensure that allocations are released on all error paths in this function. Addresses-Coverity: 1494120 ("Resource leak") cc: stable@vger.kernel.org # 5.16+ Fixes: 40d87aaf ("media: venus: vdec: decoded picture buffer handling during reconfig sequence") Signed-off-by:Ameer Hamza <amhamza.mgc@gmail.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Stanimir Varbanov authored
Describe missing structure members: core.h: warning: Function parameter or member 'sys_err_done' not described in 'venus_core' 'fw_min_cnt' not described in 'venus_inst' 'flags' not described in 'venus_inst' 'dpb_ids' not described in 'venus_inst' Signed-off-by:
-
- 17 Feb, 2022 5 commits
-
-
Laurent Pinchart authored
Replace the driver-specific definitions of MIPI CSI-2 data types with macros from mipi-csi2.h. Signed-off-by:
-
Laurent Pinchart authored
Replace the hardcoded MIPI CSI-2 data types with macros from mipi-csi2.h. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Laurent Pinchart authored
Replace the hardcoded MIPI CSI-2 data types with macros from mipi-csi2.h. Signed-off-by:
-
Laurent Pinchart authored
There are many CSI-2-related drivers in the media subsystem that come with their own macros to handle the CSI-2 data types (or just hardcode the numerical values). Provide a shared header with definitions for those data types that driver can use. Signed-off-by:
-
Nikita Yushchenko authored
VSP hardware could be used (e.g. by the bootloader) before driver load, and some interrupts could be left in enabled and pending state. In this case, setting up VSP interrupt handler without masking interrupts before causes interrupt handler to be immediately called (and crash due to null vsp->info dereference). Fix that by explicitly masking all interrupts before setting the interrupt handler. To do so, have to set the interrupt handler later, after hw revision is already detected and number of interrupts to mask gets known. Based on patch by Koji Matsuoka <koji.matsuoka.xm@renesas.com> included in the Renesas BSP kernel. Signed-off-by:
Nikita Yushchenko <nikita.yoush@cogentembedded.com> Reviewed-by:
-
