• Mike Isely's avatar
    V4L/DVB (7321): pvrusb2: Rework context handling and initialization · 794b1607
    Mike Isely authored
    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: default avatarMike Isely <isely@pobox.com>
    Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@infradead.org>
    794b1607
pvrusb2-hdw-internal.h 12.8 KB