- 24 Aug, 2016 40 commits
-
-
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:
Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Acked-by:
Tejun Heo <tj@kernel.org> Acked-by:
Frank Zago <frank@zago.net> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
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:
-
Hans Verkuil authored
The V4L2_YCBCR_ENC_SYCC encoding is identical to V4L2_YCBCR_ENC_601. Remove V4L2_YCBCR_ENC_SYCC from the documentation since it should not be used. Signed-off-by:
-
Hans Verkuil authored
This define is a duplicate of V4L2_YCBCR_ENC_601. So mark it as 'should not be used' and put it under #ifndef __KERNEL__ to prevent drivers from referring to it. Signed-off-by:
-
Hans Verkuil authored
The SYCC Y'CbCr encoding is identical to the 601 encoding. Since the SYCC define is about to be removed for use in the kernel we need to drop it in the TPG code as well. This patch also adds a 4th decimal to the 601 conversion matrix. That was specified by the sYCC spec and it makes sense to use this across the board. [mchehab@s-opensource.com: fix conflicts with LaTeX math expression patch] Signed-off-by:
-
