1. 25 4月, 2008 5 次提交
    • M
      V4L/DVB (7321): pvrusb2: Rework context handling and initialization · 794b1607
      Mike Isely 提交于
      This change significantly rearranges pvr2_context level initialization
      and operation:
      
      1. A new kernel thread is set up for management of the context.
      
      2. Destruction of the pvr2_context instance is moved into the kernel
         thread.  No other context is able to remove the instance; doing
         this simplifies lock handling.
      
      3. The callback into pvrusb2-main, which is used to trigger
         initialization of each interface, is now issued from this kernel
         thread.  Previously it had been indirectly issued out of the work
         queue thread in pvr2_hdw, which led to deadlock issues if the
         interface needed to change a control setting (which in turn
         requires dispatch of another work queue entry).
      
      4. Callbacks into the interfaces (via the pvr2_channel structure) are
         now issued strictly from this thread.  The net result of this is
         that such callback functions can now also safely operate driver
         controls without deadlocking the work queue.  (At the moment this
         is not actually a problem, but I'm anticipating issues with this in
         the future).
      
      5. There is no longer any need for anyone to enter / exit the
         pvr2_context structure.  Implementation of the kernel thread here
         allows this all to be internal now, simplifying other logic.
      
      6. A very very longstanding issue involving a mutex deadlock between
         the pvrusb2 driver and v4l should now be solved.  The deadlock
         involved the pvr2_context mutex and a globals-protecting mutex in
         v4l.  During initialization the driver would take the pvr2_context
         mutex first then the v4l2 interface would register with v4l and
         implicitly take the v4l mutex.  Later when v4l would call back into
         the driver, the two mutexes could possibly be taken in the opposite
         order, a situation that can lead to deadlock.  In practice this
         really wasn't an issue unless a v4l app tried to start VERY early
         after the driver appeared.  However it still needed to be solved,
         and with the use of the kernel thread relieving need for
         pvr2_context mutex, the problem should be finally solved.
      Signed-off-by: NMike Isely <isely@pobox.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      794b1607
    • M
      V4L/DVB (7313): pvrusb2: Make LED control into a device-specific attribute · 40381cb0
      Mike Isely 提交于
      The pvrusb2 driver has used hardcoded logic to control the LED on the
      device.  However this is really Hauppauge-specific behavior.  This
      change defines a new device attribute for LED control and sets things
      up appropriately for Hauppauge devices.
      Signed-off-by: NMike Isely <isely@pobox.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      40381cb0
    • M
      V4L/DVB (7309): pvrusb2: Enhance core logic to also control digital streaming · 62433e31
      Mike Isely 提交于
      This is a major pvrusb2 change.  The driver core has an algorithm that
      is used to cleanly sequence the changes needed to enable / disable
      video streaming.  The algorithm had originally been written for analog
      streaming, but when in digital mode the pipeline is considerably
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      62433e31
    • M
      V4L/DVB (7305): pvrusb2: whitespace fixup · 7f421fe4
      Mike Isely 提交于
      Signed-off-by: NMike Isely <isely@pobox.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      7f421fe4
    • M
  2. 26 1月, 2008 5 次提交
  3. 22 10月, 2007 1 次提交
  4. 10 10月, 2007 1 次提交
  5. 28 4月, 2007 1 次提交
  6. 21 2月, 2007 7 次提交
  7. 26 9月, 2006 4 次提交
  8. 01 7月, 2006 1 次提交
  9. 27 6月, 2006 4 次提交