1. 02 10月, 2012 1 次提交
  2. 26 9月, 2012 2 次提交
  3. 19 9月, 2012 1 次提交
    • A
      [media] ivtv, ivtv-alsa: Add initial ivtv-alsa interface driver for ivtv · 269c11fb
      Andy Walls 提交于
      This is a cut-and-paste port of the cx18-alsa driver to
      create an ivtv-alsa interface module for the ivtv driver.
      It is not actually hooked-up to the PCM stream DMA buffers
      from the ivtv driver yet.  That will be done in a coming change,
      since that portion is so very different from the cx18 driver.
      This code has all or more of the bugs and shortcomings of the
      cx18-alsa interface driver: inconsistent use of itvsc->slock,
      ivtv-alsa-mixer.c is dead code, assumes 48 ksps regardless
      of the actual setting of the audio capture, problems with
      proper struct ivtv and struct ivtv_stream housekeeping,
      struct ivtv_open_id.v4l2_fh abuse, and $DIETY knows what else.
      Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      269c11fb
  4. 16 8月, 2012 1 次提交
  5. 10 8月, 2012 1 次提交
  6. 07 7月, 2012 1 次提交
  7. 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
  8. 08 3月, 2012 1 次提交
  9. 14 2月, 2012 2 次提交
  10. 24 1月, 2012 1 次提交
  11. 16 1月, 2012 2 次提交
  12. 01 6月, 2011 1 次提交
  13. 23 3月, 2011 1 次提交
  14. 09 8月, 2010 1 次提交
  15. 03 8月, 2010 2 次提交
    • I
      V4L/DVB: ivtv: Automatic firmware reload · 215659d1
      Ian Armstrong 提交于
      If the firmware has failed, this patch will automatically reload &
      restart the card. The previous card state will be restored on a
      successful restart.  Firmware reload will only happen if neither the
      encoder or decoder is active.  If the card is busy then behaviour is as
      before, returning -EIO on device access until the reload can occur. On
      cards that support video output, coloured bars will be displayed during
      the reload.
      
      Andy Walls (ivtv maintainer and patch committer) made minor tweaks to
      comments and the logged messages, but nothing substantial otherwise.
      Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
      Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      215659d1
    • I
      V4L/DVB: ivtv: Add firmare monitoring and debug mode to ignore firmware problems · 914610e8
      Ian Armstrong 提交于
      >From Ian's e-mail:
      When a device is opened the firmware state will be checked. If it isn't
      responding then the open will fail with -EIO.  Due to the nature of the
      hardware, a single failed check will block everything since we don't know
      exactly what has failed. A side effect of this is the blocking of debug
      access, so an additional debug level has been created which allows the block
      to be bypassed.
      
      Andy Walls' modifications:
      I modified Ian's patch to add a separate fw_debug module parameter to change
      the driver's behavior, as opposed to using the normal debug module parameter.
      The fw_debug module parameter is only available when CONFIG_VIDEO_ADV_DEBUG
      is set.
      I also made some minor whitespace adjustments and changed some warning
      messages to be a bit more specific.  s/happy/glad/g
      Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk>
      Signed-off-by: NAndy Walls <awalls@md.metrocast.net>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      914610e8
  16. 09 7月, 2010 1 次提交
  17. 01 6月, 2010 2 次提交
  18. 19 5月, 2010 2 次提交
  19. 18 5月, 2010 2 次提交
  20. 27 2月, 2010 2 次提交
    • A
      V4L/DVB: ivtv: Adjust msleep() delays used to prevent tinny audio and PCI bus hang · 95480f27
      Andy Walls 提交于
      Martin Dauskardt <martin.dauskardt@gmx.de> has done extensive testing on what
      values can be used and and concluded that only 300 ms total is required to
      avoid bad video effects such as occasional black screen and short sync
      disturbances.  Furthermore he determined how this 300 ms was split between
      the two msleep()s did matter very much, so he suggested 150ms/150ms as one
      acceptable alternative that is implemented here.
      
      Many thanks go to Martin.
      Tested-by: NMartin Dauskardt <martin.dauskardt@gmx.de>
      Signed-off-by: NAndy Walls <awalls@radix.net>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      95480f27
    • A
      V4L/DVB: cx25840, v4l2-subdev, ivtv, pvrusb2: Fix ivtv/cx25840 tinny audio · 3ccc646b
      Andy Walls 提交于
      This change attempts to fix the ivtv tinny audio problem by keeping digitizer
      to encoder audio clocks running, while disabling the video clocks as needed to
      avoid unpredictable PCI bus hangs.
      
      To accomplish this, for the cx25840 module enabling of audio streaming had
      to be separated from enabling video streaming, requiring an additional
      v4l2_subdev_audio_op and calls to this new op in the pvrusb2 and ivtv drivers.
      
      The cx231xx and cx23885 driver use the cx25840 module for affecting only
      video on s_stream calls, so those drivers needed no change.
      
      The CX23418 hardware does not exhibit either the tinny audio problem nor the PCI
      bus hang, so the cx18 driver did not need corresponding changes.
      
      CX2341[56] based cards that are not using the CX2584x family of chips
      do not seem to be affected by the tinny audio problem, and this change should
      not affect how they are configured. It will delay their first capture by
      starting by another 300 msec though.
      
      Many thanks go to Argus <pthorn-ivtvd@styx2002.no-ip.org> and
      Martin Dauskardt <martin.dauskardt@gmx.de> whose persistent testing and
      investigation of this problem will hopefully fix this problem once and for all
      for many ivtv users.
      Reported-by: NMartin Dauskardt <martin.dauskardt@gmx.de>
      Reported-by: NArgus <pthorn-ivtvd@styx2002.no-ip.org>
      Signed-off-by: NAndy Walls <awalls@radix.net>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      3ccc646b
  21. 16 12月, 2009 1 次提交
  22. 19 9月, 2009 2 次提交
  23. 30 3月, 2009 1 次提交
  24. 03 1月, 2009 1 次提交
  25. 30 12月, 2008 2 次提交
  26. 22 10月, 2008 1 次提交
  27. 13 10月, 2008 1 次提交
  28. 12 10月, 2008 1 次提交
    • H
      V4L/DVB (9133): v4l: disconnect kernel number from minor · dd89601d
      Hans Verkuil 提交于
      The v4l core creates four different video devices (video, vbi, radio, vtx)
      and each has its own range of minor numbers. However, modern devices keep
      increasing the number of devices that they need so a maximum of 64 video
      devices will not be enough in the future. In addition this scheme makes
      it very hard to add new device types.
      
      This patch disconnects the kernel number allocation (e.g. video0, video1,
      etc.) from the actual minor number (just pick the first free minor).
      
      This allows for much more flexibility in the future. However, it does
      require the use of udev. For those who cannot use udev a new CONFIG option
      was created that changes the allocation scheme back to the old behavior.
      
      Thanks to Greg KH for suggesting this approach during the 2008 LPC.
      
      In addition, several bugs were fixed in the ivtv and cx18 drivers: these
      drivers try to allocate specific kernel numbers but that scheme contained
      a bug which caused what should have been e.g. video17 to appear as e.g.
      video2.
      Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      dd89601d
  29. 04 9月, 2008 1 次提交
  30. 27 7月, 2008 1 次提交