1. 22 Jun, 2015 1 commit
  2. 18 Jun, 2015 4 commits
    • Laurent Pinchart's avatar
      [media] MAINTAINERS: Add entry for the Renesas VSP1 driver · 6f32a8c9
      Laurent Pinchart authored
      The driver is maintained and supported, document it as such.
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      6f32a8c9
    • Hans Verkuil's avatar
      [media] videodev2.h: fix copy-and-paste error in V4L2_MAP_XFER_FUNC_DEFAULT · f8d5556f
      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: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      f8d5556f
    • Hans Verkuil's avatar
      [media] Revert "[media] vb2: Push mmap_sem down to memops" · 511a1b8a
      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: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      511a1b8a
    • Mauro Carvalho Chehab's avatar
      [media] mantis: cleanup a warning · 6fe2d69c
      Mauro Carvalho Chehab authored
      Signed-off-by: default avatarMauro 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;
      6fe2d69c
  3. 11 Jun, 2015 1 commit
    • Mauro Carvalho Chehab's avatar
      [media] bdisp-debug: don't try to divide by s64 · 82d229cd
      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: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      82d229cd
  4. 10 Jun, 2015 32 commits
  5. 09 Jun, 2015 2 commits
    • Jemma Denson's avatar
      [media] b2c2: Add option to skip the first 6 pid filters · d3525b63
      Jemma Denson authored
      The flexcop bridge chip has two banks of hardware pid filters -
      an initial 6, and on some chip revisions an additional bank of 32.
      
      A bug is present on the initial 6 - when changing transponders
      one of two PAT packets from the old transponder would be included
      in the initial packets from the new transponder. This usually
      transpired with userspace programs complaining about services
      missing, because they are seeing a PAT that they would not be
      expecting. Running in full TS mode does not exhibit this problem,
      neither does using just the additional 32.
      
      This patch adds in an option to not use the inital 6 and solely use
      just the additional 32, and enables this option for the SkystarS2
      card. Other cards can be added as required if they also have
      this bug.
      Signed-off-by: default avatarJemma Denson <jdenson@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      d3525b63
    • Takeshi Yoshimura's avatar
      [media] ddbridge: Do not free_irq() if request_irq() failed · 25e057fd
      Takeshi Yoshimura authored
      My static checker detected that free_irq() is called even after
      request_irq() failed in ddb_probe(). In this case, the kernel may try to
      free dev->pdev->irq although the IRQ is not assigned. This event rarely
      occurs, but always introduces a warning if it happens.
      
      "goto fail1" always results in disabling enabled MSI and releasing a
      requested IRQ. It seems like the former handling is necessary. So I added
      a conditional branch before the free_irq() (stat == 0 means request_irq()
      succeeds).
      Signed-off-by: default avatarTakeshi Yoshimura <yos@sslab.ics.keio.ac.jp>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      25e057fd