[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>