Add videobuf2 specific vb2_qbuf and vb2_dqbuf trace events that mirror the
v4l2_qbuf and v4l2_dqbuf trace events, only they include additional
information about queue fill state and are emitted right before the buffer
is enqueued in the driver or userspace is woken up. This allows to make
sense of the timeline of trace events in combination with others that might
be triggered by __enqueue_in_driver.

Also two new trace events vb2_buf_queue and vb2_buf_done are added,
allowing to trace the handover between videobuf2 framework and driver.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The queue owner will be used by videobuf2 trace events to determine and
record the device minor number. It is set in v4l2_m2m_reqbufs instead of
v4l2_m2m_ioctl_reqbufs because several drivers implement their own
vidioc_reqbufs handlers that still call v4l2_m2m_reqbufs directly.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Add a new helper function called v4l2_subdev_notify_event() which will
deliver the specified event to both the v4l2 subdev event queue as well as
to the notify callback. The former is typically used by userspace
applications to listen to notification events while the later is used by
bridge drivers. Combining both into the same function avoids boilerplate
code in subdev drivers.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

If the vdev pointer == NULL, then just return.

This makes it easier for subdev drivers to use this function without having to
check if the sd->devnode pointer is NULL or not.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

In many cases, refresh rate is not exact integer. In such cases,
fraction was lost and it used to print, say, 59 in case of 59.94.
Now, capturing the fraction up to 2 decimal places.
Signed-off-by: NPrashant Laddha <prladdha@cisco.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

We can simplify the code removing the if().

v4l2_ctr_new sets ctrls->elems to 1 when !ctrl->is_ptr.
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The last CVT standard introduced reduced blanking version 2 which is signaled by
a vsync of 8. Log this.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Added support for reduced blanking version 2 (RB v2) in cvt timings.
Standard specifies a fixed vsync pulse of 8 lines to indicate RB v2
timings. Vertical back porch is fixed at 6 lines and vertical front
porch is remainder of vertical blanking time.

For RB v2, horizontal blanking is fixed at 80 pixels. Horizontal sync
is fixed at 32. All horizontal timing counts (active pixels, front,
back porches) can be specified upto a precision of 1.

RB v2 allows for non standard aspect ratios. In RB v2 vsync does not
indicate aspect ratio. In absence of aspect ratio v4l2_detect_cvt()
cannot calculate image width from image height. Hence extending the
v4l2_detect_cvt() to pass image width in case of RB v2.
Signed-off-by: NPrashant Laddha <prladdha@cisco.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Use kernel.h macro definition.

Thanks to Julia Lawall for Coccinelle scripting support.
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Cc: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

