1. 26 11月, 2012 1 次提交
  2. 27 9月, 2012 2 次提交
  3. 26 9月, 2012 2 次提交
  4. 14 8月, 2012 1 次提交
  5. 10 8月, 2012 1 次提交
  6. 31 7月, 2012 4 次提交
  7. 19 7月, 2012 1 次提交
  8. 07 7月, 2012 3 次提交
  9. 12 6月, 2012 2 次提交
  10. 15 5月, 2012 1 次提交
  11. 14 5月, 2012 3 次提交
    • H
      [media] v4l2-dev: add flag to have the core lock all file operations · 5126f259
      Hans Verkuil 提交于
      This used to be the default if the lock pointer was set, but now that lock is by
      default only used for ioctl serialization. Those drivers that already used
      core locking have this flag set explicitly, except for some drivers where
      it was obvious that there was no need to serialize any file operations other
      than ioctl.
      
      The drivers that didn't need this flag were:
      
      drivers/media/radio/dsbr100.c
      drivers/media/radio/radio-isa.c
      drivers/media/radio/radio-keene.c
      drivers/media/radio/radio-miropcm20.c
      drivers/media/radio/radio-mr800.c
      drivers/media/radio/radio-tea5764.c
      drivers/media/radio/radio-timb.c
      drivers/media/video/vivi.c
      sound/i2c/other/tea575x-tuner.c
      
      The other drivers that use core locking and where it was not immediately
      obvious that this flag wasn't needed were changed so that the flag is set
      together with a comment that that driver needs work to avoid having to
      set that flag. This will often involve taking the core lock in the fops
      themselves.
      
      Eventually this flag should go and it should not be used in new drivers.
      
      There are a few reasons why we want to avoid core locking of non-ioctl
      fops: in the case of mmap this can lead to a deadlock in rare situations
      since when mmap is called the mmap_sem is held and it is possible for
      other parts of the code to take that lock as well (copy_from_user()/copy_to_user()
      perform a down_read(&mm->mmap_sem) when a page fault occurs).
      
      It is very unlikely that that happens since the core lock serializes all
      fops, but the kernel warns about it if lock validation is turned on.
      
      For poll it is also undesirable to take the core lock as that can introduce
      increased latency. The same is true for read/write.
      
      While it was possible to make flags or something to turn on/off taking the
      core lock for each file operation, in practice it is much simpler to just
      not take it at all except for ioctl and leave it to the driver to take the
      lock. There are only a handful fops compared to the zillion ioctls we have.
      
      I also wanted to make it obvious which drivers still take the lock for all
      fops, so that's why I chose to have drivers set it explicitly.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5126f259
    • H
      [media] v4l2-dev/ioctl: determine the valid ioctls upfront · 48ea0be0
      Hans Verkuil 提交于
      Rather than testing whether an ioctl is implemented in the driver or not
      every time the ioctl is called, do it upfront when the device is registered.
      
      This also allows a driver to disable certain ioctls based on the capabilities
      of the detected board, something you can't do today without creating separate
      v4l2_ioctl_ops structs for each new variation.
      
      For the most part it is pretty straightforward, but for control ioctls a flag
      is needed since it is possible that you have per-filehandle controls, and that
      can't be determined upfront of course.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      48ea0be0
    • H
      [media] v4l2-dev: make it possible to skip locking for selected ioctls · 8ab75e3e
      Hans Verkuil 提交于
      Using the V4L2 core lock is a very robust method that is usually very good
      at doing the right thing. But some drivers, particularly USB drivers, may
      want to prevent the core from taking the lock for specific ioctls, particularly
      buffer queuing ioctls.
      
      The reason is that certain commands like S_CTRL can take a long time to process
      over USB and all the time the core has the lock, preventing VIDIOC_DQBUF from
      proceeding, even though a frame may be ready in the queue.
      
      This introduces unwanted latency.
      
      Since the buffer queuing commands often have their own internal lock it is
      often not necessary to take the core lock. Drivers can now say that they don't
      want the core to take the lock for specific ioctls.
      
      As it is a specific opt-out it makes it clear to the reviewer that those
      ioctls will need more care when reviewing.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      8ab75e3e
  12. 29 3月, 2012 1 次提交
  13. 20 3月, 2012 1 次提交
    • B
      [media] V4L/v4l2-dev: Make 'videodev_init' as a subsys initcall · ee981c6f
      Bhupesh Sharma 提交于
      As the V4L2 based UVC webcam gadget (g_webcam) expects the
      'videodev' to present when the 'webcam_bind' routine is called,
      so 'videodev' should be available as early as possible.
      
      Now, when 'g_webcam' is built as a module (i.e. not a part of
      kernel) the late availability of 'videodev' is OK, but if
      'g_webcam' is built statically as a part of the kernel,
      the kernel crashes (a sample crash dump using Designware 2.0 UDC
      is provided below).
      
      To solve the same, this patch makes 'videodev_init' as a subsys initcall.
      
      Kernel Crash Dump:
      
      ------------------
      
      designware_udc designware_udc: Device Synopsys UDC probed csr 90810000: plug 90812000
      g_webcam gadget: uvc_function_bind
      Unable to handle kernel NULL pointer dereference at virtual address 000000e4
      pgd = 80004000
      [000000e4] *pgd=00000000
      Internal error: Oops: 5 [#1] SMP
      Modules linked in:
      CPU: 0    Not tainted  (3.3.0-rc3-13888-ge774c03-dirty #20)
      PC is at do_raw_spin_lock+0x10/0x16c
      LR is at _raw_spin_lock+0x10/0x14
      pc : [<8019e344>]    lr : [<804095c0>]    psr: 60000013
      sp : 8f839d20  ip : 8f839d50  fp : 8f839d4c
      r10: 80760a94  r9 : 8042de98  r8 : 00000154
      r7 : 80760e94  r6 : 805cfc10  r5 : 8fb6a008  r4 : 8fb6a008
      r3 : 805dd0c8  r2 : 8f839d48  r1 : 805cfc08  r0 : 000000e0
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c5387d  Table: 0000404a  DAC: 00000015
      Process swapper/0 (pid: 1, stack limit = 0x8f8382f0)
      Stack: (0x8f839d20 to 0x8f83a000)
      9d20: ffffffff ffffffff 8fb6a008 8fb6a008 805cfc10 80760e94 00000154 8042de98
      9d40: 8f839d5c 8f839d50 804095c0 8019e340 8f839d7c 8f839d60 80222b28 804095bc
      9d60: 8fb12b80 8fb6a008 8fb6a010 805cfc08 8f839dc4 8f839d80 80223db8 80222adc
      9d80: 8f839dac 8f839d90 8022baa0 8019e2e8 8fb6a008 8075e7f4 8fb6a008 8fb6a008
      9da0: 00000000 8fb6a008 80760e94 00000154 8042de98 80760a94 8f839ddc 8f839dc8
      9dc0: 802242a8 80223d1c 8fb12b80 8fb6a000 8f839e1c 8f839de0 8030132c 80224298
      9de0: 80223ce8 803f2ee8 00000001 804f7750 8f839e1c 8f824008 805cff20 8f824000
      9e00: 8fb6a000 ffffffff 00000000 8f8d4880 8f839e4c 8f839e20 80562e3c 80301100
      9e20: 00000000 8fb13140 8f824008 805cff20 8042aa68 8f824000 8042aa8c 805e4d40
      9e40: 8f839e64 8f839e50 802d20c4 80562ba8 805d0058 805cff20 8f839e8c 8f839e68
      9e60: 80563034 802d206c 8042aa8c 805cff20 8f8d4880 00000000 805cfc08 8fb12a40
      9e80: 8f839e9c 8f839e90 805630c4 80562ec4 8f839ebc 8f839ea0 802d2364 805630b0
      9ea0: 805cfeac 8f8d4880 805cfbe8 807605e8 8f839ed4 8f839ec0 80562b3c 802d22cc
      9ec0: 80562ac4 8f8d4880 8f839f04 8f839ed8 802d0b40 80562ad0 8f839ef4 805cff90
      9ee0: 805cff90 805cfb98 00000000 00000000 805cfbe8 805e4d40 8f839f3c 8f839f08
      9f00: 802cd078 802d0a18 00000000 802d0a0c 00000000 8fb9ba00 802d0a0c 805cff90
      9f20: 00000013 00000000 00000000 805e4d40 8f839f5c 8f839f40 802cf390 802ccff0
      9f40: 00000003 00000003 804fb598 00000000 8f839f74 8f839f60 802d2554 802cf2a0
      9f60: 8f838000 8057731c 8f839f84 8f839f78 80562b90 802d24d0 8f839fdc 8f839f88
      9f80: 800085d4 80562b84 805af2ac 805af2ac 80562b78 00000000 00000013 00000000
      9fa0: 00000000 00000000 8f839fc4 8f839fb8 80043dd0 8057706c 8057731c 8002875c
      9fc0: 00000013 00000000 00000000 00000000 8f839ff4 8f839fe0 805468d4 800085a0
      9fe0: 00000000 80546840 00000000 8f839ff8 8002875c 8054684c 51155555 55545555
      Backtrace:
      [<8019e334>] (do_raw_spin_lock+0x0/0x16c) from [<804095c0>] (_raw_spin_lock+0x10/0x14)
       r9:8042de98 r8:00000154 r7:80760e94 r6:805cfc10 r5:8fb6a008
      r4:8fb6a008
      [<804095b0>] (_raw_spin_lock+0x0/0x14) from [<80222b28>] (get_device_parent+0x58/0x1c0)
      [<80222ad0>] (get_device_parent+0x0/0x1c0) from [<80223db8>] (device_add+0xa8/0x57c)
       r6:805cfc08 r5:8fb6a010 r4:8fb6a008 r3:8fb12b80
      [<80223d10>] (device_add+0x0/0x57c) from [<802242a8>] (device_register+0x1c/0x20)
      [<8022428c>] (device_register+0x0/0x20) from [<8030132c>] (__video_register_device+0x238/0x484)
       r4:8fb6a000 r3:8fb12b80
      [<803010f4>] (__video_register_device+0x0/0x484) from [<80562e3c>] (uvc_function_bind+0x2a0/0x31c)
      [<80562b9c>] (uvc_function_bind+0x0/0x31c) from [<802d20c4>] (usb_add_function+0x64/0x118)
      [<802d2060>] (usb_add_function+0x0/0x118) from [<80563034>] (uvc_bind_config+0x17c/0x1ec)
       r5:805cff20 r4:805d0058
      [<80562eb8>] (uvc_bind_config+0x0/0x1ec) from [<805630c4>] (webcam_config_bind+0x20/0x28)
       r8:8fb12a40 r7:805cfc08 r6:00000000 r5:8f8d4880 r4:805cff20
      r3:8042aa8c
      [<805630a4>] (webcam_config_bind+0x0/0x28) from [<802d2364>] (usb_add_config+0xa4/0x124)
      [<802d22c0>] (usb_add_config+0x0/0x124) from [<80562b3c>] (webcam_bind+0x78/0xb4)
       r6:807605e8 r5:805cfbe8 r4:8f8d4880 r3:805cfeac
      [<80562ac4>] (webcam_bind+0x0/0xb4) from [<802d0b40>] (composite_bind+0x134/0x308)
       r4:8f8d4880 r3:80562ac4
      [<802d0a0c>] (composite_bind+0x0/0x308) from [<802cd078>] (dw_udc_start+0x94/0x2bc)
      [<802ccfe4>] (dw_udc_start+0x0/0x2bc) from [<802cf390>] (usb_gadget_probe_driver+0xfc/0x180)
      [<802cf294>] (usb_gadget_probe_driver+0x0/0x180) from [<802d2554>] (usb_composite_probe+0x90/0xb4)
       r6:00000000 r5:804fb598 r4:00000003 r3:00000003
      [<802d24c4>] (usb_composite_probe+0x0/0xb4) from [<80562b90>] (webcam_init+0x18/0x24)
       r5:8057731c r4:8f838000
      [<80562b78>] (webcam_init+0x0/0x24) from [<800085d4>] (do_one_initcall+0x40/0x184)
      [<80008594>] (do_one_initcall+0x0/0x184) from [<805468d4>] (kernel_init+0x94/0x134)
      [<80546840>] (kernel_init+0x0/0x134) from [<8002875c>] (do_exit+0x0/0x6f8)
       r5:80546840 r4:00000000
      Code: e1a0c00d e92ddbf0 e24cb004 e24dd008 (e5902004)
      ---[ end trace 7ecca37f36fbdc06 ]---
      Signed-off-by: NBhupesh Sharma <bhupesh.sharma@st.com>
      Tested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      ee981c6f
  14. 20 12月, 2011 1 次提交
  15. 11 12月, 2011 1 次提交
  16. 19 10月, 2011 1 次提交
  17. 22 9月, 2011 1 次提交
  18. 01 7月, 2011 1 次提交
    • L
      [media] v4l: Don't access media entity after is has been destroyed · c064b8ea
      Laurent Pinchart 提交于
      Entities associated with video device nodes are unregistered in
      video_unregister_device(). This destroys the entity even though it can
      still be accessed through open video device nodes.
      
      Move the media_device_unregister_entity() call from
      video_unregister_device() to v4l2_device_release() to ensure that the
      entity isn't unregistered until the last reference to the video device
      is released.
      
      Also remove the media_entity_get()/put() calls from v4l2-dev.c. Those
      functions were designed for subdevs, to avoid a parent module from being
      removed while still accessible through board code. They're not currently
      needed for video device nodes, and will oops when a hotpluggable device
      is disconnected during streaming, as media_entity_put() called in
      v4l2_device_release() tries to access entity->parent->dev->driver which
      is set to NULL when the device is disconnected.
      Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: NSakari Ailus <sakari.ailus@iki.fi>
      Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c064b8ea
  19. 20 5月, 2011 1 次提交
  20. 19 4月, 2011 1 次提交
  21. 23 3月, 2011 4 次提交
  22. 22 3月, 2011 2 次提交
  23. 19 1月, 2011 1 次提交
  24. 02 12月, 2010 3 次提交