| Age | Commit message (Collapse) | Author |
|---|
|
In videobuf2 dma-sg memory types the prepare and finish ops, instead
of passing the number of entries in the original scatterlist as the
"nents" parameter to dma_sync_sg_for_device() and dma_sync_sg_for_cpu(),
the value returned by dma_map_sg() was used. Albeit this has been
suggested in comments of some implementations (which have since been
corrected), this is wrong.
Fixes: d790b7eda953 ("vb2-dma-sg: move dma_(un)map_sg here")
Cc: stable@vger.kernel.org # for v3.19 and up
Signed-off-by: Tiffany Lin <tiffany.lin@mediatek.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Make videobuf2-v4l2 as a wrapper of videobuf2-core for v4l2-use.
And replace videobuf2-core.h with videobuf2-v4l2.h.
This renaming change should be accompanied by the modifications
of all device drivers that include videobuf2-core.h.
It can be done with just running this shell script.
replace()
{
str1=$1
str2=$2
dir=$3
for file in $(find $dir -name *.h -o -name *.c -o -name Makefile)
do
echo $file
sed "s/$str1/$str2/g" $file > $file.out
mv $file.out $file
done
}
replace "videobuf2-core" "videobuf2-v4l2" "include/media/"
replace "videobuf2-core" "videobuf2-v4l2" "drivers/media/"
replace "videobuf2-core" "videobuf2-v4l2" "drivers/usb/gadget/"
replace "videobuf2-core" "videobuf2-v4l2" "drivers/staging/media/"
Signed-off-by: Junghak Sung <jh1009.sung@samsung.com>
Signed-off-by: Geunyoung Kim <nenggun.kim@samsung.com>
Acked-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Acked-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Currently vb2 core acquires mmap_sem just around call to
__qbuf_userptr(). However since commit f035eb4e976ef5 (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 memop so that the
semaphore is acquired for a shorter time and it is clearer what it is
needed for.
Note that we also need mmap_sem in .put_userptr memop since that ends up
calling vb2_put_vma() which calls vma->vm_ops->close() which should be
called with mmap_sem held. However we didn't hold mmap_sem in some code
paths anyway (e.g. when called via vb2_ioctl_reqbufs() ->
__vb2_queue_free() -> vb2_dma_sg_put_userptr()) and getting mmap_sem in
put_userptr() introduces a lock inversion with queue->mmap_lock in the
above mentioned call path.
Luckily this whole locking mess will get resolved once we convert
videobuf2 core to the new mm helper which avoids the need for mmap_sem
in .put_userptr memop altogether.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
This reverts commit 48b25a3a713b90988b6882d318f7c0a6bed9aabc.
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: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Mauro 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: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Currently vb2 core acquires mmap_sem just around call to
__qbuf_userptr(). However since commit f035eb4e976ef5 (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: Jan Kara <jack@suse.cz>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro 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: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
|
|
By default dma_map_sg syncs the mapped buffer to the device. But
buf_prepare expects a buffer syncs for the cpu and the buffer
will be synced to the device in the prepare memop.
The reverse is true for dma_unmap_sg, buf_finish and the finish
memop.
To prevent unnecessary syncs we ask dma_(un)map_sg to skip the
sync.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Add DMABUF export support to vb2-dma-sg.
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Add support for importing dmabuf to videobuf2-dma-sg.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
This moves dma_(un)map_sg to the get_userptr/put_userptr and alloc/put
memops of videobuf2-dma-sg.c and adds dma_sync_sg_for_device/cpu to the
prepare/finish memops.
Now that vb2-dma-sg will sync the buffers for you in the prepare/finish
memops we can drop that from the drivers that use dma-sg.
For the solo6x10 driver that was a bit more involved because it needs to
copy JPEG or MPEG headers to the buffer before returning it to userspace,
and that cannot be done in the old place since the buffer there is still
setup for DMA access, not for CPU access. However, the buf_finish
op is the ideal place to do this. By the time buf_finish is called
the buffer is available for CPU access, so copying to the buffer is fine.
[mchehab@osg.samsung.com: Fix a compilation breakage:
drivers/media/v4l2-core/videobuf2-dma-sg.c:150:19: error: 'struct vb2_dma_sg_buf' has no member named 'dma_sgt']
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Require that dma-sg also uses an allocation context. This is in preparation
for adding prepare/finish memops to sync the memory between DMA and CPU.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro 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: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Pawel Osciak <pawel@osciak.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
sg_alloc_table_from_pages() only allocates a sg_table, so it should just use
GFP_KERNEL, not gfp_flags. If gfp_flags contains __GFP_DMA32 then mm/sl[au]b.c
will call BUG_ON:
[ 358.027515] ------------[ cut here ]------------
[ 358.027546] kernel BUG at mm/slub.c:1416!
[ 358.027558] invalid opcode: 0000 [#1] PREEMPT SMP
[ 358.027576] Modules linked in: mt2131 s5h1409 tda8290 tuner cx25840 cx23885 btcx_risc altera_ci tda18271 altera_stapl videobuf2_dvb tveeprom cx2341x videobuf2_dma_sg dvb_core rc_core videobuf2_memops videobuf2_core nouveau zr36067 videocodec v4l2_common videodev media x86_pkg_temp_thermal cfbfillrect cfbimgblt cfbcopyarea ttm drm_kms_helper processor button isci
[ 358.027712] CPU: 19 PID: 3654 Comm: cat Not tainted 3.16.0-rc6-telek #167
[ 358.027723] Hardware name: ASUSTeK COMPUTER INC. Z9PE-D8 WS/Z9PE-D8 WS, BIOS 5404 02/10/2014
[ 358.027741] task: ffff880897c7d960 ti: ffff88089b4d4000 task.ti: ffff88089b4d4000
[ 358.027753] RIP: 0010:[<ffffffff81196040>] [<ffffffff81196040>] new_slab+0x280/0x320
[ 358.027776] RSP: 0018:ffff88089b4d7ae8 EFLAGS: 00010002
[ 358.027787] RAX: ffff880897c7d960 RBX: 0000000000000000 RCX: ffff88089b4d7b50
[ 358.027798] RDX: 00000000ffffffff RSI: 0000000000000004 RDI: ffff88089f803b00
[ 358.027809] RBP: ffff88089b4d7bb8 R08: 0000000000000000 R09: 0000000100400040
[ 358.027821] R10: 0000160000000000 R11: ffff88109bc02c40 R12: 0000000000000001
[ 358.027832] R13: ffff88089f8000c0 R14: ffff88089f803b00 R15: ffff8810bfcf4be0
[ 358.027845] FS: 00007f83fe5c0700(0000) GS:ffff8810bfce0000(0000) knlGS:0000000000000000
[ 358.027858] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 358.027868] CR2: 0000000001dfd568 CR3: 0000001097d5a000 CR4: 00000000000407e0
[ 358.027878] Stack:
[ 358.027885] ffffffff81198860 ffff8810bfcf4be0 ffff880897c7d960 0000000000001b00
[ 358.027905] ffff880897c7d960 0000000000000000 ffff8810bfcf4bf0 0000000000000000
[ 358.027924] 0000000000000000 0000000100000100 ffffffff813ef84a 00000004ffffffff
[ 358.027944] Call Trace:
[ 358.027956] [<ffffffff81198860>] ? __slab_alloc+0x400/0x4e0
[ 358.027973] [<ffffffff813ef84a>] ? sg_kmalloc+0x1a/0x30
[ 358.027985] [<ffffffff81198f17>] __kmalloc+0x127/0x150
[ 358.027997] [<ffffffff813ef84a>] ? sg_kmalloc+0x1a/0x30
[ 358.028009] [<ffffffff813ef84a>] sg_kmalloc+0x1a/0x30
[ 358.028023] [<ffffffff813eff84>] __sg_alloc_table+0x74/0x180
[ 358.028035] [<ffffffff813ef830>] ? sg_kfree+0x20/0x20
[ 358.028048] [<ffffffff813f00af>] sg_alloc_table+0x1f/0x60
[ 358.028061] [<ffffffff813f0174>] sg_alloc_table_from_pages+0x84/0x1f0
[ 358.028077] [<ffffffffa007c3f9>] vb2_dma_sg_alloc+0x159/0x230 [videobuf2_dma_sg]
[ 358.028095] [<ffffffffa003d55a>] __vb2_queue_alloc+0x10a/0x680 [videobuf2_core]
[ 358.028113] [<ffffffffa003e110>] __reqbufs.isra.14+0x220/0x3e0 [videobuf2_core]
[ 358.028130] [<ffffffffa003e79d>] __vb2_init_fileio+0xbd/0x380 [videobuf2_core]
[ 358.028147] [<ffffffffa003f563>] __vb2_perform_fileio+0x5b3/0x6e0 [videobuf2_core]
[ 358.028164] [<ffffffffa003f871>] vb2_fop_read+0xb1/0x100 [videobuf2_core]
[ 358.028184] [<ffffffffa06dd2e5>] v4l2_read+0x65/0xb0 [videodev]
[ 358.028198] [<ffffffff811a243f>] vfs_read+0x8f/0x170
[ 358.028210] [<ffffffff811a30a1>] SyS_read+0x41/0xb0
[ 358.028224] [<ffffffff818f02e9>] system_call_fastpath+0x16/0x1b
[ 358.028234] Code: 66 90 e9 dc fd ff ff 0f 1f 40 00 41 8b 4d 68 e9 d5 fe ff ff 0f 1f 80 00 00 00 00 f0 41 80 4d 00 40 e9 03 ff ff ff 0f 1f 44 00 00 <0f> 0b 66 0f 1f 44 00 00 44 89 c6 4c 89 45 d0 e8 0c 82 ff ff 48
[ 358.028415] RIP [<ffffffff81196040>] new_slab+0x280/0x320
[ 358.028432] RSP <ffff88089b4d7ae8>
[ 358.032208] ---[ end trace 6443240199c706e4 ]---
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: stable@vger.kernel.org # for v3.13 and up
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
vb2_get_vma() copy the content of the vma to a new structure but set
some of its pointers to NULL.
One of this pointer is used by follow_pte() called by follow_pfn()
on io memory.
This can lead to a NULL pointer derreference.
The version of vma that has not been cleared must be used.
[ 406.143320] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
[ 406.143427] IP: [<ffffffff8115204c>] follow_pfn+0x2c/0x70
[ 406.143491] PGD 6c3f0067 PUD 6c3ef067 PMD 0
[ 406.143546] Oops: 0000 [#1] SMP
[ 406.143587] Modules linked in: qtec_mem qt5023_video qtec_testgen qtec_xform videobuf2_core gpio_xilinx videobuf2_vmalloc videobuf2_dma_sg qtec_cmosis videobuf2_memops qtec_pcie qtec_white fglrx(PO) qt5023 spi_xilinx spi_bitbang
[ 406.143852] CPU: 0 PID: 299 Comm: tracker Tainted: P O 3.13.0-qtec-standard #10
[ 406.143927] Hardware name: QTechnology QT5022/QT5022, BIOS PM_2.1.0.309 X64 04/04/2013
[ 406.144000] task: ffff880085c82d60 ti: ffff880085abe000 task.ti: ffff880085abe000
[ 406.144067] RIP: 0010:[<ffffffff8115204c>] [<ffffffff8115204c>] follow_pfn+0x2c/0x70
[ 406.144145] RSP: 0018:ffff880085abf888 EFLAGS: 00010296
[ 406.144195] RAX: 0000000000000000 RBX: ffff880085abf8e0 RCX: ffff880085abf888
[ 406.144260] RDX: ffff880085abf890 RSI: 00007fc52e173000 RDI: ffff8800863cbe40
[ 406.144325] RBP: ffff880085abf8a8 R08: 0000000000000018 R09: ffff8800863cbf00
[ 406.144388] R10: ffff880086703b80 R11: 00000000000001e0 R12: 0000000000018000
[ 406.144452] R13: 0000000000000000 R14: ffffea0000000000 R15: ffff88015922fea0
[ 406.144517] FS: 00007fc536e7c740(0000) GS:ffff88015ec00000(0000) knlGS:0000000000000000
[ 406.144591] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 406.144644] CR2: 0000000000000040 CR3: 0000000066c9d000 CR4: 00000000000007f0
[ 406.144708] Stack:
[ 406.144731] 0000000000018000 00007fc52e18b000 0000000000000000 00007fc52e173000
[ 406.144813] ffff880085abf918 ffffffffa083b2fd ffff880085ab1ba8 0000000000000000
[ 406.144894] 0000000000000000 0000000100000000 ffff880085abf928 ffff880159a20800
[ 406.144976] Call Trace:
[ 406.145011] [<ffffffffa083b2fd>] vb2_dma_sg_get_userptr+0x14d/0x310 [videobuf2_dma_sg]
[ 406.145089] [<ffffffffa08507df>] __qbuf_userptr+0xbf/0x3e0 [videobuf2_core]
[ 406.147229] [<ffffffffa0041454>] ? mc_heap_lock_memory+0x1f4/0x490 [fglrx]
[ 406.149234] [<ffffffff813428f3>] ? cpumask_next_and+0x23/0x50
[ 406.151223] [<ffffffff810b2e38>] ? enqueue_task_fair+0x658/0xde0
[ 406.153199] [<ffffffff81061888>] ? native_smp_send_reschedule+0x48/0x60
[ 406.155184] [<ffffffff815836b9>] ? get_ctrl+0xa9/0xd0
[ 406.157161] [<ffffffff8116f4e4>] ? __kmalloc+0x1a4/0x1b0
[ 406.159135] [<ffffffffa0850b9c>] ? __vb2_queue_alloc+0x9c/0x4a0 [videobuf2_core]
[ 406.161130] [<ffffffffa0852d08>] __buf_prepare+0x1a8/0x210 [videobuf2_core]
[ 406.163171] [<ffffffffa0854c57>] __vb2_qbuf+0x27/0xcc [videobuf2_core]
[ 406.165229] [<ffffffffa0851dfd>] vb2_queue_or_prepare_buf+0x1ed/0x270 [videobuf2_core]
[ 406.167325] [<ffffffffa0854c30>] ? vb2_ioctl_querybuf+0x30/0x30 [videobuf2_core]
[ 406.169419] [<ffffffffa0851e9c>] vb2_qbuf+0x1c/0x20 [videobuf2_core]
[ 406.171508] [<ffffffffa0851ef8>] vb2_ioctl_qbuf+0x58/0x70 [videobuf2_core]
[ 406.173604] [<ffffffff8157d3a8>] v4l_qbuf+0x48/0x60
[ 406.175681] [<ffffffff8157b29c>] __video_do_ioctl+0x2bc/0x340
[ 406.177779] [<ffffffff8116f43c>] ? __kmalloc+0xfc/0x1b0
[ 406.179883] [<ffffffff8157cd0e>] ? video_usercopy+0x7e/0x470
[ 406.181961] [<ffffffff8157ce81>] video_usercopy+0x1f1/0x470
[ 406.184021] [<ffffffff8157afe0>] ? v4l_printk_ioctl+0xb0/0xb0
[ 406.186085] [<ffffffff810ae1ed>] ? account_system_time+0x8d/0x190
[ 406.188149] [<ffffffff8157d115>] video_ioctl2+0x15/0x20
[ 406.190216] [<ffffffff815781b3>] v4l2_ioctl+0x123/0x160
[ 406.192251] [<ffffffff810ce415>] ? rcu_eqs_enter+0x65/0xa0
[ 406.194256] [<ffffffff81186b28>] do_vfs_ioctl+0x88/0x560
[ 406.196258] [<ffffffff810ae145>] ? account_user_time+0x95/0xb0
[ 406.198262] [<ffffffff810ae6a4>] ? vtime_account_user+0x44/0x70
[ 406.200215] [<ffffffff81187091>] SyS_ioctl+0x91/0xb0
[ 406.202107] [<ffffffff817be109>] tracesys+0xd0/0xd5
[ 406.203946] Code: 66 66 66 90 48 f7 47 50 00 44 00 00 b8 ea ff ff ff 74 52 55 48 89 e5 53 48 89 d3 48 8d 4d e0 48 8d 55 e8 48 83 ec 18 48 8b 47 40 <48> 8b 78 40 e8 8b fe ff ff 85 c0 75 27 48 8b 55 e8 48 b9 00 f0
[ 406.208011] RIP [<ffffffff8115204c>] follow_pfn+0x2c/0x70
[ 406.209908] RSP <ffff880085abf888>
[ 406.211760] CR2: 0000000000000040
[ 406.213676] ---[ end trace 996d9f64e6739a04 ]---
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
Merge the media fixes merged upstream for v3.13-rc4
* upstream-fixes: (30 commits)
[media] videobuf2-dma-sg: fix possible memory leak
[media] vb2: regression fix: always set length field.
[media] mt9p031: Include linux/of.h header
[media] rtl2830: add parent for I2C adapter
[media] media: marvell-ccic: use devm to release clk
[media] ths7303: Declare as static a private function
[media] em28xx-video: Swap release order to avoid lock nesting
[media] usbtv: Add support for PAL video source
[media] media_tree: Fix spelling errors
[media] videobuf2: Add support for file access mode flags for DMABUF exporting
[media] radio-shark2: Mark shark_resume_leds() inline to kill compiler warning
[media] radio-shark: Mark shark_resume_leds() inline to kill compiler warning
[media] af9035: unlock on error in af9035_i2c_master_xfer()
[media] af9033: fix broken I2C
[media] v4l: omap3isp: Don't check for missing get_fmt op on remote subdev
[media] af9035: fix broken I2C and USB I/O
[media] wm8775: fix broken audio routing
[media] marvell-ccic: drop resource free in driver remove
[media] tef6862/radio-tea5764: actually assign clamp result
[media] cx231xx: use after free on error path in probe
...
|
|
Fix the return when 'buf->pages' allocation error.
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
|
|
Memory exported via remap_pfn_range cannot be remapped via
get_user_pages.
Other videobuf2 methods (like the dma-contig) supports io memory.
This patch adds support for this kind of memory.
v2: Comments by Marek Szyprowski
-Use vb2_get_vma and vb2_put_vma
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
num_pages_from_user and buf->num_pages were swapped.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
Replace the private struct vb2_dma_sg_desc with the struct sg_table so
we can benefit from all the helping functions in lib/scatterlist.c for
things like allocating the sg or compacting the descriptor.
marvel-ccic and solo6x10 drivers, that use this API have been updated.
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
[s.nawrocki@samsung.com: minor corrections of the changelog]
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
Most DMA engines have limitations regarding the number of DMA segments
(sg-buffers) that they can handle. Videobuffers can easily spread
through hundreds of pages.
In the previous aproach, the pages were allocated individually, this
could led to the creation houndreds of dma segments (sg-buffers) that
could not be handled by some DMA engines.
This patch tries to minimize the number of DMA segments by using
alloc_pages. In the worst case it will behave as before, but most
of the times it will reduce the number of dma segments
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
Memory maps typically require that the buffer size to be page
aligned. Currently, two memops drivers do such alignment
internally, but videobuf-vmalloc doesn't.
Also, the buffer overflow check doesn't take it into account.
So, instead of doing it at each memops driver, enforce it at
VB2 core.
Reported-by: Prabhakar lad <prabhakar.csengg@gmail.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
This prevents the kernel log from being spammed with these messages.
By turning on the debug option you will see them again.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.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: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Federico Vaga <federico.vaga@gmail.com>
Signed-off-by: Mauro 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: Mauro Carvalho Chehab <mchehab@redhat.com>
|
Tiffany Lin
Junghak Sung
Jan Kara
Hans Verkuil
Ricardo Ribalda
Sumit Semwal
Hans Verkuil
Hans Verkuil
Mauro Carvalho Chehab
Geyslan G. Bem
Mauro Carvalho Chehab