- 24 Aug, 2016 40 commits
-
-
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 gsc-m2m 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 the driver, card and bus_info fields. Before this patch: Driver Info (not using libv4l2): Driver name : 13e00000.video- Card type : 13e00000.video-scaler Bus info : platform:13e00000.video-scaler Driver version: 4.7.0 After this patch: Driver Info (not using libv4l2): Driver name : exynos-gsc Card type : exynos-gsc gscaler Bus info : platform:13e00000.video-scaler Driver version: 4.7.0 Signed-off-by:Javier Martinez Canillas <javier@osg.samsung.com> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Javier Martinez Canillas authored
The driver doesn't set the device in the struct v4l2_capability bus_info field so v4l2-compliance reports the following error for VIDIOC_QUERYCAP: Required ioctls: fail: v4l2-compliance.cpp(537): missing bus_info prefix ('platform') test VIDIOC_QUERYCAP: FAIL This patch fixes this by filling also the device besides the bus. Signed-off-by: -
Javier Martinez Canillas authored
The driver fills in both the struct v4l2_capability driver and card fields the same values, that is the driver's name plus the information if the dev is a decoder or an encoder. But the driver field has a fixed length of 16 bytes so the filled data is truncated: Driver Info (not using libv4l2): Driver name : s5p-jpeg decode Card type : s5p-jpeg decoder Bus info : platform:11f50000.jpeg Driver version: 4.7.0 Also, this field should only contain the driver's name so use just that. The information if the device is a decoder or an encoder is in the card type field anyways. Signed-off-by:Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Javier Martinez Canillas authored
The same struct device_node * is used for looking up the I2C sensor, OF graph endpoint and port. So the reference count is incremented but not decremented for the endpoint and port nodes. Fix this by having separate pointers for each node looked up. Signed-off-by:
Nicolas Dufresne <nicoas.dufresne@collabora.com> Signed-off-by:
-
Javier Martinez Canillas authored
The driver doesn't set the struct v4l2_capability cap_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: -
Mauro Carvalho Chehab authored
Remove those two vars that aren't used, as reported by smatch: drivers/media/pci/tw5864/tw5864-video.c: In function 'tw5864_prepare_frame_headers': drivers/media/pci/tw5864/tw5864-video.c:1219:16: warning: variable 'space_before_sl_hdr' set but not used [-Wunused-but-set-variable] unsigned long space_before_sl_hdr; ^~~~~~~~~~~~~~~~~~~ drivers/media/pci/tw5864/tw5864-video.c:1218:6: warning: variable 'sl_hdr' set but not used [-Wunused-but-set-variable] u8 *sl_hdr; ^~~~~~ Signed-off-by: -
Mauro Carvalho Chehab authored
As warned by smatch: drivers/media/pci/tw5864/tw5864-core.c:160 tw5864_h264_isr() error: double lock 'irqsave:flags' drivers/media/pci/tw5864/tw5864-core.c:174 tw5864_h264_isr() error: double unlock 'irqsave:flags' Remove the IRQ duplicated lock. Signed-off-by: -
Hans Verkuil authored
Fix this warning: warning: (VIDEO_TW5864 && VIDEO_MEDIATEK_VCODEC) selects VIDEOBUF2_DMA_CONTIG which has unmet direct dependencies (MEDIA_SUPPORT && HAS_DMA) This driver depends on HAS_DMA. Signed-off-by:
-
Andrey Utkin authored
Support for boards based on Techwell TW5864 chip which provides multichannel video & audio grabbing and encoding (H.264, MJPEG, ADPCM G.726). This submission implements only H.264 encoding of all channels at D1 resolution. Thanks to Mark Thompson <sw@jkqxz.net> for help, and for contribution of H.264 startcode emulation prevention code. Signed-off-by:
Andrey Utkin <andrey.utkin@corp.bluecherry.net> Signed-off-by:
-
Mauro Carvalho Chehab authored
/devel/v4l/patchwork/Documentation/media/uapi/v4l/extended-controls.rst:2116: WARNING: Inline literal start-string without end-string. Signed-off-by: -
Hans Verkuil authored
This field was never documented, and neither was it mentioned that it should be zeroed by the application. Signed-off-by:
-
Hans Verkuil authored
The dma-contig and dma-sg memops require a valid struct device for the DMA to be handled correctly. Call WARN_ON and return ERR_PTR(-EINVAL) if it was NULL. Setting the correct device pointer was forgotten in several new driver submissions. This was caught during code review, but it really should be caught in the code. Signed-off-by:
-
Hans Verkuil authored
Always return an ERR_PTR() instead of NULL. This makes the behavior of alloc, get_userptr and attach_dmabuf the same. Update the documentation in videobuf2-core.h as well. Signed-off-by:
-
Javier Martinez Canillas authored
There is a TODO comment about the dma-buf being mapped in VIDIOC_QBUF instead of doing it closer to when the actual DMA is going to happen when the buffers are queued in the driver (i.e: __enqueue_in_driver). But there is a reason to do it earlier in QBUF, and is that userspace has no way to know if a exported dma-buf can be imported successfully and so relies on QBUF succeeding as indication that the dma-buf mapped. If QBUF fails, the application can fallback to another streaming I/O method. But moving the dma-buf mapping later when queueing the buffers can be too late for userspace to recover, since it may had dropped the buffer(s) already when it knows that the dma-buf mapping failed. So remove the TODO instead and change the comment to explain this. Suggested-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Javier Martinez Canillas authored
If the VIDIOC_QBUF ioctl fails due a wrong dmabuf length, it's useful to get the invalid and minimum lengths as a debug info. Before this patch: vb2-core: __qbuf_dmabuf: invalid dmabuf length for plane 1 After this patch: vb2-core: __qbuf_dmabuf: invalid dmabuf length 221248 for plane 1, minimum length 410880 Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Florian Echtler authored
The device hardware is always running at 60 FPS, so report this both via PARM_IOCTL and ENUM_FRAMEINTERVALS. [hans.verkuil@cisco.com: fix suspect indent checkpatch warning] [mchehab@s-opensource.com: fix a trivial merge conflict] Signed-off-by:
Martin Kaltenbrunner <modin@yuri.at> Signed-off-by:
Florian Echtler <floe@butterbrot.org> Signed-off-by:
-
Ricardo Ribalda authored
V4L2_CTRL_FLAG_VOLATILE behaviour when V4L2_CTRL_FLAG_EXECUTE_ON_WRITE is set was not properly explained. Also set some hyperlink to ease the Documentation browsing. Credit-to: Hans Verkuil <hansverk@cisco.com> [mchehab@s-opensource.com: fix a trivial merge conflict] Reported-by:
Dimitrios Katsaros <patcherwork@gmail.com> Signed-off-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by:
-
Hans Verkuil authored
Document that the cropping ioctls can return ENODATA if the operation isn't supported for the current input or output. Signed-off-by:
-
Hans Verkuil authored
Returning -EINVAL indicates wrong arguments, but that's not the case here. Returning -ENOTTY is also no option, since the ioctl is implemented, but it just is not valid for this input. So use -ENODATA instead. This is also used elsewhere when an ioctl isn't valid for a specific input. In this case G/S_SELECTION returned -EINVAL for the webcam input. That input doesn't support cropping, instead it uses ENUM_FRAMESIZES to enumerate a list of discrete frame sizes. Signed-off-by:
-
Hans Verkuil authored
The old cropcap video op is now only used to pass the pixelaspect ratio, so rename it. Signed-off-by:
-
Hans Verkuil authored
This is part of a final push to convert all drivers to g/s_selection. Signed-off-by:
-
Hans Verkuil authored
This is part of a final push to convert all drivers to g/s_selection. Signed-off-by:
-
Hans Verkuil authored
This is part of a final push to convert all drivers to g/s_selection. Signed-off-by:
-
Hans Verkuil authored
This is part of a final push to convert all drivers to g/s_selection. Signed-off-by:
-
Hans Verkuil authored
This is part of a final push to convert all drivers to g/s_selection. Signed-off-by:
-
Hans Verkuil authored
This is part of a final push to convert all drivers to g/s_selection. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans Verkuil authored
This is part of a final push to convert all drivers to g/s_selection. Signed-off-by:
-
Hans Verkuil authored
Replace all calls to g/s_crop by calls to the get/set_selection pad ops. Remove the old g/s_crop video ops since they are now no longer used. The cropcap video op is now only used to pass pixelaspect information, and is only needed if the pixelaspect is not 1:1. Signed-off-by:
-
Steve Longerbeam authored
Some targets control the ADV7180 power pin via a gpio, so add optional support for "powerdown" pin control. Signed-off-by:
Steve Longerbeam <steve_longerbeam@mentor.com> Tested-by:
Tim Harvey <tharvey@gateworks.com> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Steve Longerbeam authored
Replace hard-coded addresses with new register macro defines. No functional changes. Signed-off-by:
-
Markus Elfring authored
The video_unregister_device() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Markus Elfring authored
The spi_unregister_device() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The rc_free_device() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Hans Verkuil authored
Add support for reduced fps (i.e. 59.94 Hz instead of 60 Hz) for the HDMI output. Signed-off-by:
-
Bhaktipriya Shridhar authored
The workqueue work_queue is involved in EDID (Extended Display Identification Data) handling. It has a single work item(&state->edid_handler) and hence doesn't require ordering. It is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with the use of system_wq. &state->edid_handler is a self requeueing work item and it has been been sync cancelled in ad9389b_remove() to ensure that nothing is pending when the driver is disconnected. The unused label err_unreg has also been dropped. Signed-off-by:
Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Bhaktipriya Shridhar authored
The workqueue "work_thread" is involved in streaming the camera data. It has a single work item(&dev->work_struct) 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:
Frank Zago <frank@zago.net> Signed-off-by:
-
Bhaktipriya Shridhar authored
The workqueue "work_thread" is involved in streaming the camera data. It has a single work item(&sd->work_struct) 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:
-
Bhaktipriya Shridhar authored
The workqueue "work_thread" is involved in streaming the camera data. It has a single work item(&sd->work_struct) 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:
-
Bhaktipriya Shridhar authored
The workqueue "work_thread" is involved in updating the JPEG quality of the gspca_dev. 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:
-
Bhaktipriya Shridhar authored
The workqueue "workqueue" is involved in polling the pvrusb2 hardware (pvr2_hdw). It has a single work item(&hdw->workpoll) 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 pvr2_hdw_destroy to ensure that there are no pending tasks while disconnecting the driver. Signed-off-by:
-
