1. 28 10月, 2012 2 次提交
  2. 27 9月, 2012 1 次提交
  3. 26 9月, 2012 3 次提交
  4. 10 8月, 2012 1 次提交
  5. 19 6月, 2012 1 次提交
  6. 14 5月, 2012 1 次提交
    • 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
  7. 15 2月, 2012 2 次提交
  8. 06 1月, 2012 1 次提交
  9. 31 12月, 2011 3 次提交
  10. 26 11月, 2011 1 次提交
  11. 01 11月, 2011 1 次提交
  12. 21 9月, 2011 1 次提交
  13. 15 9月, 2011 1 次提交
  14. 07 9月, 2011 1 次提交
  15. 28 7月, 2011 2 次提交
    • H
      [media] v4l2-ctrls: fix and improve volatile control handling · ddac5c10
      Hans Verkuil 提交于
      If you have a cluster of controls that is a mix of volatile and non-volatile
      controls, then requesting the value of the volatile control would fail if the
      master control of that cluster was non-volatile. The code assumed that the
      volatile state of the master control was the same for all other controls in
      the cluster.
      
      This is now fixed.
      
      In addition, it was clear from bugs in some drivers that it was confusing that
      the ctrl->cur union had to be used in g_volatile_ctrl. Several drivers used the
      'new' values instead. The framework was changed so that drivers now set the new
      value instead of the current value.
      
      This has an additional benefit as well: the volatile values are now only stored
      in the 'new' value, leaving the current value alone. This is useful for
      autofoo/foo control clusters where you want to have a 'foo' control act like a
      volatile control if 'autofoo' is on, but as a normal control when it is off.
      
      Since with this change the cur value is no longer overwritten when g_volatile_ctrl
      is called, you can use it to remember the original 'foo' value. For example:
      
      autofoo = 0, foo = 10 and foo is non-volatile.
      
      Now autofoo is set to 1 and foo is marked volatile. Retrieving the foo value
      will get the volatile value. Set autofoo back to 0, which marks foo as non-
      volatile again, and retrieving foo will get the old current value of 10.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      ddac5c10
    • M
      [media] radio: Use the subsystem version control for VIDIOC_QUERYCAP · 29834c1a
      Mauro Carvalho Chehab 提交于
      Just like the video drivers, the right thing to do is to use
      the per-subsystem version control.
      Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      29834c1a
  16. 25 5月, 2011 1 次提交
  17. 20 5月, 2011 1 次提交
  18. 01 4月, 2011 1 次提交
  19. 31 3月, 2011 1 次提交
  20. 22 3月, 2011 7 次提交