- 08 Jul, 2016 40 commits
-
-
Javier Martinez Canillas authored
Commit 4b9c1cb6 ("[media] Documentation: media: description of DMABUF importing in V4L2") documented the V4L2 dma-buf importing support but did not update the VIDIOC_REQBUFS description, so only the Memory Mapping and User Pointer I/O methods are mentioned. Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Amitoj Kaur Chawla authored
Replace if condition and BUG() with a BUG_ON having the conditional expression of the if statement as argument. The Coccinelle semantic patch used to make this change is as follows: @@ expression E,f; @@ ( if (<+... f(...) ...+>) { BUG(); } | - if (E) { BUG(); } + BUG_ON(E); ) Signed-off-by:Amitoj Kaur Chawla <amitoj1606@gmail.com> Signed-off-by:
-
Alexey Khoroshilov authored
It is responsibility of a caller of fops->open(), to make sure an owner of the fops is available until file is closed. So, there is no need to lock THIS_MODULE explicitly. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Hans Verkuil authored
When the rc_map table is created the char pointer of the name of the keymap is copied to the rc_map->name field. However, this pointer points to memory from the keymap module itself. Since these keymap modules are not refcounted, that means anyone can call rmmod to unload that module. Which is not a big deal because the contents of the map is all copied to rc_map, except for the keymap name. So after a keymap module is unloaded the name pointer has become stale. Unloading the rc-core module will now cause a kernel oops in rc_dev_uevent(). The solution is to kstrdup the name so there are no more references to the keymap module remaining. Signed-off-by:
-
Hans Verkuil authored
The V4L2_DV_RGB_RANGE_* settings are, as the name says, for RGB formats only. So they should be ignored for non-RGB formats. Signed-off-by:
-
Hans Verkuil authored
Allow VIDEO_MEDIATEK_VCODEC to build when COMPILE_TEST is set (even without MTK_IOMMU). Signed-off-by:
-
Hans Verkuil authored
The patch dropping the vb2_dma_contig_init_ctx() and _cleanup_ctx() functions was already applied before this driver was added. So convert this driver as well. Signed-off-by:
-
Arnd Bergmann authored
When CONFIG_INPUT is disabled, multiple gspca backend drivers print compile-time warnings about unused variables: media/usb/gspca/cpia1.c: In function 'sd_stopN': media/usb/gspca/cpia1.c:1627:13: error: unused variable 'sd' [-Werror=unused-variable] media/usb/gspca/konica.c: In function 'sd_stopN': media/usb/gspca/konica.c:246:13: error: unused variable 'sd' [-Werror=unused-variable] This annotates the variables as __maybe_unused, to let the compiler know that they are declared intentionally. Fixes: ee186fd9 ("[media] gscpa_t613: Add support for the camera button") Fixes: c2f644ae ("[media] gspca_cpia1: Add support for button") Fixes: b517af72 ("V4L/DVB: gspca_konica: New gspca subdriver for konica chipset using cams") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Oliver Neukum authored
Allow for SS+ devices Signed-off-by:
Oliver Neukum <ONeukum@suse.com> Signed-off-by:
-
Hans Verkuil authored
Hans de Goede has no more time to work on those, so I'll take over. For gspca/pwc I'll do 'Odd Fixes', for radio-shark I'll be a full maintainer. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Bhaktipriya Shridhar authored
The workqueue "workqueue" is involved in transmitting hdpvr buffers. It has a single work item(&dev->worker) and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with the use of system_wq. System workqueues have been able to handle high level of concurrency for a long time now and hence it's not required to have a singlethreaded workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue created with create_singlethread_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantee unless the target CPU is explicitly specified and thus the increase of local concurrency shouldn't make any difference. Work item has been flushed in hdpvr_device_release() to ensure that there are no pending tasks while disconnecting the driver. Signed-off-by:
Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Bhaktipriya Shridhar authored
The workqueue "work_queues" enables hotplugging. It has a single work item(&state->delayed_work_enable_hotplug) and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with the use of system_wq. System workqueues have been able to handle high level of concurrency for a long time now and hence it's not required to have a singlethreaded workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue created with create_singlethread_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantee unless the target CPU is explicitly specified and thus the increase of local concurrency shouldn't make any difference. Work item has been sync cancelled in adv76xx_remove() to ensure that there are no pending tasks while disconnecting the driver. Signed-off-by:
-
Bhaktipriya Shridhar authored
The workqueue "work_queues" enables hotplugging. It has a single work item(&state->delayed_work_enable_hotplug) and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with the use of system_wq. System workqueues have been able to handle high level of concurrency for a long time now and hence it's not required to have a singlethreaded workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue created with create_singlethread_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantee unless the target CPU is explicitly specified and thus the increase of local concurrency shouldn't make any difference. Work item has been sync cancelled in tc358743_remove() to ensure that there are no pending tasks while disconnecting the driver. Signed-off-by:
-
Bhaktipriya Shridhar authored
The workqueue "work_queues" enables hotplugging. It has a single work item(&state->delayed_work_enable_hotplug) and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with the use of system_wq. System workqueues have been able to handle high level of concurrency for a long time now and hence it's not required to have a singlethreaded workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue created with create_singlethread_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantee unless the target CPU is explicitly specified and thus the increase of local concurrency shouldn't make any difference. Work item has been sync cancelled in adv7842_remove() to ensure that there are no pending tasks while disconnecting the driver. Signed-off-by:
-
Bhaktipriya Shridhar authored
The workqueue "work_thread" is involved in JPEG quality update. It has a single work item(&sd->work) and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with the use of system_wq. System workqueues have been able to handle high level of concurrency for a long time now and hence it's not required to have a singlethreaded workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue created with create_singlethread_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantee unless the target CPU is explicitly specified and thus the increase of local concurrency shouldn't make any difference. Work item has been flushed in sd_stop0() to ensure that there are no pending tasks while disconnecting the driver. Signed-off-by:
-
Antonio Ospite authored
v4l2-compliance fails with this message: fail: v4l2-test-buffers.cpp(250): \ timestamp != V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC && \ timestamp != V4L2_BUF_FLAG_TIMESTAMP_COPY ... test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL When setting the frame time, gspca uses v4l2_get_timestamp() which uses ktime_get_ts() which uses ktime_get_ts64() which returns a monotonic timestamp, so it's safe to initialize the buffer flags to V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC to fix the failure. Signed-off-by:Antonio Ospite <ao2@ao2.it> Signed-off-by:
-
Antonio Ospite authored
According to v4l2-compliance VIDIOC_ENUM_FRAMEINTERVALS should fail for unsupported frame sizes, but gspca is too tolerant and tries to find the frame intervals for the frame size nearest to the requested one. This makes v4l2-compliance fail with this message: fail: v4l2-test-formats.cpp(123): \ found frame intervals for invalid size 321x240 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL Fix this by using an exact match for the frame size when enumerating frame intervals, and retuning an error if the frame size for which the frame intervals have been asked is not supported. Signed-off-by: -
Antonio Ospite authored
The name wxh_to_nearest_mode() reflects better what the function does. Signed-off-by:
-
Antonio Ospite authored
Set the frame _interval_ type to V4L2_FRMIVAL_TYPE_DISCRETE instead of using V4L2_FRMSIZE_TYPE_DISCRETE which is meant for frame _size_. The old and new values happen to be the same so there is no functional change. Signed-off-by:
-
Antonio Ospite authored
When writing the change in commit dcc7fdbe ("[media] gspca: ov534/topro: prevent a division by 0") I used magic numbers for the default framerate to minimize the code footprint to make it easier to backport the patch to the stable trees. However it's better if the default framerate has its own define to avoid risking using different values in different places, and for readability. While at it also remove some trivial comments about the framerates which don't add much to the code anymore. Signed-off-by:
-
Arnd Bergmann authored
The pwc driver causes a warning when CONFIG_USB_PWC_INPUT_EVDEV is unset: drivers/media/usb/pwc/pwc-if.c: In function 'usb_pwc_probe': drivers/media/usb/pwc/pwc-if.c:1115:1: warning: label 'err_video_unreg' defined but not used [-Wunused-label] This moves the unused label and code inside another #ifdef to get rid of the warning. Signed-off-by:
-
Hans Verkuil authored
Make this a proper typed array. Drop the old allocate context code since that is no longer used. Note that the memops functions now get a struct device pointer instead of the struct device ** that was there initially (actually a void pointer to a struct containing only a struct device pointer). This code is now a lot cleaner. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by:
-
Hans Verkuil authored
Stop using alloc_ctx and just fill in the device pointer. Signed-off-by:
-
Hans Verkuil authored
Stop using alloc_ctx and just fill in the device pointer. Signed-off-by:
-
Hans Verkuil authored
Stop using alloc_ctx and just fill in the device pointer. Signed-off-by:
-
Hans Verkuil authored
Stop using alloc_ctx and just fill in the device pointer. Signed-off-by:
-
Hans Verkuil authored
Stop using alloc_ctx and just fill in the device pointer. Signed-off-by:
Fabien Dessenne <fabien.dessenne@st.com> Acked-by:
Benoit Parrot <bparrot@ti.com> Reviewed-by:
-
Hans Verkuil authored
Stop using alloc_ctx and just fill in the device pointer. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Cc: Scott Jiang <scott.jiang.linux@gmail.com> Acked-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Hans Verkuil authored
Stop using alloc_ctx and just fill in the device pointer. Signed-off-by:
-
Hans Verkuil authored
Stop using alloc_ctx and just fill in the device pointer. Signed-off-by:
-
Hans Verkuil authored
Stop using alloc_ctx and just fill in the device pointer. Signed-off-by:
-
Hans Verkuil authored
Stop using alloc_ctx and just fill in the device pointer. Signed-off-by:
-
Hans Verkuil authored
Stop using alloc_ctx as that is now no longer needed. Signed-off-by:
-
Hans Verkuil authored
The allocation context is nothing more than a per-plane device pointer to use when allocating buffers. So just provide a dev pointer in vb2_queue for that purpose and drivers can skip allocating/releasing/filling in the allocation context unless they require different per-plane device pointers as used by some Samsung SoCs. Signed-off-by:
-
Hans Verkuil authored
Make the dma attributes struct part of vb2_queue. This greatly simplifies the remainder of the patch series since the dma_contig alloc context is now (as before) just a struct device pointer. Signed-off-by:
-
Sylwester Nawrocki authored
This fixes dropping ownership of buffers in the driver's stop_streaming callback, so buffers on the memory-to-memory video nodes are properly released, also in case when the driver has a buffer only on one of the queues (OUTPUT, CAPTURE) before the video node close. The issue was being reported by videobuf2 with a following warning while checking q->owned_by_drv_count: [ 2498.310766] WARNING: CPU: 0 PID: 9358 at drivers/media/v4l2-core/videobuf2-core.c:1818 __vb2_queue_cancel+0xe8/0x14c [ 2498.320258] Modules linked in: [ 2498.323212] CPU: 0 PID: 9358 Comm: v4l2_decode Not tainted 4.7.0-rc4-next-20160627 #1210 [ 2498.331284] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 2498.331327] [<c010d738>] (unwind_backtrace) from [<c010a4b0>] (show_stack+0x10/0x14) [ 2498.331344] [<c010a4b0>] (show_stack) from [<c031a4ac>] (dump_stack+0x74/0x94) [ 2498.331358] [<c031a4ac>] (dump_stack) from [<c011a52c>] (__warn+0xd4/0x100) [ 2498.331369] [<c011a52c>] (__warn) from [<c011a578>] (warn_slowpath_null+0x20/0x28) [ 2498.331381] [<c011a578>] (warn_slowpath_null) from [<c04ed420>] (__vb2_queue_cancel+0xe8/0x14c) [ 2498.331395] [<c04ed420>] (__vb2_queue_cancel) from [<c04ee10c>] (vb2_core_queue_release+0x18/0x38) [ 2498.331406] [<c04ee10c>] (vb2_core_queue_release) from [<c04eab50>] (v4l2_m2m_ctx_release+0x1c/0x28) [ 2498.331420] [<c04eab50>] (v4l2_m2m_ctx_release) from [<c04fe184>] (fimc_m2m_release+0x24/0x78) [ 2498.331437] [<c04fe184>] (fimc_m2m_release) from [<c04d76c8>] (v4l2_release+0x34/0x74) [ 2498.331455] [<c04d76c8>] (v4l2_release) from [<c01dc8d4>] (__fput+0x80/0x1bc) [ 2498.331469] [<c01dc8d4>] (__fput) from [<c0132edc>] (task_work_run+0xc0/0xe4) [ 2498.331482] [<c0132edc>] (task_work_run) from [<c011d460>] (do_exit+0x304/0xa24) [ 2498.331493] [<c011d460>] (do_exit) from [<c011dccc>] (do_group_exit+0x3c/0xbc) [ 2498.331505] [<c011dccc>] (do_group_exit) from [<c0126cac>] (get_signal+0x200/0x65c) [ 2498.331517] [<c0126cac>] (get_signal) from [<c010e928>] (do_signal+0x84/0x3c4) [ 2498.331532] [<c010e928>] (do_signal) from [<c010a0ec>] (do_work_pending+0xa4/0xb4) [ 2498.331545] [<c010a0ec>] (do_work_pending) from [<c0107954>] (slow_work_pending+0xc/0x20) Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Kamil Debski <k.debski@samsung.com> Signed-off-by:
-
Javier Martinez Canillas authored
According to the V4L2 documentation the driver and card fields should be used to identify the driver and the device but the s5p-mfc driver fills those field using the platform device name, which in turn is the name of the device DT node. So not only the filled information isn't correct but also the same values are used in all the fields for both the encoder and decoder video devices. Before this patch: Driver Info (not using libv4l2): Driver name : 11000000.codec Card type : 11000000.codec Bus info : platform:11000000.codec Driver version: 4.7.0 Driver Info (not using libv4l2): Driver name : 11000000.codec Card type : 11000000.codec Bus info : platform:11000000.codec Driver version: 4.7.0 After this patch: Driver Info (not using libv4l2): Driver name : s5p-mfc Card type : s5p-mfc-dec Bus info : platform:11000000.codec Driver version: 4.7.0 Driver Info (not using libv4l2): Driver name : s5p-mfc Card type : s5p-mfc-enc Bus info : platform:11000000.codec Driver version: 4.7.0 Signed-off-by: -
Javier Martinez Canillas authored
The driver doesn't set the struct v4l2_capability bus_info field so the v4l2-compliance tool reports the following errors for VIDIOC_QUERYCAP: Required ioctls: VIDIOC_QUERYCAP returned 0 (Success) fail: v4l2-compliance.cpp(304): string empty fail: v4l2-compliance.cpp(528): check_ustring(vcap.bus_info, sizeof(vcap.bus_info)) test VIDIOC_QUERYCAP: FAIL This patch fixes by setting the field in VIDIOC_QUERYCAP ioctl handler: Required ioctls: VIDIOC_QUERYCAP returned 0 (Success) test VIDIOC_QUERYCAP: OK Signed-off-by: -
Javier Martinez Canillas authored
The streaming field in struct vb2_queue is meant to be private and should not be used by drivers directly, instead the vb2_is_streaming() function should be used to check the videobuf2 queue streaming status. Signed-off-by:
-
Javier Martinez Canillas authored
The V4L2 documentation says that applications must call the VIDIOC_REQBUFS ioctl to determine if a memory mapped, user pointer or DMABUF based I/O is supported by the driver. For example GStreamer does this by first calling VIDIOC_REQBUFS with count zero for all the possible streaming I/O methods and then finally doing the real VIDIOC_REQBUFS with count N using a known to be supported memory type. But the driver prints an error on VIDIOC_REQBUFS if the memory type is not supported which leads to the following errors that can confuse the users: [ 178.704390] vidioc_reqbufs:575: Only V4L2_MEMORY_MMAP is supported [ 178.704666] vidioc_reqbufs:575: Only V4L2_MEMORY_MMAP is supported [ 178.714956] vidioc_reqbufs:575: Only V4L2_MEMORY_MMAP is supported [ 178.715229] vidioc_reqbufs:575: Only V4L2_MEMORY_MMAP is supported Signed-off-by:
-
