1. 06 4月, 2021 1 次提交
  2. 07 12月, 2020 1 次提交
    • H
      media: vivid: fix 'disconnect' error injection · 9e5f21d6
      Hans Verkuil 提交于
      The 'disconnect' error injection functionality suffered from bit rot.
      
      New device nodes were added without updating vivid_user_gen_s_ctrl(), so
      that function had to be updated for the new device nodes.
      
      Also, vivid didn't check if specific device nodes were actually ever
      created, so the vivid_is_last_user() would fail on that (it would return
      true instead of false in that case).
      
      Finally, selecting Disconnect, then unbind the vivid driver would fail
      since the remove() would think that the device nodes were already
      unregistered. Keep track of whether disconnect was pressed and re-register
      the device nodes in remove() before doing the real unregister.
      
      [hverkuil: unsigned uses -> unsigned int uses]
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      9e5f21d6
  3. 08 9月, 2020 1 次提交
    • H
      media: vivid: fix compile warning/error · d034731b
      Hans Verkuil 提交于
      Fix this warning:
      
      vivid-core.c: In function 'vivid_create_devnodes':
      vivid-core.c:1318:11: warning: unused variable 'i' [-Wunused-variable]
       1318 |  int ret, i;
            |           ^
      
      and this error:
      
      vivid-core.c: In function 'vivid_create_instance':
      vivid-core.c:1885:47: error: 'cec_tx_bus_cnt' undeclared (first use in this function)
       1885 |  ret = vivid_create_devnodes(pdev, dev, inst, cec_tx_bus_cnt,
            |                                               ^~~~~~~~~~~~~~
      vivid-core.c:1885:47: note: each undeclared identifier is reported only once for each function it appears in
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      d034731b
  4. 07 9月, 2020 7 次提交
  5. 28 8月, 2020 1 次提交
  6. 04 7月, 2020 1 次提交
  7. 23 6月, 2020 1 次提交
  8. 16 4月, 2020 1 次提交
  9. 14 4月, 2020 1 次提交
    • M
      media: split test drivers from platform directory · 4b32216a
      Mauro Carvalho Chehab 提交于
      When the first test device was added (vivi.c), there were just
      one file. I was too lazy on that time to create a separate
      directory just for it, so I kept it together with platform.
      
      Now, we have vivid, vicodec, vim2m and vimc. Also, a new
      virtual driver has been prepared to support DVB API.
      
      So, it is time to solve this mess, by placing test stuff
      on a separate directory.
      
      It should be noticed that we also have some skeleton drivers
      (for V4L and for DVB). For now, we'll keep them separate,
      as they're not really test drivers, but instead, just
      examples. The DVB frontend ones will likely be part of a new DVB
      test driver. By that time, it should make sense to move them
      here as well.
      Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      4b32216a
  10. 25 3月, 2020 1 次提交
  11. 24 2月, 2020 1 次提交
  12. 16 12月, 2019 1 次提交
  13. 13 12月, 2019 1 次提交
  14. 08 11月, 2019 1 次提交
    • H
      media: vivid: add vivid_create_queue() helper · 0c90f649
      Hans Verkuil 提交于
      Refactor some of the vivid_create_instance code by using a
      new vivid_create_queue() helper function.
      
      Also add some sanity checks for the node_types vs input/output_types
      module options.
      
      This patch resolves these two smatch parse errors:
      
      drivers/media/platform/vivid/vivid-core.c:1679 vivid_create_instance() parse error: OOM: 3002600Kb sm_state_count = 6160113
      drivers/media/platform/vivid/vivid-core.c: drivers/media/platform/vivid/vivid-core.c:1679
      vivid_create_instance() parse error: __split_smt: function too hairy.  Giving up after 33 seconds
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
      0c90f649
  15. 05 11月, 2019 1 次提交
    • H
      media: vivid: media_device_cleanup was called too early · 8ffd573c
      Hans Verkuil 提交于
      Running the contrib/test/test-media script in v4l-utils with the vivid argument
      will cause this kernel warning:
      
      [  104.748720] videodev: v4l2_release
      [  104.748731] ------------[ cut here ]------------
      [  104.748750] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
      [  104.748790] WARNING: CPU: 6 PID: 1823 at kernel/locking/mutex.c:938 __mutex_lock+0x919/0xc10
      [  104.748800] Modules linked in: rc_cec vivid v4l2_tpg videobuf2_dma_contig cec rc_core v4l2_dv_timings videobuf2_vmalloc videobuf2_memops
      videobuf2_v4l2 videobuf2_common videodev mc vmw_balloon vmw_vmci button vmwgfx
      [  104.748845] CPU: 6 PID: 1823 Comm: sleep Not tainted 5.4.0-rc1-test-no #150
      [  104.748853] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019
      [  104.748867] RIP: 0010:__mutex_lock+0x919/0xc10
      [  104.748878] Code: 59 83 e8 9a fc 16 ff 44 8b 05 23 61 38 01 45 85 c0 0f 85 ef f7 ff ff 48 c7 c6 a0 1f 87 82 48 c7 c7 a0 1e 87 82 e8 cd bb
      f7 fe <0f> 0b e9 d5 f7 ff ff f6 c3 04 0f 84 3b fd ff ff 49 89 df 41 83 e7
      [  104.748886] RSP: 0018:ffff88811a357b80 EFLAGS: 00010286
      [  104.748895] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
      [  104.748902] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffed102346af62
      [  104.748910] RBP: ffff88811a357cf0 R08: ffffffff81217c91 R09: fffffbfff061c271
      [  104.748917] R10: fffffbfff061c270 R11: ffffffff830e1383 R12: ffff8881a46103c0
      [  104.748924] R13: 0000000000000000 R14: ffff8881a4614f90 R15: ffff8881a46153d0
      [  104.748933] FS:  0000000000000000(0000) GS:ffff8881b6780000(0000) knlGS:0000000000000000
      [  104.748940] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  104.748949] CR2: 00007f163fc9ca20 CR3: 0000000003013004 CR4: 00000000001606e0
      [  104.749036] Call Trace:
      [  104.749051]  ? _raw_spin_unlock+0x1f/0x30
      [  104.749067]  ? llist_add_batch+0x33/0x50
      [  104.749081]  ? tick_nohz_tick_stopped+0x19/0x30
      [  104.749130]  ? v4l2_release.cold+0x6c/0xd6 [videodev]
      [  104.749143]  ? mutex_lock_io_nested+0xb80/0xb80
      [  104.749153]  ? vprintk_emit+0xf2/0x220
      [  104.749191]  ? vivid_req_validate+0x40/0x40 [vivid]
      [  104.749201]  ? printk+0xad/0xde
      [  104.749211]  ? kmsg_dump_rewind_nolock+0x54/0x54
      [  104.749226]  ? locks_remove_file+0x78/0x2b0
      [  104.749248]  ? __fsnotify_update_child_dentry_flags.part.0+0x170/0x170
      [  104.749281]  ? vivid_req_validate+0x40/0x40 [vivid]
      [  104.749321]  ? v4l2_release.cold+0x6c/0xd6 [videodev]
      [  104.749361]  v4l2_release.cold+0x6c/0xd6 [videodev]
      [  104.749378]  __fput+0x15a/0x390
      [  104.749393]  task_work_run+0xb2/0xe0
      [  104.749407]  do_exit+0x4d0/0x1200
      [  104.749422]  ? do_user_addr_fault+0x367/0x610
      [  104.749431]  ? release_task+0x990/0x990
      [  104.749449]  ? rwsem_spin_on_owner+0x170/0x170
      [  104.749463]  ? vmacache_find+0xb2/0x100
      [  104.749476]  do_group_exit+0x85/0x130
      [  104.749487]  __x64_sys_exit_group+0x23/0x30
      [  104.749500]  do_syscall_64+0x5e/0x1c0
      [  104.749511]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [  104.749520] RIP: 0033:0x7f163fc5c9d6
      [  104.749536] Code: Bad RIP value.
      [  104.749543] RSP: 002b:00007ffe6f3bec58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
      [  104.749553] RAX: ffffffffffffffda RBX: 00007f163fd4d760 RCX: 00007f163fc5c9d6
      [  104.749560] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
      [  104.749567] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80
      [  104.749574] R10: 00007ffe6f3beb24 R11: 0000000000000246 R12: 00007f163fd4d760
      [  104.749581] R13: 0000000000000002 R14: 00007f163fd56428 R15: 0000000000000000
      [  104.749597] ---[ end trace 66f20f73fc0daf79 ]---
      
      This is caused by media_device_cleanup() which destroys
      v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock
      that mutex after media_device_cleanup() is called.
      
      By moving media_device_cleanup() to the v4l2_device's release function it is
      guaranteed that the mutex is valid whenever v4l2_release is called.
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
      8ffd573c
  16. 24 10月, 2019 2 次提交
  17. 30 7月, 2019 1 次提交
  18. 25 7月, 2019 1 次提交
  19. 22 6月, 2019 5 次提交
  20. 05 6月, 2019 1 次提交
  21. 29 3月, 2019 1 次提交
  22. 19 2月, 2019 1 次提交
  23. 17 1月, 2019 2 次提交
  24. 04 12月, 2018 2 次提交
  25. 23 11月, 2018 1 次提交
  26. 21 11月, 2018 1 次提交
  27. 12 9月, 2018 1 次提交