1. 19 6月, 2012 1 次提交
  2. 21 5月, 2012 1 次提交
  3. 20 5月, 2012 1 次提交
  4. 19 5月, 2012 1 次提交
  5. 15 5月, 2012 7 次提交
  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. 11 4月, 2012 8 次提交
  8. 20 3月, 2012 7 次提交
  9. 08 3月, 2012 1 次提交
    • G
      [media] em28xx: pre-allocate DVB isoc transfer buffers · 86d38d1e
      Gianluca Gennari 提交于
      On MIPS/ARM set-top-boxes, as well as old x86 PCs, memory allocation failures
      in the em28xx driver are common, due to memory fragmentation over time, that
      makes impossible to allocate large chunks of coherent memory.
      A typical system with 256/512 MB of RAM fails after just 1 day of uptime (see
      the old thread for detailed reports and crashlogs).
      
      In fact, the em28xx driver allocates memory for USB isoc transfers at runtime,
      as opposite to the dvb-usb drivers that allocates the USB buffers when the
      device is initialized, and frees them when the device is disconnected.
      
      Moreover, in digital mode the USB isoc transfer buffers are freed, allocated
      and cleared every time the user selects a new channel, wasting time and
      resources.
      
      This patch solves both problems by allocating DVB isoc transfer buffers in
      em28xx_usb_probe(), and freeing them in em28xx_usb_disconnect().
      In fact, the buffers size and number depend only on the max USB packet size
      that is parsed from the USB descriptors in em28xx_usb_probe(), so it can
      never change for a given device.
      
      This approach makes no sense in analog mode (as the buffer size depends on
      the alternate mode selected at runtime), the patch creates two separate sets
      of buffers for digital and analog modes.
      
      For digital-only devices, USB buffers are created when the device is probed
      and freed when the device is disconnected.
      For analog-only devices, nothing changes: isoc buffers are created at runtime.
      For hybrid devices, two sets of buffers are maintained: the digital-mode
      buffers are created when the device is probed, and freed when the device is
      disconnected; analog-mode buffers are created/destroyed at runtime as before.
      So, in analog mode, digital and analog buffers coexists at the same time: this
      can be justified by the fact that digital mode is by far more commonly used
      nowadays, so it makes sense to optimize the driver for this use case scenario.
      
      The patch has been tested in the last few days on a x86 PC and a MIPS
      set-top-box, with the PCTV 290e (digital only) and the Terratec Hybrid XS
      (hybrid device). With the latter, I switched several times between analog and
      digital mode (Kaffeine/TvTime) with no issue at all.
      I unplugged/plugged the devices several times with no problem.
      Also, after over 3 days of normal usage in the MPIS set-top-box, the PCTV 290e
      was still up and running.
      Signed-off-by: NGianluca Gennari <gennarone@gmail.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      86d38d1e
  10. 24 1月, 2012 1 次提交
  11. 11 1月, 2012 5 次提交
  12. 07 1月, 2012 1 次提交
  13. 06 1月, 2012 5 次提交