- 24 Aug, 2016 40 commits
-
-
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:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
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:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
Wolfram Sang <wsa-dev@sang-engineering.com> Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Wolfram Sang authored
kmalloc will print enough information in case of failure. Signed-off-by:
-
Julia Lawall authored
The venc_common_if structures are never modified, so declare them as const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Ezequiel Garcia authored
Currently, the hardware is not given a complete initial configuration. In order to fix this, this rather large commit reworks standard, frame format and input configuration. While at it, we introduce proper functions to configure each parameter, and as a result the code is a bit cleaner. Reported-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Hans Verkuil authored
Instead of referring to Y', Cb and Cr, it referred to Yc', Cbc and Crc, which were accidentally copied from the BT.2020 constant luminance text. Signed-off-by:
-
Hans Verkuil authored
The text of the note included text that shouldn't have been part of the note. Move that out of the note into the proper place. [mchehab@s-opensource.com: fix a trivial merge conflict] Signed-off-by:
-
