- 24 Jun, 2015 2 commits
-
-
Mauro Carvalho Chehab authored
On some archs, like tile, the PAGE_SIZE is not 4K. In the case of tile arch, it can be either 16KB or 64KB. Due to that, a warning is produced: drivers/media/pci/saa7134/saa7134.h:678:43: warning: large integer implicitly truncated to unsigned type [-Woverflow] This is actually an error, as it will write trach to the DMA size registers. The logic at saa7134-ts already does the right thing: saa_writeb(SAA7134_TS_DMA0, ((dev->ts.nr_packets-1)&0xff)); saa_writeb(SAA7134_TS_DMA1, (((dev->ts.nr_packets-1)>>8)&0xff)); /* TSNOPIT=0, TSCOLAP=0 */ saa_writeb(SAA7134_TS_DMA2, ((((dev->ts.nr_packets-1)>>16)&0x3f) | 0x00)); So, fix the driver to take larger page sizes into account. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Mauro Carvalho Chehab authored
Using CONFIG_PM_SLEEP suppress the warnings when the driver is compiled without PM sleep functions: drivers/media/rc/st_rc.c:338:12: warning: ‘st_rc_suspend’ defined but not used [-Wunused-function] drivers/media/rc/st_rc.c:359:12: warning: ‘st_rc_resume’ defined but not used [-Wunused-function] Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
-
- 23 Jun, 2015 1 commit
-
-
Mauro Carvalho Chehab authored
On alpha, gcc warns a log about signed/unsigned ballance, with produces 3185 warnings. Ok, this is bogus, but it indicates that the declaration at V4L2 side is not consistent with the one at I2C. With this trivial patch, the number of errors reduce to 2959 warnings. Still too much, but it is 7.1% less. So let's do it. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
- 22 Jun, 2015 3 commits
-
-
Mauro Carvalho Chehab authored
Some architectures already use CHIPID defines: drivers/media/radio/si470x/radio-si470x.h:57:0: warning: "CHIPID" redefined [enabled by default] drivers/media/radio/si470x/radio-si470x.h:57:0: warning: "CHIPID" redefined [enabled by default] drivers/media/radio/si470x/radio-si470x.h:57:0: warning: "CHIPID" redefined [enabled by default] So, use SI_foo namespace to avoid conflicts. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Mauro Carvalho Chehab authored
This driver requires support for DMA attrs function, and not just DMA. Change the options accordingly to remove those errors: /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c: In function ‘bdisp_hw_free_nodes’: /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c:132:3: error: implicit declaration of function ‘dma_free_attrs’ [-Werror=implicit-function-declaration] dma_free_attrs(ctx->bdisp_dev->dev, ^ /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c: In function ‘bdisp_hw_alloc_nodes’: /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c:157:9: error: implicit declaration of function ‘dma_alloc_attrs’ [-Werror=implicit-function-declaration] base = dma_alloc_attrs(dev, node_size * MAX_NB_NODE, &paddr, ^ /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c:157:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] base = dma_alloc_attrs(dev, node_size * MAX_NB_NODE, &paddr, ^ /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c: In function ‘bdisp_hw_alloc_filters’: /devel/v4l/to_next/drivers/media/platform/sti/bdisp/bdisp-hw.c:219:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion] base = dma_alloc_attrs(dev, size, &paddr, GFP_KERNEL | GFP_DMA, &attrs); Also, get rid of bogus, unused and duplicated symbol declaration for the config option done at bdisp/Kconfig. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Laurent Pinchart authored
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: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: stable@vger.kernel.org # for v4.0 Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
- 18 Jun, 2015 4 commits
-
-
Laurent Pinchart authored
The driver is maintained and supported, document it as such. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Hans Verkuil authored
The colorspace argument was compared against a V4L2_XFER_FUNC define instead of against a V4L2_COLORSPACE define, returning the wrong answer. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Hans Verkuil authored
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: 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>
-
Mauro Carvalho Chehab authored
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> drivers/media/pci/mantis/mantis_i2c.c: In function 'mantis_i2c_init': drivers/media/pci/mantis/mantis_i2c.c:222:15: warning: variable 'intmask' set but not used [-Wunused-but-set-variable] u32 intstat, intmask;
-
- 11 Jun, 2015 1 commit
-
-
Mauro Carvalho Chehab authored
There are several warnings there, on some architectures, related to dividing a s32 by a s64 value: drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: comparison of distinct pointer types lacks a cast drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: right shift count >= width of type drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: passing argument 1 of '__div64_32' from incompatible pointer type drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: comparison of distinct pointer types lacks a cast drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: right shift count >= width of type drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: passing argument 1 of '__div64_32' from incompatible pointer type CC [M] drivers/media/tuners/mt2060.o drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: comparison of distinct pointer types lacks a cast drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: right shift count >= width of type drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: passing argument 1 of '__div64_32' from incompatible pointer type drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: comparison of distinct pointer types lacks a cast drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: right shift count >= width of type drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: passing argument 1 of '__div64_32' from incompatible pointer type That doesn't make much sense. What the driver is actually trying to do is to divide one second by a value. So, check the range before dividing. That warrants the right result and will remove the warnings on non-64 bits archs. Also fixes this warning: drivers/media/platform/sti/bdisp/bdisp-debug.c:588: warning: comparison of distinct pointer types lacks a cast by using div64_s64() instead of calling do_div() directly. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
- 10 Jun, 2015 29 commits
-
-
Mauro Carvalho Chehab authored
While compiled on alpha, got this error: drivers/media/pci/cx88/cx88-video.c:415:12: warning: 'restart_video_queue' defined but not used [-Wunused-function] Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Rafael Lourenço de Lima Chehab authored
The attribution of dev->boards occured too late, which would couse an OOPS in media controller registration. Signed-off-by: Rafael Lourenço de Lima Chehab <chehabrafael@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Malcolm Priestley authored
Indroduce function lme2510_update_stats to update statistics directly from usb interrupt. Provide signal and snr wrap rounds for dvb v3 functions. Block and post bit are not available. When i2c_talk_onoff is on no statistics are available, with possible future hand over to the relevant frontend/tuner. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Mauro Carvalho Chehab authored
Fix the following warning: drivers/media/platform/sti/bdisp/bdisp-v4l2.c: In function 'bdisp_register_device': drivers/media/platform/sti/bdisp/bdisp-v4l2.c:1024:26: warning: variable 'pdev' set but not used [-Wunused-but-set-variable] struct platform_device *pdev; Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Fabien Dessenne authored
As reported by smatch: drivers/media/platform/sti/bdisp/bdisp-v4l2.c:947 bdisp_s_selection() warn: unsigned 'out.width' is never less than zero. drivers/media/platform/sti/bdisp/bdisp-v4l2.c:947 bdisp_s_selection() warn: unsigned 'out.height' is never less than zero. Indeed, width and height are unsigned. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Mauro Carvalho Chehab authored
drivers/built-in.o: In function `ts2020_read_signal_strength': ts2020.c:(.text+0x298ff94): undefined reference to `__divdi3' ts2020.c:(.text+0x298ffd4): undefined reference to `__divdi3' ts2020.c:(.text+0x298fffd): undefined reference to `__divdi3' Makefile:921: recipe for target 'vmlinux' failed Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Mauro Carvalho Chehab authored
Commit a96762da('[media] mantis: add remote control support') introduced some new CodingStyle issues. Fix them. No functional changes. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Jan Klötzke authored
The embedded UART is apparently used to receive decoded IR (RC5?) codes. Forward these scan codes to the RC framework and (where known) add corresponding mapping tables to translate them into regular keys. This patch has been tested on a TechniSat CableStar HD2. The mappings of other rc-maps were taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/) and the s2-liplianin repository. The major difference to Christoph's patch is a reworked interrupt handling of the UART because the RX interrupt is apparently level triggered and requires masking until the FIFO is read by the UART worker. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Jan Klötzke authored
This RC map was taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/). It is used solely by the respective mantis based card because the encoding is not known. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Jan Klötzke authored
This RC map was taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/). It is used solely by the respective mantis based card because the encoding is not known. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Jan Klötzke authored
This RC map was taken from Christoph Pinkl's patch (http://patchwork.linuxtv.org/patch/7217/). It is used solely by the respective mantis based card because the encoding is not known. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Jan Klötzke authored
The TS35 remote is distributed with TechniSat CableStar HD2 cards (mantis chipset). The exact protocol type is unknown, making this rc map probably only usable by mantis cards. Signed-off-by: Jan Klötzke <jan@kloetzke.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Dan Carpenter authored
Quite a few of the ->diseqc_send_master_cmd() implementations don't check cmd->msg_len so it can lead to memory corruption. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Olli Salonen authored
This reverts commit ad90b6b0. This patch breaks I2C communication towards Si2168. After reverting and applying the other patch in this series the I2C communication is correct. Signed-off-by: Olli Salonen <olli.salonen@iki.fi> Reviewed-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Olli Salonen authored
The i2c_reg_len for Si2168 should be 0 for correct I2C communication. Signed-off-by: Olli Salonen <olli.salonen@iki.fi> Reviewed-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Vaishali Thakkar authored
In little endian cases, macro cpu_to_be16 unfolds to __swab16 which provides special case for constants. In big endian cases, __constant_cpu_to_be16 and cpu_to_be16 expand directly to the same expression. So, replace __constant_cpu_to_be16 with cpu_to_be16 with the goal of getting rid of the definition of __constant_cpu_to_be16 completely. The semantic patch that performs this transformation is as follows: @@expression x;@@ - __constant_cpu_to_be16(x) + cpu_to_be16(x) Signed-off-by: Vaishali Thakkar <vthakkar1994@gmail.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Malcolm Priestley authored
Following a change made to TS2020 tuner in patches ts2020: Provide DVBv5 API signal strength ts2020: Allow stats polling to be suppressed Polling on the driver must be suppressed because the demuxer is stopped by I2C messages. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
David Howells authored
Statistics polling can not be done by lmedm04 driver's implementation of M88RS2000/TS2020 because I2C messages stop the device's demuxer, so allow polling for statistics to be suppressed in the ts2020 driver by setting dont_poll in the ts2020_config struct. Reported-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
David Howells authored
Copy the loop_through setting from the ts2020_config struct to the internal ts2020_priv struct so that it can actually be used. Whilst we're at it, group the bitfields together in the same order in both structs so that the compiler has a good chance to copy them in one go. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
David Howells authored
Provide a DVBv5 API signal strength. This is in units of 0.001 dBm rather than a percentage. >From Antti Palosaari's testing with a signal generator, it appears that the gain calculated according to Montage's specification if negated is a reasonable representation of the signal strength of the generator. To this end: (1) Polled statistic gathering needed to be implemented in the TS2020 driver. This is done in the ts2020_stat_work() function. (2) The calculated gain is placed as the signal strength in the dtv_property_cache associated with the front end with the scale set to FE_SCALE_DECIBEL. (3) The DVBv3 format signal strength then needed to be calculated from the signal strength stored in the dtv_property_cache rather than accessing the value when ts2020_read_signal_strength() is called. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
David Howells authored
The TS2020 and TS2022 tuners take an input from the demodulator indicating the AGC setting on that component that is then used to influence the tuner's own gain. This should be taken into account when calculating the gain and signal strength. Further, the existing TS2020 driver miscalculates the signal strength as the result of its calculations can exceed the storage capacity of the 16-bit word used to return it to userspace. To this end: (1) Add a callback function (->get_agc_pwm()) in the ts2020_config struct that the tuner can call to get the AGC PWM value from the demodulator. (2) Modify the TS2020 driver to calculate the gain according to Montage's specification with the adjustment that we produce a negative value and scale it to 0.001dB units (which is what the DVBv5 API will require): (a) Callback to the demodulator to retrieve the AGC PWM value and then turn that into Vagc for incorporation in the calculations. If the callback is unset, assume a Vagc of 0. (b) Calculate the tuner gain from a combination of Vagc and the tuner's RF gain and baseband gain settings. (3) Turn this into a percentage signal strength as per Montage's specification for return to userspace with the DVBv3 API. (4) Provide a function in the M88DS3103 demodulator driver that can be used to get the AGC PWM value on behalf of the tuner. (5) The ts2020_config.get_agc_pwm function should be set by the code that stitches together the drivers for each card. For the DVBSky cards that use the M88DS3103 with the TS2020 or the TS2022, set the get_agc_pwm function to point to m88ds3103_get_agc_pwm. I have tested this with a DVBSky S952 card which has an M88DS3103 and a TS2022. Thanks to Montage for providing access to information about the workings of these parts. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Antti Palosaari authored
Use I2C client binding for demod and SEC. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Antti Palosaari authored
Use regmap for I2C register access. Remove own I2C repeated mutex as it should not be needed. I2C adapter lock is already taken when I2C mux adapter is called, no need for double locking. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Antti Palosaari authored
Rename driver state from priv to dev. Use I2C client for correct logging. Use adapter and address from I2C client structure where needed. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
David Howells authored
ts2020_attach() allocates a variable pdata on the stack and then passes a pointer to it to i2c_new_device() which stashes the pointer in persistent structures. Add a comment to the effect that this isn't actually an error because the contents of the variable are only used in ts2020_probe() and this is only called ts2020_attach()'s stack frame exists. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Antti Palosaari authored
Use regmap to cover I2C register access. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Antti Palosaari authored
Register driver using I2C bindings internally when legacy media attach is used. That is done by registering driver using I2C binding from legacy attach. That way we can get valid I2C client, which is needed for proper dev_() logging and regmap for example even legacy binding is used. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Antti Palosaari authored
* We don't need calculate channel bandwidth from symbol rate as it is calculated by DVB core. * Use clamp() to force upper/lower limit of filter 3dB frequency. Upper limit should never exceeded 40MHz (80MHz BW) in any case, though... Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Antti Palosaari authored
Used frequency synthesizer is simple Integer-N PLL, with configurable reference divider, output divider and of course N itself. Old calculations were working fine, but not so easy to understand. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-