Commit f61bf13b ("[media] vb2: add allow_zero_bytesused flag to the
vb2_queue struct") added a WARN_ONCE to catch usage of a deprecated API
using a zero value for v4l2_buffer.bytesused.

However, the condition is checked incorrectly, as the v4L2_buffer
bytesused field is supposed to be ignored for multiplanar buffers. This
results in spurious warnings when using the multiplanar API.

Fix it by checking v4l2_buffer.bytesused for uniplanar buffers and
v4l2_plane.bytesused for multiplanar buffers.

Fixes: f61bf13b ("[media] vb2: add allow_zero_bytesused flag to the vb2_queue struct")
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: stable@vger.kernel.org # for v4.0
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This reverts commit 48b25a3a.

That commit caused two regressions. The first is a BUG:

Jun 14 18:42:15 test-media kernel: [  115.972299] BUG: unable to handle kernel NULL pointer dereference at 0000000000000100
Jun 14 18:42:15 test-media kernel: [  115.972307] IP: [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070
Jun 14 18:42:15 test-media kernel: [  115.972316] PGD 0
Jun 14 18:42:15 test-media kernel: [  115.972318] Oops: 0000 [#1] PREEMPT SMP
Jun 14 18:42:15 test-media kernel: [  115.972321] Modules linked in: vivid v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media vmw_balloon vmw_vmci acpi_cpufreq processor button
Jun 14 18:42:15 test-media kernel: [  115.972333] CPU: 0 PID: 1542 Comm: v4l2-ctl Not tainted 4.1.0-rc3-test-media #1190
Jun 14 18:42:15 test-media kernel: [  115.972336] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
Jun 14 18:42:15 test-media kernel: [  115.972337] task: ffff880220ce4200 ti: ffff88021d16c000 task.ti: ffff88021d16c000
Jun 14 18:42:15 test-media kernel: [  115.972339] RIP: 0010:[<ffffffff810d5cd0>]  [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070
Jun 14 18:42:15 test-media kernel: [  115.972342] RSP: 0018:ffff88021d16f9b8  EFLAGS: 00010002
Jun 14 18:42:15 test-media kernel: [  115.972343] RAX: 0000000000000046 RBX: 0000000000000292 RCX: 0000000000000001
Jun 14 18:42:15 test-media kernel: [  115.972345] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000100
Jun 14 18:42:15 test-media kernel: [  115.972346] RBP: ffff88021d16fa88 R08: 0000000000000001 R09: 0000000000000000
Jun 14 18:42:15 test-media kernel: [  115.972347] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
Jun 14 18:42:15 test-media kernel: [  115.972348] R13: ffff880220ce4200 R14: 0000000000000100 R15: 0000000000000000
Jun 14 18:42:15 test-media kernel: [  115.972350] FS:  00007f2441e7f740(0000) GS:ffff880236e00000(0000) knlGS:0000000000000000
Jun 14 18:42:15 test-media kernel: [  115.972351] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jun 14 18:42:15 test-media kernel: [  115.972353] CR2: 0000000000000100 CR3: 0000000001e0b000 CR4: 00000000001406f0
Jun 14 18:42:15 test-media kernel: [  115.972424] Stack:
Jun 14 18:42:15 test-media kernel: [  115.972427]  ffff88021d16fa98 ffffffff810d6543 0000000000000006 0000000000000246
Jun 14 18:42:15 test-media kernel: [  115.972431]  ffff88021d16fa08 ffffffff810d532d ffff880220ce4a78 ffff880200000000
Jun 14 18:42:15 test-media kernel: [  115.972433]  ffff880200000001 0000000000000000 0000000000000001 000000000093a4a0
Jun 14 18:42:15 test-media kernel: [  115.972436] Call Trace:
Jun 14 18:42:15 test-media kernel: [  115.972440]  [<ffffffff810d6543>] ? __lock_acquire+0xb63/0x2070
Jun 14 18:42:15 test-media kernel: [  115.972443]  [<ffffffff810d532d>] ? mark_held_locks+0x6d/0xa0
Jun 14 18:42:15 test-media kernel: [  115.972445]  [<ffffffff810d37a8>] ? __lock_is_held+0x58/0x80
Jun 14 18:42:15 test-media kernel: [  115.972447]  [<ffffffff810d852c>] lock_acquire+0x6c/0xa0
Jun 14 18:42:15 test-media kernel: [  115.972452]  [<ffffffffa039f1f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
Jun 14 18:42:15 test-media kernel: [  115.972458]  [<ffffffff819b1a92>] down_read+0x42/0x60
Jun 14 18:42:15 test-media kernel: [  115.972460]  [<ffffffffa039f1f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
Jun 14 18:42:15 test-media kernel: [  115.972463]  [<ffffffff819af1b1>] ? mutex_lock_nested+0x2b1/0x560
Jun 14 18:42:15 test-media kernel: [  115.972467]  [<ffffffffa038fdc5>] ? vb2_queue_release+0x25/0x40 [videobuf2_core]
Jun 14 18:42:15 test-media kernel: [  115.972469]  [<ffffffffa039f1f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
Jun 14 18:42:15 test-media kernel: [  115.972472]  [<ffffffffa038b626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core]
Jun 14 18:42:15 test-media kernel: [  115.972475]  [<ffffffffa038fdd3>] vb2_queue_release+0x33/0x40 [videobuf2_core]
Jun 14 18:42:15 test-media kernel: [  115.972478]  [<ffffffffa038fe75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core]
Jun 14 18:42:15 test-media kernel: [  115.972481]  [<ffffffffa038feb9>] vb2_fop_release+0x29/0x50 [videobuf2_core]
Jun 14 18:42:15 test-media kernel: [  115.972485]  [<ffffffffa03ad372>] vivid_fop_release+0x92/0x230 [vivid]
Jun 14 18:42:15 test-media kernel: [  115.972491]  [<ffffffffa0358460>] v4l2_release+0x30/0x80 [videodev]
Jun 14 18:42:15 test-media kernel: [  115.972496]  [<ffffffff811a51d5>] __fput+0xe5/0x200
Jun 14 18:42:15 test-media kernel: [  115.972498]  [<ffffffff811a5339>] ____fput+0x9/0x10
Jun 14 18:42:15 test-media kernel: [  115.972501]  [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0
Jun 14 18:42:15 test-media kernel: [  115.972504]  [<ffffffff8108c670>] do_exit+0x3a0/0xaf0
Jun 14 18:42:15 test-media kernel: [  115.972507]  [<ffffffff819b3a9b>] ? _raw_spin_unlock_irq+0x2b/0x60
Jun 14 18:42:15 test-media kernel: [  115.972509]  [<ffffffff8108e0ff>] do_group_exit+0x4f/0xe0
Jun 14 18:42:15 test-media kernel: [  115.972511]  [<ffffffff8109a170>] get_signal+0x200/0x8c0
Jun 14 18:42:15 test-media kernel: [  115.972514]  [<ffffffff819b14b5>] ? __mutex_unlock_slowpath+0xf5/0x240
Jun 14 18:42:15 test-media kernel: [  115.972518]  [<ffffffff81002593>] do_signal+0x23/0x820
Jun 14 18:42:15 test-media kernel: [  115.972521]  [<ffffffff819b1609>] ? mutex_unlock+0x9/0x10
Jun 14 18:42:15 test-media kernel: [  115.972524]  [<ffffffffa0358648>] ? v4l2_ioctl+0x78/0xf0 [videodev]
Jun 14 18:42:15 test-media kernel: [  115.972526]  [<ffffffff819b4653>] ? int_very_careful+0x5/0x46
Jun 14 18:42:15 test-media kernel: [  115.972529]  [<ffffffff810d54bd>] ? trace_hardirqs_on_caller+0x15d/0x200
Jun 14 18:42:15 test-media kernel: [  115.972531]  [<ffffffff81002de0>] do_notify_resume+0x50/0x60
Jun 14 18:42:15 test-media kernel: [  115.972533]  [<ffffffff819b46a6>] int_signal+0x12/0x17
Jun 14 18:42:15 test-media kernel: [  115.972534] Code: ca 81 31 c0 e8 7a e2 8c 00 e8 aa 1d 8d 00 0f 1f 44 00 00 31 db 48 81 c4 a8 00 00 00 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 66 90 <49> 81 3e 40 4e 02 82 b8 00 00 00 00 44 0f 44 e0 41 83 ff 01 0f
Jun 14 18:42:15 test-media kernel: [  115.972567] RIP  [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070
Jun 14 18:42:15 test-media kernel: [  115.972569]  RSP <ffff88021d16f9b8>
Jun 14 18:42:15 test-media kernel: [  115.972570] CR2: 0000000000000100
Jun 14 18:42:15 test-media kernel: [  115.972573] ---[ end trace 25595c2b8560cb57 ]---
Jun 14 18:42:15 test-media kernel: [  115.972575] Fixing recursive fault but reboot is needed!

This can be reproduced by loading the vivid driver and running:

v4l2-ctl --stream-user

and pressing Ctrl-C. You may have to try a few times, but in my experience this BUG
is triggered quite quickly.

The second is a possible deadlock:

Jun 14 18:44:07 test-media kernel: [   49.376650] ======================================================
Jun 14 18:44:07 test-media kernel: [   49.376651] [ INFO: possible circular locking dependency detected ]
Jun 14 18:44:07 test-media kernel: [   49.376653] 4.1.0-rc3-test-media #1190 Not tainted
Jun 14 18:44:07 test-media kernel: [   49.376654] -------------------------------------------------------
Jun 14 18:44:07 test-media kernel: [   49.376655] v4l2-compliance/1468 is trying to acquire lock:
Jun 14 18:44:07 test-media kernel: [   49.376657]  (&mm->mmap_sem){++++++}, at: [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
Jun 14 18:44:07 test-media kernel: [   49.376665]
Jun 14 18:44:07 test-media kernel: [   49.376665] but task is already holding lock:
Jun 14 18:44:07 test-media kernel: [   49.376666]  (&q->mmap_lock){+.+...}, at: [<ffffffffa0398dc5>] vb2_queue_release+0x25/0x40 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376670]
Jun 14 18:44:07 test-media kernel: [   49.376670] which lock already depends on the new lock.
Jun 14 18:44:07 test-media kernel: [   49.376670]
Jun 14 18:44:07 test-media kernel: [   49.376671]
Jun 14 18:44:07 test-media kernel: [   49.376671] the existing dependency chain (in reverse order) is:
Jun 14 18:44:07 test-media kernel: [   49.376672]
Jun 14 18:44:07 test-media kernel: [   49.376672] -> #1 (&q->mmap_lock){+.+...}:
Jun 14 18:44:07 test-media kernel: [   49.376675]        [<ffffffff810d852c>] lock_acquire+0x6c/0xa0
Jun 14 18:44:07 test-media kernel: [   49.376682]        [<ffffffff819aef5e>] mutex_lock_nested+0x5e/0x560
Jun 14 18:44:07 test-media kernel: [   49.376689]        [<ffffffffa03934a2>] vb2_mmap+0x232/0x350 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376691]        [<ffffffffa0395a60>] vb2_fop_mmap+0x20/0x30 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376694]        [<ffffffffa0361102>] v4l2_mmap+0x52/0x90 [videodev]
Jun 14 18:44:07 test-media kernel: [   49.376698]        [<ffffffff81177e33>] mmap_region+0x3b3/0x5e0
Jun 14 18:44:07 test-media kernel: [   49.376701]        [<ffffffff81178377>] do_mmap_pgoff+0x317/0x400
Jun 14 18:44:07 test-media kernel: [   49.376703]        [<ffffffff81165320>] vm_mmap_pgoff+0x90/0xc0
Jun 14 18:44:07 test-media kernel: [   49.376708]        [<ffffffff81176867>] SyS_mmap_pgoff+0x1d7/0x280
Jun 14 18:44:07 test-media kernel: [   49.376709]        [<ffffffff81007f8d>] SyS_mmap+0x1d/0x20
Jun 14 18:44:07 test-media kernel: [   49.376714]        [<ffffffff819b44ae>] system_call_fastpath+0x12/0x76
Jun 14 18:44:07 test-media kernel: [   49.376716]
Jun 14 18:44:07 test-media kernel: [   49.376716] -> #0 (&mm->mmap_sem){++++++}:
Jun 14 18:44:07 test-media kernel: [   49.376718]        [<ffffffff810d79b3>] __lock_acquire+0x1fd3/0x2070
Jun 14 18:44:07 test-media kernel: [   49.376720]        [<ffffffff810d852c>] lock_acquire+0x6c/0xa0
Jun 14 18:44:07 test-media kernel: [   49.376721]        [<ffffffff819b1a92>] down_read+0x42/0x60
Jun 14 18:44:07 test-media kernel: [   49.376723]        [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
Jun 14 18:44:07 test-media kernel: [   49.376725]        [<ffffffffa0394626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376727]        [<ffffffffa0398dd3>] vb2_queue_release+0x33/0x40 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376729]        [<ffffffffa0398e75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376731]        [<ffffffffa0398eb9>] vb2_fop_release+0x29/0x50 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376733]        [<ffffffffa03b6372>] vivid_fop_release+0x92/0x230 [vivid]
Jun 14 18:44:07 test-media kernel: [   49.376737]        [<ffffffffa0361460>] v4l2_release+0x30/0x80 [videodev]
Jun 14 18:44:07 test-media kernel: [   49.376739]        [<ffffffff811a51d5>] __fput+0xe5/0x200
Jun 14 18:44:07 test-media kernel: [   49.376744]        [<ffffffff811a5339>] ____fput+0x9/0x10
Jun 14 18:44:07 test-media kernel: [   49.376746]        [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0
Jun 14 18:44:07 test-media kernel: [   49.376749]        [<ffffffff81002dd1>] do_notify_resume+0x41/0x60
Jun 14 18:44:07 test-media kernel: [   49.376752]        [<ffffffff819b46a6>] int_signal+0x12/0x17
Jun 14 18:44:07 test-media kernel: [   49.376754]
Jun 14 18:44:07 test-media kernel: [   49.376754] other info that might help us debug this:
Jun 14 18:44:07 test-media kernel: [   49.376754]
Jun 14 18:44:07 test-media kernel: [   49.376755]  Possible unsafe locking scenario:
Jun 14 18:44:07 test-media kernel: [   49.376755]
Jun 14 18:44:07 test-media kernel: [   49.376756]        CPU0                    CPU1
Jun 14 18:44:07 test-media kernel: [   49.376757]        ----                    ----
Jun 14 18:44:07 test-media kernel: [   49.376758]   lock(&q->mmap_lock);
Jun 14 18:44:07 test-media kernel: [   49.376759]                                lock(&mm->mmap_sem);
Jun 14 18:44:07 test-media kernel: [   49.376760]                                lock(&q->mmap_lock);
Jun 14 18:44:07 test-media kernel: [   49.376761]   lock(&mm->mmap_sem);
Jun 14 18:44:07 test-media kernel: [   49.376763]
Jun 14 18:44:07 test-media kernel: [   49.376763]  *** DEADLOCK ***
Jun 14 18:44:07 test-media kernel: [   49.376763]
Jun 14 18:44:07 test-media kernel: [   49.376764] 2 locks held by v4l2-compliance/1468:
Jun 14 18:44:07 test-media kernel: [   49.376765]  #0:  (&dev->mutex#3){+.+.+.}, at: [<ffffffffa0398e0a>] _vb2_fop_release+0x2a/0xb0 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376770]  #1:  (&q->mmap_lock){+.+...}, at: [<ffffffffa0398dc5>] vb2_queue_release+0x25/0x40 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376773]
Jun 14 18:44:07 test-media kernel: [   49.376773] stack backtrace:
Jun 14 18:44:07 test-media kernel: [   49.376776] CPU: 2 PID: 1468 Comm: v4l2-compliance Not tainted 4.1.0-rc3-test-media #1190
Jun 14 18:44:07 test-media kernel: [   49.376777] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
Jun 14 18:44:07 test-media kernel: [   49.376779]  ffffffff8279e0b0 ffff88021d6f7ba8 ffffffff819a7aac 0000000000000011
Jun 14 18:44:07 test-media kernel: [   49.376781]  ffffffff8279e0b0 ffff88021d6f7bf8 ffffffff819a3964 ffff88021d6f7bd8
Jun 14 18:44:07 test-media kernel: [   49.376783]  ffff8800ac8aa100 0000000000000002 ffff8800ac8aa9a0 0000000000000002
Jun 14 18:44:07 test-media kernel: [   49.376785] Call Trace:
Jun 14 18:44:07 test-media kernel: [   49.376788]  [<ffffffff819a7aac>] dump_stack+0x4f/0x7b
Jun 14 18:44:07 test-media kernel: [   49.376792]  [<ffffffff819a3964>] print_circular_bug+0x20f/0x251
Jun 14 18:44:07 test-media kernel: [   49.376793]  [<ffffffff810d79b3>] __lock_acquire+0x1fd3/0x2070
Jun 14 18:44:07 test-media kernel: [   49.376795]  [<ffffffff810d6543>] ? __lock_acquire+0xb63/0x2070
Jun 14 18:44:07 test-media kernel: [   49.376797]  [<ffffffff810d37a8>] ? __lock_is_held+0x58/0x80
Jun 14 18:44:07 test-media kernel: [   49.376798]  [<ffffffff810d852c>] lock_acquire+0x6c/0xa0
Jun 14 18:44:07 test-media kernel: [   49.376800]  [<ffffffffa03a81f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
Jun 14 18:44:07 test-media kernel: [   49.376802]  [<ffffffff819b1a92>] down_read+0x42/0x60
Jun 14 18:44:07 test-media kernel: [   49.376803]  [<ffffffffa03a81f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
Jun 14 18:44:07 test-media kernel: [   49.376805]  [<ffffffff819af1b1>] ? mutex_lock_nested+0x2b1/0x560
Jun 14 18:44:07 test-media kernel: [   49.376807]  [<ffffffffa0398dc5>] ? vb2_queue_release+0x25/0x40 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376808]  [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc]
Jun 14 18:44:07 test-media kernel: [   49.376810]  [<ffffffffa0398e0a>] ? _vb2_fop_release+0x2a/0xb0 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376812]  [<ffffffffa0394626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376814]  [<ffffffffa0398dd3>] vb2_queue_release+0x33/0x40 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376816]  [<ffffffffa0398e75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376818]  [<ffffffffa0398eb9>] vb2_fop_release+0x29/0x50 [videobuf2_core]
Jun 14 18:44:07 test-media kernel: [   49.376820]  [<ffffffffa03b6372>] vivid_fop_release+0x92/0x230 [vivid]
Jun 14 18:44:07 test-media kernel: [   49.376822]  [<ffffffffa0361460>] v4l2_release+0x30/0x80 [videodev]
Jun 14 18:44:07 test-media kernel: [   49.376824]  [<ffffffff811a51d5>] __fput+0xe5/0x200
Jun 14 18:44:07 test-media kernel: [   49.376825]  [<ffffffff819b4653>] ? int_very_careful+0x5/0x46
Jun 14 18:44:07 test-media kernel: [   49.376827]  [<ffffffff811a5339>] ____fput+0x9/0x10
Jun 14 18:44:07 test-media kernel: [   49.376828]  [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0
Jun 14 18:44:07 test-media kernel: [   49.376830]  [<ffffffff81002dd1>] do_notify_resume+0x41/0x60
Jun 14 18:44:07 test-media kernel: [   49.376832]  [<ffffffff819b46a6>] int_signal+0x12/0x17

This can be triggered by loading the vivid module with the module option 'no_error_inj=1'
and running 'v4l2-compliance -s5'. Again, it may take a few attempts to trigger this
but for me it happens quite quickly.

Without this patch I cannot reproduce these two issues. So reverting is the best
solution for now.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

V4L2 async sub-devices are currently matched (OF case) based on the struct
device_node pointer in struct device. LED devices may have more than one
LED, and in that case the OF node to match is not directly the device's
node, but a LED's node.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

Extend detect_cvt/gtf API to indicate the format type (interlaced
or progressive). In case of interlaced, the vertical front and back
porch and vsync values for both (odd,even) fields are considered to
derive image height. Populated vsync, vertical front, back porch
values in bt timing structure for even and odd fields and updated
the flags appropriately.

Also modified the functions calling the detect_cvt/gtf(). As of now
these functions are calling detect_cvt/gtf() with interlaced flag
set to false.

Cc: Martin Bugge <marbugge@cisco.com>
Cc: Mats Randgaard <matrandg@cisco.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NPrashant Laddha <prladdha@cisco.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The v4l2_print_dv_timings() didn't log the interlaced format correctly. The timings
for the bottom field weren't logged and the fields per second value was half of what
it should have been.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Currently, in gtf hblank calculations, the rounding is used twice,
one at intermediate division and one at final state where hblank
is rounded to nearest multiple of twice cell granularity. This
error got introduced in 'commit d7ed5a3d ("[media]
v4l2-dv-timings: fix rounding in hblank and hsync calculation"),
where it missed combining the rounding step. Correcting the same
in this patch.
Signed-off-by: NPrashant Laddha <prladdha@cisco.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This was never added for some reason, so add it now.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

If userspace passed the invalid buffer type 0 to the kernel, then the
kernel log would show 'type=(null)' since there was no string defined
for type 0. Fix this.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This field was never cleared by the kernel making future extensions
hard to implement. Clear it now.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Current v4l2_of_parse_parallel_bus function attempts to parse the
DT properties for the parallel bus as well as BT656 bus.
If the pclk-sample property is defined for the BT656 bus, it is still
marked as a parallel bus.
Fix this by parsing the pclk after the bus_type is selected.
Only when hsync or vsync properties are specified, the bus_type should
be set to V4L2_MBUS_PARALLEL.
Signed-off-by: NNikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

In the past the transfer function was implied by the colorspace. However,
it is an independent entity in its own right. Add support for explicitly
choosing the transfer function.

This change will allow us to represent linear RGB (as is used by openGL), and
it will make it easier to work with decoded video material since most codecs
store the transfer function as a separate property as well.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

U8 and U16LE format human readable names were translated with string
containing emulated word. These strings were taken from msi2500 driver,
where those formats were emulated (after module parameter is set). But
on API correct names should be used, without any special case notes.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

16 bit greyscale format, structured in Big Endian. Such a format can be
converted into a PMN image just by adding a header.
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

When sg_alloc_table_from_pages() does not fail it returns a sg_table
structure with nents and nents_orig initialized to the same value.

dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.

The output of dma_map, should be used to transverse the scatter list.

dma_unmap_sg needs the value passed to dma_map_sg (nents_orig).

sg_free_tables uses also orig_nent.

This patch fix the file to follow this paradigm.
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

vb2_buffer_done() already allows STATE_QUEUED, but currently only when not
streaming. It is useful to allow it while streaming as well, as this makes
it possible for drivers to requeue buffers while waiting for a stable
video signal.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The intermediate calculation in the expression for hblank can exceed
32 bit signed range. This overflow can lead to negative values for
hblank. Typecasting intermediate variable to higher precision.

Cc: Martin Bugge <marbugge@cisco.com>
Signed-off-by: NPrashant Laddha <prladdha@cisco.com>
[hans.verkuil@cisco.com: made the denominator u32, since that's what div_u64 expects]
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To reenable dequeuing on the capture queue, the driver must explicitly
call vb2_clear_last_buffer_queued. The last buffer queued flag is
cleared automatically during STREAMOFF.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NKamil Debski <k.debski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Currently vb2 core acquires mmap_sem just around call to
__qbuf_userptr(). However since commit f035eb4e (videobuf2: fix
lockdep warning) it isn't necessary to acquire it so early as we no
longer have to drop queue mutex before acquiring mmap_sem. So push
acquisition of mmap_sem down into .get_userptr and .put_userptr memops
so that the semaphore is acquired for a shorter time and it is clearer
what it is needed for.
Signed-off-by: NJan Kara <jack@suse.cz>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This change will not change timing calculation. In CVT generator
spreadsheet the nominal value of hsync (as a percentage of line)
is 8 percent.

Cc: Martin Bugge <marbugge@cisco.com>
Signed-off-by: NPrashant Laddha <prladdha@cisco.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Wrong values of hfreq and image height can lead to strange timings.
Avoid timing calculations for such values.

Suggested By: Martin Bugge <marbugge@cisco.com>

Cc: Martin Bugge <marbugge@cisco.com>
Signed-off-by: NPrashant Laddha <prladdha@cisco.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Changed the rounding calculation for hblank and hsync to match it
to equations in cvt and gtf standards.

In cvt calculation, hsync needs to be rounded down.

In gtf calculations, hblank needs to be rounded to nearest multiple
of twice the cell granularity and hsync needs to be rounded to the
nearest multiple of cell granularity.

Cc: Martin Bugge <marbugge@cisco.com>
Signed-off-by: NPrashant Laddha <prladdha@cisco.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Changed the rounding offsets used in vsync_bp calculation in cvt and
gtf timings. The results for vsync_bp should now match with results
from timing generator spreadsheets for cvt and gtf standards.

In the vsync_bp calculation for cvt, always round down the value of
(CVT_MIN_VSYNC_BP / h_period_est) and then add 1. It thus, reflects
the equation used in timing generator spreadsheet. Using 1999999 as
rounding offset, could pontentially lead to bumping up the vsync_bp
value by extra 1.

In the vsync_bp calculations for gtf, instead of round up or round
down, round the (CVT_MIN_VSYNC_BP / h_period_est) to the nearest
integer.

Thanks to Martin Bugge <marbugge@cisco.com> for validating with
standards and suggestions on equations.

Cc: Martin Bugge <marbugge@cisco.com>
Signed-off-by: NPrashant Laddha <prladdha@cisco.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

If NO_DMA=y:

    ERROR: "dma_unmap_sg" [drivers/media/v4l2-core/videobuf2-dma-sg.ko] undefined!
    ERROR: "dma_map_sg" [drivers/media/v4l2-core/videobuf2-dma-sg.ko] undefined!
    ERROR: "dma_sync_sg_for_cpu" [drivers/media/v4l2-core/videobuf2-dma-sg.ko] undefined!

VIDEOBUF2_DMA_SG cannot be enabled manually by the user, it's always
selected automatically by drivers that need it. Several of those drivers
already have an explicit dependency on HAS_DMA.

Make VIDEOBUF2_DMA_SG depend on HAS_DMA. This makes it easier to find
drivers that select VIDEOBUF2_DMA_SG without depending on HAS_DMA, as
Kconfig will give a warning.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The changeset ba300204 added a logic at the core to fill
the format description, however, a break is missing on one of
the formats, as reported by smatch:
	drivers/media/v4l2-core/v4l2-ioctl.c:1211 v4l_fill_fmtdesc() warn: missing break? reassigning 'descr'
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The descriptions used in drivers for the formats returned with ENUM_FMT
are all over the place.

So instead allow the core to fill them in if the driver didn't. This
allows drivers to drop the description and flags.

Based on an earlier patch from Philipp Zabel:
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/81411Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The link-frequencies property is a variable length array of link frequencies
in an endpoint. The array is needed by an increasing number of drivers, so
it makes sense to add it to struct v4l2_of_endpoint.

However, the length of the array is variable and the size of struct
v4l2_of_endpoint is fixed since it is allocated by the caller. The options
here are

1. to define a fixed maximum limit of link frequencies that has to be the
global maximum of all boards. This is seen as problematic since the maximum
could be largish, and everyone hitting the problem would need to submit a
patch to fix it, or

2. parse the property in every driver. This doesn't sound appealing as two
of the three implementations submitted to linux-media were wrong, and one of
them was even merged before this was noticed, or

3. change the interface so that allocating and releasing memory according to
the size of the array is possible. This is what the patch does.

v4l2_of_alloc_parse_endpoint() is just like v4l2_of_parse_endpoint(), but it
will allocate the memory resources needed to store struct v4l2_of_endpoint
and the additional arrays pointed to by this struct. A corresponding release
function v4l2_of_free_endpoint() is provided to release the memory allocated
by v4l2_of_alloc_parse_endpoint().

In addition to this, the link-frequencies property is parsed as well, and
the result is stored to struct v4l2_of_endpoint field link_frequencies.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Zero the entire struct starting from bus_type. As more fields are added, no
changes will be needed in the function to reset their value explicitly.
Signed-off-by: NSakari Ailus <sakari.ailus@iki.fi>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

My 'allmodconfig' build is _almost_ free of warnings, and most of the
remaining ones are for legacy drivers that just do bad things that I
can't find it in my black heart to care too much about.  But this one
was just annoying me:

   drivers/media/v4l2-core/videobuf2-core.c:3256:26: warning: unused variable ‘fileio’ [-Wunused-variable]

because commit 0e661006 ("[media] vb2: fix 'UNBALANCED' warnings
when calling vb2_thread_stop()") removed all users of 'fileio' and
instead calls "__vb2_cleanup_fileio(q)" to clean up q->fileio.  But the
now unused 'fileio' variable was left around.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>