- 25 Nov, 2020 4 commits
-
-
Hugues Fruchet authored
Add support of BT656 embedded synchronization bus. This mode allows to save hardware synchro lines hsync & vsync by replacing them with synchro codes embedded in data stream. This bus type is only compatible with 8 bits width data bus. Due to reserved values 0x00 & 0xff used for synchro codes, valid data vary from 0x1 to 0xfe, this is up to sensor to clip accordingly pixel data. As a consequence of this clipping, JPEG is not supported with this bus type. DCMI crop feature is also not available with this bus type. Signed-off-by:
Hugues Fruchet <hugues.fruchet@st.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Hugues Fruchet authored
Add support of BT656 embedded synchronization bus mode in DCMI driver. Add "bus-type" property and make it required so that there is no ambiguity between parallel mode (bus-type=5) and BT656 mode (bus-type=6). BT656 mode allows to save hardware synchro lines hsync & vsync by replacing them with synchro codes embedded in data stream, hence hsync-active & vsync-active properties are useless in this mode. With DCMI, BT656 bus mode is only compatible with 8 bits width data bus. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Tianshu Qiu authored
Add a v4l2 sub-device driver for the OminiVision ov9734 image sensor which can deliver maximum 720p image frames at 30 fps. This driver also add vertical blanking, exposure, test pattern, digital and analog gain control for the image sensor. Signed-off-by:
Bingbu Cao <bingbu.cao@intel.com> Signed-off-by:
Tianshu Qiu <tian.shu.qiu@intel.com> Signed-off-by:
-
Andy Shevchenko authored
There are few nice macros in mm.h, some of which we may use here. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
- 17 Nov, 2020 17 commits
-
-
Hans Verkuil authored
In two places time32 structures were defined, but they are not used if CONFIG_COMPAT_32BIT_TIME is not set. Put these two structs under #ifdef CONFIG_COMPAT_32BIT_TIME as well to clearly indicate that they are only used if that config option is set. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Qinglang Miao authored
Fix to goto snd_error in error handling case when fails to do snd_ctl_add, as done elsewhere in this function. Fixes: 28cae868 ("[media] solo6x10: move out of staging into drivers/media/pci.") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by:
-
Hans Verkuil authored
Fix this smatch error: saa7134-video.c:1286 saa7134_g_fmt_vid_overlay() error: we previously assumed 'f->fmt.win.clips' could be null (see line 1279) This is actually a false error since if f->fmt.win.clips is NULL, clipcount will be set to 0, so the clips array won't be touched, but it doesn't hurt to make this explicit in the code. Signed-off-by:
-
Zebediah Figura authored
cx231xx_close_extension and hence cx231xx_audio_fini() are called with the cx231xx device lock held, but snd_cx231xx_pcm_close() also grabs that mutex when closing the file on behalf of arecord. There seems to be no reason to wait for sound card resources to be released, so let the release be asynchronous. Tested with a Hauppauge 955Q (2040:b123) and Linux 5.9.6; the hang described in the bug no longer occurs and disconnecting the device correctly terminates arecord with ENODEV. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=204087Signed-off-by:
Zebediah Figura <zfigura@codeweavers.com> Signed-off-by:
-
Sakari Ailus authored
Prevent NULL (or close to NULL) pointer dereference in various places by registering the video device only when the V4L2 m2m framework has been set up. Fixes: commit 96d8eab5 ("V4L/DVB: [v5,2/2] v4l: Add a mem-to-mem videobuf framework test device") Signed-off-by:
-
Dikshita Agarwal authored
remove check for V4L2_CTRL_TYPE_BUTTON from v4l2_ctrl_request_clone and v4l2_ctrl_request_setup(). Signed-off-by:
Dikshita Agarwal <dikshita@codeaurora.org> Signed-off-by:
-
Helen Koike authored
All the items in the TODO list were addressed, uapi was reviewed, documentation written, checkpatch errors fixed, several bugs fixed. There is no big reason to keep this driver in staging, so move it out. Dt-bindings Verified with: make ARCH=arm64 dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/media/rockchip-isp1.yaml Fields of MAINTAINERS file sorted according to output of ./scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS --order [dt-bindings: media: rkisp1: move rockchip-isp1 bindings out of staging] [dt-bindings: media: rkisp1: move rockchip-isp1 bindings out of staging] [hverkuil: fix various checkpatch alignment warnings] Signed-off-by:
Helen Koike <helen.koike@collabora.com> Acked-by:
Tomasz Figa <tfiga@chromium.org> Signed-off-by:
-
Shunqian Zheng authored
Add the Rockchip ISP1 specific processing parameter format V4L2_META_FMT_RK_ISP1_PARAMS and metadata format V4L2_META_FMT_RK_ISP1_STAT_3A for 3A. Signed-off-by:
Shunqian Zheng <zhengsq@rock-chips.com> Signed-off-by:
Jacob Chen <jacob2.chen@rock-chips.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Helen Koike authored
The dma engine should be stopped first. The driver waits for an interrupt to stop the stream in a known state after a frame. If rkisp1_cap_stream_disable() is called after stopping the rest of the pipeline, then most likely the interrupt won't arrive, we'll get a timeout and debugfs variables mp_stop_timeout or sp_stop_timeout will be incremented. Fixes: 37db540bb9d1f ("media: staging: rkisp1: cap: refactor enable/disable stream to allow multistreaming") Signed-off-by: -
Dinghao Liu authored
When device_create() fails, dvbdev and dvbdevfops should be freed just like when dvb_register_media_device() fails. Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Qinglang Miao authored
Add the missing platform_device_unregister() before return from zd1301_frontend_attach in the error handling case when pdev->dev.driver is empty. There's an error handling route named err_platform_device_unregister, so just reuse it. Signed-off-by:
-
Dan Carpenter authored
Smatch complains that "rc_proto" comes from the user and it can result in shift wrapping in ir_raw_encode_scancode() drivers/media/rc/rc-ir-raw.c:526 ir_raw_encode_scancode() error: undefined (user controlled) shift '1 << protocol' This is true, but I reviewed the surrounding code and it appears harmless. Anyway, let's verify that "rc_proto" is valid as a kernel hardening measure. Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Mansur Alisha Shaik authored
After the SMMU translation is disabled in the arm-smmu shutdown callback during reboot, if any subsystem are still alive then IOVAs they are using will become PAs on bus, which may lead to crash. So implemented shutdown callback, which detach iommu maps. Signed-off-by:
Mansur Alisha Shaik <mansur@codeaurora.org> Signed-off-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by:
-
Mansur Alisha Shaik authored
In concurrency usecase and reboot scenario we are seeing muliple crashes related to iommu_map/iommu_unamp of core->fw.iommu_domain. In one case we are seeing "Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008" crash, this is because of core->fw.iommu_domain in venus_firmware_deinit() and trying to map in venus_boot() during venus_sys_error_handler() Call trace: __iommu_map+0x4c/0x348 iommu_map+0x5c/0x70 venus_boot+0x184/0x230 [venus_core] venus_sys_error_handler+0xa0/0x14c [venus_core] process_one_work+0x210/0x3d0 worker_thread+0x248/0x3f4 kthread+0x11c/0x12c ret_from_fork+0x10/0x18 In second case we are seeing "Unable to handle kernel paging request at virtual address 006b6b6b6b6b6b9b" crash, this is because of unmapping iommu domain which is already unmapped. Call trace: venus_remove+0xf8/0x108 [venus_core] venus_core_shutdown+0x1c/0x34 [venus_core] platform_drv_shutdown+0x28/0x34 device_shutdown+0x154/0x1fc kernel_restart_prepare+0x40/0x4c kernel_restart+0x1c/0x64 __arm64_sys_reboot+0x190/0x238 el0_svc_common+0xa4/0x154 el0_svc_compat_handler+0x2c/0x38 el0_svc_compat+0x8/0x10 Signed-off-by:
-
Mansur Alisha Shaik authored
For core ops we are having only write protect but there is no read protect, because of this in multithreading and concurrency, one CPU core is reading without wait which is causing the NULL pointer dereferece crash. one such scenario is as show below, where in one CPU core, core->ops becoming NULL and in another CPU core calling core->ops->session_init(). CPU: core-7: Call trace: hfi_session_init+0x180/0x1dc [venus_core] vdec_queue_setup+0x9c/0x364 [venus_dec] vb2_core_reqbufs+0x1e4/0x368 [videobuf2_common] vb2_reqbufs+0x4c/0x64 [videobuf2_v4l2] v4l2_m2m_reqbufs+0x50/0x84 [v4l2_mem2mem] v4l2_m2m_ioctl_reqbufs+0x2c/0x38 [v4l2_mem2mem] v4l_reqbufs+0x4c/0x5c __video_do_ioctl+0x2b0/0x39c CPU: core-0: Call trace: venus_shutdown+0x98/0xfc [venus_core] venus_sys_error_handler+0x64/0x148 [venus_core] process_one_work+0x210/0x3d0 worker_thread+0x248/0x3f4 kthread+0x11c/0x12c Signed-off-by:
-
Mansur Alisha Shaik authored
Currently in calculate_inst_freq(), video driver is calculating macro blocks per frame instead of macro blocks per second(mpbs). Which results frequency is always setting to lower frequency (150MHz) as per frequency table for sc7180. Hence the playback is not smooth. Corrected this by correcting the mbps calculation in calculate_inst_freq(). Signed-off-by:
-
Mansur Alisha Shaik authored
As per current implementation, video driver is unvoting "videom-mem" path for last video session during vdec_session_release(). While video playback when we try to suspend device, we see video clock warnings since votes are already removed during vdec_session_release(). corrected this by putting dummy vote on "video-mem" after last video session release and unvoting it during suspend. suspend") Fixes: 07f8f22a ("media: venus: core: remove CNOC voting while device Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
-
- 16 Nov, 2020 19 commits
-
-
Mansur Alisha Shaik authored
As per bandwidth table video driver is voting with average bandwidth for "video-mem" and "cpu-cfg" paths as peak bandwidth is zero in bandwidth table. suspend") Fixes: 07f8f22a ("media: venus: core: remove CNOC voting while device Signed-off-by:
-
Mansur Alisha Shaik authored
Currently video driver is voting for venus0-ebi path during buffer processing with an average bandwidth of all the instances and unvoting during session release. While video streaming when we try to do XO-SD using the command "echo mem > /sys/power/state command" , device is not entering to suspend state and from interconnect summary seeing votes for venus0-ebi Corrected this by voting for venus0-ebi path in venus_runtime_resume() and unvote during venus_runtime_suspend(). suspend") Fixes: 07f8f22a ("media: venus: core: remove CNOC voting while device Signed-off-by:
-
Mansur Alisha Shaik authored
Currently video driver is voting after clk enable and un voting before clk disable. This is incorrect, video driver should vote before clk enable and unvote after clk disable. Corrected this by changing the order of clk enable and clk disable. suspend") Fixes: 07f8f22a ("media: venus: core: remove CNOC voting while device Signed-off-by:
-
Alexandre Courbot authored
Per the stateful codec specification, VIDIOC_G_SELECTION with a target of V4L2_SEL_TGT_COMPOSE is supposed to return the crop area of capture buffers containing the decoded frame. Until now the driver did not get that information from the firmware and just returned the dimensions of CAPTURE buffers. The firmware unfortunately does not always provide the crop information from the stream ; also make sure to detect when that happens and fallback to providing the coded size in these cases. Signed-off-by:
Alexandre Courbot <acourbot@chromium.org> Signed-off-by:
-
Stanimir Varbanov authored
The default codec after driver open is set to be H264 but the instance format for capture is wrongly set to H263. Correct this to H264. For regular applications this is not a big issue because they set the format through S_FMT but for example v4l2-compliance does not. Signed-off-by:
-
Mauro Carvalho Chehab authored
Some identifiers have different names between their prototypes and the kernel-doc markup. Seome seems to be due to cut-and-paste related issues. Others need to be fixed, as kernel-doc markups should use this format: identifier - description Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> # IPU3 and V4L2 Signed-off-by: -
Yu Kuai authored
if mtk_jpeg_clk_init() succeed, mtk_jpeg_probe() and mtk_jpeg_remove() doesn't have a corresponding put_device(). Thus add a new helper mtk_jpeg_clk_release() to fix it. Fixes: b2f0d272 ("[media] vcodec: mediatek: Add Mediatek JPEG Decoder Driver") Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Signed-off-by:
-
Jernej Skrabec authored
Video engine in R40 is very similar to that in A33 but it runs on lower speed, at least according to OS images released by board designer. Signed-off-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
Jernej Skrabec authored
Allwinner R40 SoC contains video engine. Add compatible for it. Signed-off-by:
-
Ezequiel Garcia authored
To avoid potentially overflowing the kernel logs in the case of corrupted streams, this commit replaces an error message with a per-stream counter to be read through a driver-specific control. Applications can read the per-stream accumulated error macroblocks count. The old error message is replaced by a rate-limited debug message. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
It's possible that the VPU was initialized using just one buffer, containing only codec headers. In this case, right after the initialization and after updating the FIFO read pointer, we need to iterate through all the coda_buffer_meta and release any metas that have been already used by the VPU. This issue is affecting indirectly the bitstream buffer fill threshold, which depends on the meta end position of the first queued meta, which is passed to coda_bitstream_can_fetch_past(). Without this fix, it's possible that for certain videos, the bitstream buffer level is not filled properly, resulting in a PIC_RUN timeout. Reported-by:
Benjamin Bara <benjamin.bara@skidata.com> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Dafna Hirschfeld authored
Set the code of the metadata pads of the isp entity to MEDIA_BUS_FMT_METADATA_FIXED and set the width and height of their formats to 0. This solves the TODO item: "Fix pad format size for statistics and parameters entities." Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Acked-by:
-
Dafna Hirschfeld authored
MEDIA_BUS_FMT_METADATA_FIXED should be used when the same driver handles both sides of the link and the bus format is a fixed metadata format that is not configurable from userspace. The width and height will be set to 0 for this format. Signed-off-by:
-
Zhang Qilong authored
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak in cedrus_start_streaming. We should fix it. Fixes: d5aecd28 ("media: cedrus: Implement runtime PM") Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Signed-off-by:
-
Zhang Qilong authored
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference imbalance in rkisp1_vb2_start_streaming, so we should fix it. Fixes: 56e3b29f ("media: staging: rkisp1: add streaming paths") Signed-off-by:
-
Liu Shixin authored
Simplify the return expression. Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Signed-off-by:
-
Hsin-Yi Wang authored
Commit 9495b7e9 ("driver core: platform: Initialize dma_parms for platform devices") included dma_parms in platform_device. There's no need to allocate again. Fixes: 13483fc2 ("media: mtk-vcodec: set dma max segment size") Suggested-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by:
-
Evgeny Novikov authored
isif_probe() invokes iounmap() on error handling paths, but it does not reset the global state. So, later it can invoke iounmap() even when ioremap() fails. This is the case also for isif_remove(). The patch resets the global state after invoking iounmap() to avoid this. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Evgeny Novikov <novikov@ispras.ru> Signed-off-by:
-
Sakari Ailus authored
Remove Jason Chen's e-mail address for it no longer works. Signed-off-by:
-
