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>

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>

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>

At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.

Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().

While at it, unite dma_buf_export_named() with dma_buf_export(), and
change all callers accordingly.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: NDaniel Thompson <daniel.thompson@linaro.org>
Acked-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>

If NO_DMA=y:

drivers/built-in.o: In function `vb2_vmalloc_dmabuf_ops_detach':
videobuf2-vmalloc.c:(.text+0x6f11b0): undefined reference to `dma_unmap_sg'
drivers/built-in.o: In function `vb2_vmalloc_dmabuf_ops_map':
videobuf2-vmalloc.c:(.text+0x6f1266): undefined reference to `dma_unmap_sg'
videobuf2-vmalloc.c:(.text+0x6f1282): undefined reference to `dma_map_sg'

As we don't want to make the core VIDEOBUF2_VMALLOC depend on HAS_DMA
(it's v4l2 core code, and selected by a lot of drivers), stub out the
DMA support if HAS_DMA is not set.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Fix this warning:

drivers/media/v4l2-core/videobuf2-vmalloc.c:98:28: warning: incorrect type in assignment (different address spaces)
drivers/media/v4l2-core/videobuf2-vmalloc.c:158:28: warning: incorrect type in argument 1 (different address spaces)

The warning is correct, but we have no other choice here to forcibly cast.
At least it is now explicit that such a cast is needed.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The vb2_put_vma() 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: NMarkus Elfring <elfring@users.sourceforge.net>
Acked-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>

Add support for DMABUF exporting to the vb2-vmalloc implementation.

All memory models now have support for both importing and exporting of DMABUFs.
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Acked-by: NPawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

This is needed for the next patch where the dma-sg alloc memop needs
to know the dma_dir.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NPawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

The 'write' argument is very ambiguous. I first assumed that if it is 1,
then we're doing video output but instead it meant the reverse.

Since it is used to setup the dma_dir value anyway it is now replaced by
the correct dma_dir value which is unambiguous.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NPawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>

Some drivers have special memory requirements for their buffers, usually
related to DMA (e.g. GFP_DMA or __GFP_DMA32). Make it possible to specify
additional GFP flags for those buffers by adding a gfp_flags field to
vb2_queue.
Note that this field will be replaced in the future with a different
mechanism, but that is still work in progress and we need this feature
now so we won't be able to convert drivers with such requirements to vb2.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Acked-by: NFederico Vaga <federico.vaga@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch adds support for importing DMABUF files for
vmalloc allocator in Videobuf2.
Signed-off-by: NTomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Tested-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently, the v4l2 core is mixed together with other non-core drivers.
Move them into a separate directory.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix "symbol 'vb2_vmalloc_memops' was not declared. Should it be static?"
sparse warning.
Signed-off-by: NNicolas Thery <nicolas.thery@st.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some video devices need to use contiguous memory which is
not backed by pages as it happens with vmalloc. This patch
provides USERPTR handling for those devices.
Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch adds support for user pointer memory buffers to vmalloc
videobuf2 allocator.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NPawel Osciak <pawel@osciak.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add an implementation of contiguous virtual memory allocator and handling
routines for videobuf2, implemented on top of vmalloc()/vfree() calls.
Signed-off-by: NPawel Osciak <p.osciak@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
CC: Pawel Osciak <pawel@osciak.com>
Reviewed-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>