1. 09 9月, 2016 1 次提交
  2. 24 8月, 2016 1 次提交
  3. 23 7月, 2016 2 次提交
  4. 14 4月, 2016 1 次提交
  5. 27 2月, 2016 1 次提交
  6. 11 1月, 2016 1 次提交
  7. 03 3月, 2015 1 次提交
  8. 23 12月, 2014 1 次提交
  9. 05 7月, 2014 1 次提交
  10. 06 3月, 2014 1 次提交
  11. 21 6月, 2013 1 次提交
    • H
      [media] v4l2: always require v4l2_dev, rename parent to dev_parent · 1c1d86a1
      Hans Verkuil 提交于
      The last set of drivers still using the parent field of video_device instead
      of the v4l2_dev field have been converted, so v4l2_dev is now always set.
      A proper pointer to v4l2_dev is necessary these days otherwise the advanced
      debugging ioctls will not work when addressing sub-devices. It also ensures
      that the core can always go from a video_device struct to the top-level
      v4l2_device struct.
      There is still one single use case for the parent pointer: if there are
      multiple busses, each being the parent of one or more video nodes, and if
      they all share the same v4l2_device struct. In that case one still needs a
      parent pointer since the v4l2_device struct can only refer to a single
      parent device. The cx88 driver is one such case. Unfortunately, the cx88
      failed to set the parent pointer since 3.6. The next patch will correct this.
      In order to support this use-case the parent pointer is only renamed to
      dev_parent, not removed altogether. It has been renamed to ensure that the
      compiler will catch any (possibly out-of-tree) drivers that were missed during
      the conversion.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: NSakari Ailus <sakari.ailus@iki.fi>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      1c1d86a1
  12. 17 6月, 2013 1 次提交
    • H
      [media] v4l2: remove deprecated current_norm support completely · ca371575
      Hans Verkuil 提交于
      The use of current_norm to keep track of the current standard has been
      deprecated for quite some time. Now that all drivers that were using it
      have been converted to use g_std we can drop it from the core.
      It was a bad idea to introduce this at the time: since it is a per-device
      node field it didn't work for drivers that create multiple nodes, all sharing
      the same tuner (e.g. video and vbi nodes, or a raw video node and a compressed
      video node). In addition it was very surprising behavior that g_std was
      implemented in the core. Often drivers implemented both g_std and current_norm,
      because they didn't understand how it should be used.
      Since the benefits were very limited (if they were there at all), it is better
      to just drop it and require that drivers just implement g_std.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      ca371575
  13. 26 9月, 2012 1 次提交
  14. 10 8月, 2012 1 次提交
  15. 07 7月, 2012 1 次提交
  16. 15 5月, 2012 2 次提交
  17. 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
  18. 20 3月, 2012 1 次提交
  19. 01 6月, 2011 1 次提交
  20. 20 5月, 2011 1 次提交
  21. 23 3月, 2011 3 次提交
  22. 22 3月, 2011 2 次提交
  23. 21 10月, 2010 3 次提交
    • H
      V4L/DVB: v4l2: add core serialization lock · ee6869af
      Hans Verkuil 提交于
      Drivers can optionally set a pointer to a mutex in struct video_device.
      The core will use that to lock before calling open, read, write, unlocked_ioctl,
      poll, mmap or release.
      
      Updated the documentation as well and ensure that v4l2-event knows about the
      lock: it will unlock it before doing a blocking wait on an event and relock it
      afterwards.
      
      Ensure that the 'video_is_registered' check is done when the lock is held:
      a typical disconnect will take the lock as well before unregistering the
      device nodes, so to prevent race conditions the video_is_registered check
      should also be done with the lock held.
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      ee6869af
    • H
      V4L/DVB: v4l2-dev: remove get_unmapped_area · c29fcff3
      Hans Verkuil 提交于
      The get_unmapped_area file operation is unused. Remove.
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c29fcff3
    • H
      V4L/DVB: videotext: remove this obsolete API · 226c0eea
      Hans Verkuil 提交于
      Remove the vtx (aka videotext aka teletext) API from the v4l2 core.
      This API was scheduled for removal in kernel 2.6.35.
      
      The vtx device nodes have been superseded by vbi device nodes
      for many years. No applications exist that use the vtx support.
      Of the two i2c drivers that actually support this API the saa5249
      has been impossible to use for a year now and no known hardware
      that supports this device exists. The saa5246a is theoretically
      supported by the old mxb boards, but it never actually worked.
      
      In summary: there is no hardware that can use this API and there
      are no applications actually implementing this API.
      
      The vtx support still reserves minors 192-223 and we would really
      like to reuse those for upcoming new functionality. In the unlikely
      event that new hardware appears that wants to use the functionality
      provided by the vtx API, then that functionality should be build
      around the sliced VBI API instead.
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      226c0eea
  24. 09 8月, 2010 1 次提交
    • H
      V4L/DVB: v4l2: Add new control handling framework · 0996517c
      Hans Verkuil 提交于
      Add a new framework to handle controls which makes life for driver
      developers much easier.
      
      Note that this patch moves some of the control support that used to be in
      v4l2-common.c to v4l2-ctrls.c. The tables were copied unchanged. The body
      of v4l2_ctrl_query_fill() was copied to a new v4l2_ctrl_fill() function
      in v4l2-ctrls.c. This new function doesn't use the v4l2_queryctrl
      struct anymore, which makes it more general.
      
      The remainder of v4l2-ctrls.c is all new. Highlights include:
      
      - No need to implement VIDIOC_QUERYCTRL, QUERYMENU, S_CTRL, G_CTRL,
        S_EXT_CTRLS, G_EXT_CTRLS or TRY_EXT_CTRLS in either bridge drivers
        or subdevs. New wrapper functions are provided that can just be plugged in.
        Once everything has been converted these wrapper functions can be removed as well.
      
      - When subdevices are added their controls can be automatically merged
        with the bridge driver's controls.
      
      - Most drivers just need to implement s_ctrl to set the controls.
        The framework handles the locking and tries to be as 'atomic' as possible.
      
      - Ready for the subdev device nodes: the same mechanism applies to subdevs
        and their device nodes as well. Sub-device drivers can make controls
        local, preventing them from being merged with bridge drivers.
      
      - Takes care of backwards compatibility handling of VIDIOC_S_CTRL and
        VIDIOC_G_CTRL. Handling of V4L2_CID_PRIVATE_BASE is fully transparent.
        CTRL_CLASS controls are automatically added.
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
      Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      0996517c
  25. 19 5月, 2010 1 次提交
  26. 16 12月, 2009 2 次提交
  27. 19 9月, 2009 2 次提交
  28. 30 3月, 2009 1 次提交
  29. 03 1月, 2009 1 次提交