- 07 Mar, 2022 27 commits
-
-
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:
Mauro Carvalho Chehab <mchehab@kernel.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> 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:
Rob Herring <robh@kernel.org> Signed-off-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:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> 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 13 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 <laurent.pinchart+renesas@ideasonboard.com> 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:
-
Paul Pawlowski authored
Adds the requisite device id to support detection of the Apple FaceTime HD webcam exposed over the T2 BCE VHCI interface. Tested-by:
Aun-Ali Zaidi <admin@kodeit.net> Signed-off-by:
Paul Pawlowski <paul@mrarm.io> Signed-off-by:
Aditya Garg <gargaditya08@live.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Alexander Stein authored
Without this the default (SMPTE 170M) from init_cfg stays unchanged. Even after configuring 'srgb' colorspace (or 'raw') $ media-ctl -V "'csis-32e30000.mipi-csi':0 [colorspace:srgb]" the colorspace does not change at all: $ media-ctl --get-v4l2 "'csis-32e30000.mipi-csi':0" [fmt:SRGGB10_1X10/1920x1080 field:none colorspace:smpte170m xfer:709 ycbcr:601 quantization:lim-range] Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
-
Zhou Qingyang authored
In cal_ctx_v4l2_init_formats(), devm_kzalloc() is assigned to ctx->active_fmt and there is a dereference of it after that, which could lead to NULL pointer dereference on failure of devm_kzalloc(). Fix this bug by adding a NULL check of ctx->active_fmt. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code. Fixes: 71681550 ("media: ti-vpe: cal: Move format handling to cal.c and expose helpers") Signed-off-by:
Zhou Qingyang <zhou1615@umn.edu> Reviewed-by:
Pratyush Yadav <p.yadav@ti.com> Signed-off-by:
-
Dan Carpenter authored
This error path needs to drop the mutex to avoid a deadlock. Fixes: 7be91e02 ("media: i2c: Add ov08d10 camera sensor driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Bingbu Cao authored
MWB gain register are used to set gain for each mwb channel mannually. However, it will involve some artifacts at low light environment as gain cannot be applied to each channel synchronously. Update the driver to use group write for digital gain to make the sure RGB digital gain be applied together at frame boundary. Signed-off-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
-
Martin Kepplinger authored
link-frequencies is required but only mentioned in the example. Add it to the description. Fixes: f3ce7200 ("media: dt-bindings: media: document SK Hynix Hi-846 MIPI CSI-2 8M pixel sensor") Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> Reviewed-by:
-
Martin Kepplinger authored
This fixes "make dt_binding_check": Documentation/devicetree/bindings/media/i2c/hynix,hi846.example.dt.yaml: camera@20: port:endpoint: Unevaluated properties are not allowed ('link-frequencies', 'data-lanes' were unexpected) From schema: Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml [Sakari Ailus: Reword commit message] Fixes: f3ce7200 ("media: dt-bindings: media: document SK Hynix Hi-846 MIPI CSI-2 8M pixel sensor") Reported-by:Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Kees Cook authored
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Wrap the target region in struct_group(). This additionally fixes a theoretical misalignment of the copy (since the size of "buf" changes between 64-bit and 32-bit, but this is likely never built for 64-bit). FWIW, I think this code is totally broken on 64-bit (which appears to not be a "real" build configuration): it would either always fail (with an uninitialized data->buf_size) or would cause corruption in userspace due to the copy_to_user() in the call path against an uninitialized data->buf value: omap3isp_stat_request_statistics_time32(...) struct omap3isp_stat_data data64; ... omap3isp_stat_request_statistics(stat, &data64); int omap3isp_stat_request_statistics(struct ispstat *stat, struct omap3isp_stat_data *data) ... buf = isp_stat_buf_get(stat, data); static struct ispstat_buffer *isp_stat_buf_get(struct ispstat *stat, struct omap3isp_stat_data *data) ... if (buf->buf_size > data->buf_size) { ... return ERR_PTR(-EINVAL); } ... rval = copy_to_user(data->buf, buf->virt_addr, buf->buf_size); Regardless, additionally initialize data64 to be zero-filled to avoid undefined behavior. Link: https://lore.kernel.org/lkml/20211215220505.GB21862@embeddedor Cc: Arnd Bergmann <arnd@arndb.de> Fixes: 378e3f81 ("media: omap3isp: support 64-bit version of omap3isp_stat_data") Cc: stable@vger.kernel.org Reviewed-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
-
