[media] cx18: Fix videobuf capture
When we moved to 3.0, we found that the cx18 driver was oopsing on close with: NULL pointer deref at: [ 2290.461009] Call Trace: [ 2290.461009] [<c046007b>] ? pm_qos_add_request+0xc/0x6e [ 2290.461009] [<c082631c>] __mutex_lock_common+0x87/0x125 [ 2290.461009] [<f8970e92>] ? cx18_queue_flush+0x31/0x87 [cx18] [ 2290.461009] [<c0436b85>] ? __might_sleep+0x29/0xe4 [ 2290.461009] [<c0826515>] __mutex_lock_slowpath+0x25/0x27 [ 2290.461009] [<c08264b2>] ? mutex_lock+0x2e/0x3b [ 2290.461009] [<c08264b2>] mutex_lock+0x2e/0x3b [ 2290.461009] [<f88d3137>] videobuf_queue_lock+0x13/0x15 [videobuf_core] [ 2290.461009] [<f88d3f86>] __videobuf_free+0xfc/0x112 [videobuf_core] [ 2290.461009] [<f89741e6>] cx18_v4l2_close+0x158/0x172 [cx18] [ 2290.461009] [<c0507522>] ? cpumask_next+0x1a/0x1d [ 2290.461009] [<f88a319d>] v4l2_release+0x35/0x52 [videodev] [ 2290.461009] [<c04f5717>] fput+0x100/0x1a5 [ 2290.461009] [<c04f2e09>] filp_close+0x5c/0x64 [ 2290.461009] [<c04f2e70>] sys_close+0x5f/0x93 [ 2290.461009] [<c082cd5f>] sysenter_do_call+0x12/0x28 Some digging showed that a merge at some previous point partially added broken mmap() support, causing this trace. Remove the broken code completely. On top of that, the calculation in place for "buffer full" depended on UYUV instead of HM12, while our GStreamer code was picking HM12 in some circumstances. Finally, the V4L2_CAP_STREAMING capability was never exposed. Patch it into the YUV encoder node only. Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Showing
Please register or sign in to comment