korg/linux
0
0
Fork 0
mirror of https://mirrors.bfsu.edu.cn/git/linux.git synced 2024-11-19 02:04:19 +08:00
Code Issues Packages Projects Releases Wiki Activity
f0f4ae763b
linux/drivers/media/video/pvrusb2/pvrusb2-context.c

432 lines
10 KiB
C
Raw Normal View History

V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
/*
*
* Copyright (C) 2005 Mike Isely <isely@pobox.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
#include "pvrusb2-context.h"
#include "pvrusb2-io.h"
#include "pvrusb2-ioread.h"
#include "pvrusb2-hdw.h"
#include "pvrusb2-debug.h"
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
#include <linux/wait.h>
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
#include <linux/kthread.h>
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
#include <linux/errno.h>
#include <linux/string.h>
#include <linux/slab.h>
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
static struct pvr2_context *pvr2_context_exist_first;
static struct pvr2_context *pvr2_context_exist_last;
static struct pvr2_context *pvr2_context_notify_first;
static struct pvr2_context *pvr2_context_notify_last;
static DEFINE_MUTEX(pvr2_context_mutex);
static DECLARE_WAIT_QUEUE_HEAD(pvr2_context_sync_data);
V4L/DVB (7714): pvrusb2: Fix hang on module removal The pvrusb2 driver was getting had by this scenario: 1. Task A calls kthread_stop() for task B. 2. Before exiting, then Task B calls kthread_stop() for task C. The problem is, kthread_stop() wants to allocate an internal resource to itself (i.e. acquire a lock), which won't be released until kthread_stop() returns. But kthread_stop() won't return until task B is dead. But task B won't die until it finishes its call to kthread_stop() for task C, and that will block waiting on the resource already allocated inside task A. Deadlock. With the pvrusb2 driver, task A is the caller to pvr_exit(), task B is the control thread run inside of pvrusb2-context.c, and task C is any worker thread run inside of pvrusb2-hdw.c. This problem got introduced by the previous threading setup change, which was itself an attempt to fix a module tear-down race (which it actually did fix). The lesson here is that a task being waited on as part of a kthread_stop() simply cannot be allow to also issue a kthread_stop() - or we make sure not to issue the enclosing kthread_stop() until we know that the inner kthread_stop() has completed first. The solution for the pvrusb2 driver is some hackish code which changes the main control thread tear down into a two step process. This then makes it possible to delay issuing the kthread_stop() on the control thread until after we know that everything has been torn down first. (And yes, we really need that kthread_stop() because it's the only way to safely guarantee that a module-referencing kernel thread has safely returned back out of the module before we finally remove the module.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-09 16:14:11 +08:00
static DECLARE_WAIT_QUEUE_HEAD(pvr2_context_cleanup_data);
static int pvr2_context_cleanup_flag;
static int pvr2_context_cleaned_flag;
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
static struct task_struct *pvr2_context_thread_ptr;
static void pvr2_context_set_notify(struct pvr2_context *mp, int fl)
{
int signal_flag = 0;
mutex_lock(&pvr2_context_mutex);
if (fl) {
if (!mp->notify_flag) {
signal_flag = (pvr2_context_notify_first == NULL);
mp->notify_prev = pvr2_context_notify_last;
mp->notify_next = NULL;
pvr2_context_notify_last = mp;
if (mp->notify_prev) {
mp->notify_prev->notify_next = mp;
} else {
pvr2_context_notify_first = mp;
}
mp->notify_flag = !0;
}
} else {
if (mp->notify_flag) {
mp->notify_flag = 0;
if (mp->notify_next) {
mp->notify_next->notify_prev = mp->notify_prev;
} else {
pvr2_context_notify_last = mp->notify_prev;
}
if (mp->notify_prev) {
mp->notify_prev->notify_next = mp->notify_next;
} else {
pvr2_context_notify_first = mp->notify_next;
}
}
}
mutex_unlock(&pvr2_context_mutex);
if (signal_flag) wake_up(&pvr2_context_sync_data);
}
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
static void pvr2_context_destroy(struct pvr2_context *mp)
{
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
pvr2_trace(PVR2_TRACE_CTXT,"pvr2_context %p (destroy)",mp);
V4L/DVB (6691): pvrusb2: Rework pipeline state control This is a new implementation for video pipeline control within the pvrusb2 driver. Actual start/stop of the pipeline is moved to the driver's kernel thread. Pipeline stages are controlled autonomously based on surrounding pipeline or application control state. Kernel thread management is also cleaned up and moved into the internal control structure of the driver, solving a set up / tear down race along the way. Better failure recovery is implemented with this new control strategy. Also with this change comes better control of the cx23416 encoder, building on additional information learned about the peculiarities of controlling this part (this information was the original trigger for this rework). With this change, overall encoder stability should be considerably improved. Yes, this is a large change for this driver, but due to the nature of the feature being worked on, the changes are fairly pervasive and would be difficult to break into smaller pieces with any semblence of step-wise stability. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2007-11-26 12:48:52 +08:00
if (mp->hdw) pvr2_hdw_destroy(mp->hdw);
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
pvr2_context_set_notify(mp, 0);
mutex_lock(&pvr2_context_mutex);
if (mp->exist_next) {
mp->exist_next->exist_prev = mp->exist_prev;
} else {
pvr2_context_exist_last = mp->exist_prev;
}
if (mp->exist_prev) {
mp->exist_prev->exist_next = mp->exist_next;
} else {
pvr2_context_exist_first = mp->exist_next;
}
if (!pvr2_context_exist_first) {
/* Trigger wakeup on control thread in case it is waiting
for an exit condition. */
wake_up(&pvr2_context_sync_data);
}
mutex_unlock(&pvr2_context_mutex);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
kfree(mp);
}
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
static void pvr2_context_notify(struct pvr2_context *mp)
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
{
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
pvr2_context_set_notify(mp,!0);
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
}
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
static void pvr2_context_check(struct pvr2_context *mp)
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
{
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
struct pvr2_channel *ch1, *ch2;
pvr2_trace(PVR2_TRACE_CTXT,
"pvr2_context %p (notify)", mp);
if (!mp->initialized_flag && !mp->disconnect_flag) {
mp->initialized_flag = !0;
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
pvr2_trace(PVR2_TRACE_CTXT,
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
"pvr2_context %p (initialize)", mp);
/* Finish hardware initialization */
if (pvr2_hdw_initialize(mp->hdw,
(void (*)(void *))pvr2_context_notify,
mp)) {
mp->video_stream.stream =
pvr2_hdw_get_video_stream(mp->hdw);
/* Trigger interface initialization. By doing this
here initialization runs in our own safe and
cozy thread context. */
if (mp->setup_func) mp->setup_func(mp);
} else {
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
pvr2_trace(PVR2_TRACE_CTXT,
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
"pvr2_context %p (thread skipping setup)",
mp);
/* Even though initialization did not succeed,
we're still going to continue anyway. We need
to do this in order to await the expected
disconnect (which we will detect in the normal
course of operation). */
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
}
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
}
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
for (ch1 = mp->mc_first; ch1; ch1 = ch2) {
ch2 = ch1->mc_next;
if (ch1->check_func) ch1->check_func(ch1);
}
if (mp->disconnect_flag && !mp->mc_first) {
/* Go away... */
pvr2_context_destroy(mp);
return;
}
}
static int pvr2_context_shutok(void)
{
V4L/DVB (7714): pvrusb2: Fix hang on module removal The pvrusb2 driver was getting had by this scenario: 1. Task A calls kthread_stop() for task B. 2. Before exiting, then Task B calls kthread_stop() for task C. The problem is, kthread_stop() wants to allocate an internal resource to itself (i.e. acquire a lock), which won't be released until kthread_stop() returns. But kthread_stop() won't return until task B is dead. But task B won't die until it finishes its call to kthread_stop() for task C, and that will block waiting on the resource already allocated inside task A. Deadlock. With the pvrusb2 driver, task A is the caller to pvr_exit(), task B is the control thread run inside of pvrusb2-context.c, and task C is any worker thread run inside of pvrusb2-hdw.c. This problem got introduced by the previous threading setup change, which was itself an attempt to fix a module tear-down race (which it actually did fix). The lesson here is that a task being waited on as part of a kthread_stop() simply cannot be allow to also issue a kthread_stop() - or we make sure not to issue the enclosing kthread_stop() until we know that the inner kthread_stop() has completed first. The solution for the pvrusb2 driver is some hackish code which changes the main control thread tear down into a two step process. This then makes it possible to delay issuing the kthread_stop() on the control thread until after we know that everything has been torn down first. (And yes, we really need that kthread_stop() because it's the only way to safely guarantee that a module-referencing kernel thread has safely returned back out of the module before we finally remove the module.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-09 16:14:11 +08:00
return pvr2_context_cleanup_flag && (pvr2_context_exist_first == NULL);
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
}
static int pvr2_context_thread_func(void *foo)
{
struct pvr2_context *mp;
pvr2_trace(PVR2_TRACE_CTXT,"pvr2_context thread start");
do {
while ((mp = pvr2_context_notify_first) != NULL) {
pvr2_context_set_notify(mp, 0);
pvr2_context_check(mp);
}
wait_event_interruptible(
pvr2_context_sync_data,
((pvr2_context_notify_first != NULL) ||
pvr2_context_shutok()));
} while (!pvr2_context_shutok());
V4L/DVB (7714): pvrusb2: Fix hang on module removal The pvrusb2 driver was getting had by this scenario: 1. Task A calls kthread_stop() for task B. 2. Before exiting, then Task B calls kthread_stop() for task C. The problem is, kthread_stop() wants to allocate an internal resource to itself (i.e. acquire a lock), which won't be released until kthread_stop() returns. But kthread_stop() won't return until task B is dead. But task B won't die until it finishes its call to kthread_stop() for task C, and that will block waiting on the resource already allocated inside task A. Deadlock. With the pvrusb2 driver, task A is the caller to pvr_exit(), task B is the control thread run inside of pvrusb2-context.c, and task C is any worker thread run inside of pvrusb2-hdw.c. This problem got introduced by the previous threading setup change, which was itself an attempt to fix a module tear-down race (which it actually did fix). The lesson here is that a task being waited on as part of a kthread_stop() simply cannot be allow to also issue a kthread_stop() - or we make sure not to issue the enclosing kthread_stop() until we know that the inner kthread_stop() has completed first. The solution for the pvrusb2 driver is some hackish code which changes the main control thread tear down into a two step process. This then makes it possible to delay issuing the kthread_stop() on the control thread until after we know that everything has been torn down first. (And yes, we really need that kthread_stop() because it's the only way to safely guarantee that a module-referencing kernel thread has safely returned back out of the module before we finally remove the module.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-09 16:14:11 +08:00
pvr2_context_cleaned_flag = !0;
wake_up(&pvr2_context_cleanup_data);
pvr2_trace(PVR2_TRACE_CTXT,"pvr2_context thread cleaned up");
wait_event_interruptible(
pvr2_context_sync_data,
kthread_should_stop());
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
pvr2_trace(PVR2_TRACE_CTXT,"pvr2_context thread end");
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
return 0;
}
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
int pvr2_context_global_init(void)
{
pvr2_context_thread_ptr = kthread_run(pvr2_context_thread_func,
media: fix integer as NULL pointer warnings drivers/media/video/v4l2-common.c:719:16: warning: Using plain integer as NULL pointer drivers/media/video/au0828/au0828-dvb.c:122:19: warning: Using plain integer as NULL pointer drivers/media/video/ivtv/ivtv-yuv.c:1101:22: warning: Using plain integer as NULL pointer drivers/media/video/ivtv/ivtv-yuv.c:1102:23: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-audio.c:78:39: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-video-v4l.c:84:39: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-v4l2.c:1264:9: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-context.c:197:28: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c:126:39: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-dvb.c:133:32: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-dvb.c:145:31: warning: Using plain integer as NULL pointer drivers/media/video/pvrusb2/pvrusb2-dvb.c:177:55: warning: Using plain integer as NULL pointer drivers/media/video/videobuf-core.c:100:9: warning: Using plain integer as NULL pointer Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-29 07:50:03 +08:00
NULL,
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
"pvrusb2-context");
return (pvr2_context_thread_ptr ? 0 : -ENOMEM);
}
void pvr2_context_global_done(void)
{
V4L/DVB (7714): pvrusb2: Fix hang on module removal The pvrusb2 driver was getting had by this scenario: 1. Task A calls kthread_stop() for task B. 2. Before exiting, then Task B calls kthread_stop() for task C. The problem is, kthread_stop() wants to allocate an internal resource to itself (i.e. acquire a lock), which won't be released until kthread_stop() returns. But kthread_stop() won't return until task B is dead. But task B won't die until it finishes its call to kthread_stop() for task C, and that will block waiting on the resource already allocated inside task A. Deadlock. With the pvrusb2 driver, task A is the caller to pvr_exit(), task B is the control thread run inside of pvrusb2-context.c, and task C is any worker thread run inside of pvrusb2-hdw.c. This problem got introduced by the previous threading setup change, which was itself an attempt to fix a module tear-down race (which it actually did fix). The lesson here is that a task being waited on as part of a kthread_stop() simply cannot be allow to also issue a kthread_stop() - or we make sure not to issue the enclosing kthread_stop() until we know that the inner kthread_stop() has completed first. The solution for the pvrusb2 driver is some hackish code which changes the main control thread tear down into a two step process. This then makes it possible to delay issuing the kthread_stop() on the control thread until after we know that everything has been torn down first. (And yes, we really need that kthread_stop() because it's the only way to safely guarantee that a module-referencing kernel thread has safely returned back out of the module before we finally remove the module.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-09 16:14:11 +08:00
pvr2_context_cleanup_flag = !0;
wake_up(&pvr2_context_sync_data);
wait_event_interruptible(
pvr2_context_cleanup_data,
pvr2_context_cleaned_flag);
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
kthread_stop(pvr2_context_thread_ptr);
}
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
struct pvr2_context *pvr2_context_create(
struct usb_interface *intf,
const struct usb_device_id *devid,
void (*setup_func)(struct pvr2_context *))
{
V4L/DVB (4288): Clean out a zillion sparse warnings in pvrusb2 Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-30 22:35:28 +08:00
struct pvr2_context *mp = NULL;
V4L/DVB (5091): Pvrusb2: Use kzalloc in place of kmalloc/memset pairs Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2007-01-20 11:37:11 +08:00
mp = kzalloc(sizeof(*mp),GFP_KERNEL);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
if (!mp) goto done;
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
pvr2_trace(PVR2_TRACE_CTXT,"pvr2_context %p (create)",mp);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
mp->setup_func = setup_func;
mutex_init(&mp->mutex);
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
mutex_lock(&pvr2_context_mutex);
mp->exist_prev = pvr2_context_exist_last;
mp->exist_next = NULL;
pvr2_context_exist_last = mp;
if (mp->exist_prev) {
mp->exist_prev->exist_next = mp;
} else {
pvr2_context_exist_first = mp;
}
mutex_unlock(&pvr2_context_mutex);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
mp->hdw = pvr2_hdw_create(intf,devid);
if (!mp->hdw) {
pvr2_context_destroy(mp);
V4L/DVB (4288): Clean out a zillion sparse warnings in pvrusb2 Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-30 22:35:28 +08:00
mp = NULL;
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
goto done;
}
V4L/DVB (7711): pvrusb2: Fix race on module unload The pvrusb2 driver - for basically forever - was not enforcing a proper module tear-down. Kernel threads are used inside the driver and all must be gone before the module can be safely removed. This changeset reimplements a chunk of pvrusb2-context.c to enforce this correctly. Unfortunately this is not a simple fix. The new implementation also cuts back on kernel thread usage; instead of there being 1 control thread per instance now it's just 1 control thread shared by all instances. (By dropping to a single thread then the module exit function can block on its shutdown and the thread itself can monitor and cleanly shut down all of the other instances first.) Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-07 13:22:04 +08:00
pvr2_context_set_notify(mp, !0);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
done:
return mp;
}
V4L/DVB (7719): pvrusb2: Implement input selection enforcement In the pvrusb2 driver, different interfaces (e.g. V4L, DVB) have Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-21 14:47:43 +08:00
static void pvr2_context_reset_input_limits(struct pvr2_context *mp)
{
unsigned int tmsk,mmsk;
struct pvr2_channel *cp;
struct pvr2_hdw *hdw = mp->hdw;
mmsk = pvr2_hdw_get_input_available(hdw);
tmsk = mmsk;
for (cp = mp->mc_first; cp; cp = cp->mc_next) {
if (!cp->input_mask) continue;
tmsk &= cp->input_mask;
}
pvr2_hdw_set_input_allowed(hdw,mmsk,tmsk);
pvr2_hdw_commit_ctl(hdw);
}
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
static void pvr2_context_enter(struct pvr2_context *mp)
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
{
mutex_lock(&mp->mutex);
}
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
static void pvr2_context_exit(struct pvr2_context *mp)
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
{
int destroy_flag = 0;
if (!(mp->mc_first || !mp->disconnect_flag)) {
destroy_flag = !0;
}
mutex_unlock(&mp->mutex);
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
if (destroy_flag) pvr2_context_notify(mp);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
}
void pvr2_context_disconnect(struct pvr2_context *mp)
{
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
pvr2_hdw_disconnect(mp->hdw);
mp->disconnect_flag = !0;
pvr2_context_notify(mp);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
}
void pvr2_channel_init(struct pvr2_channel *cp,struct pvr2_context *mp)
{
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
pvr2_context_enter(mp);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
cp->hdw = mp->hdw;
cp->mc_head = mp;
V4L/DVB (4288): Clean out a zillion sparse warnings in pvrusb2 Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-30 22:35:28 +08:00
cp->mc_next = NULL;
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
cp->mc_prev = mp->mc_last;
if (mp->mc_last) {
mp->mc_last->mc_next = cp;
} else {
mp->mc_first = cp;
}
mp->mc_last = cp;
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
pvr2_context_exit(mp);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
}
static void pvr2_channel_disclaim_stream(struct pvr2_channel *cp)
{
if (!cp->stream) return;
pvr2_stream_kill(cp->stream->stream);
V4L/DVB (4288): Clean out a zillion sparse warnings in pvrusb2 Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-30 22:35:28 +08:00
cp->stream->user = NULL;
cp->stream = NULL;
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
}
void pvr2_channel_done(struct pvr2_channel *cp)
{
struct pvr2_context *mp = cp->mc_head;
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
pvr2_context_enter(mp);
V4L/DVB (7719): pvrusb2: Implement input selection enforcement In the pvrusb2 driver, different interfaces (e.g. V4L, DVB) have Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-21 14:47:43 +08:00
cp->input_mask = 0;
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
pvr2_channel_disclaim_stream(cp);
V4L/DVB (7719): pvrusb2: Implement input selection enforcement In the pvrusb2 driver, different interfaces (e.g. V4L, DVB) have Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-21 14:47:43 +08:00
pvr2_context_reset_input_limits(mp);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
if (cp->mc_next) {
cp->mc_next->mc_prev = cp->mc_prev;
} else {
mp->mc_last = cp->mc_prev;
}
if (cp->mc_prev) {
cp->mc_prev->mc_next = cp->mc_next;
} else {
mp->mc_first = cp->mc_next;
}
V4L/DVB (4288): Clean out a zillion sparse warnings in pvrusb2 Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-30 22:35:28 +08:00
cp->hdw = NULL;
V4L/DVB (7321): pvrusb2: Rework context handling and initialization 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: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:45 +08:00
pvr2_context_exit(mp);
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
}
V4L/DVB (7719): pvrusb2: Implement input selection enforcement In the pvrusb2 driver, different interfaces (e.g. V4L, DVB) have Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-21 14:47:43 +08:00
int pvr2_channel_limit_inputs(struct pvr2_channel *cp,unsigned int cmsk)
{
unsigned int tmsk,mmsk;
int ret = 0;
struct pvr2_channel *p2;
struct pvr2_hdw *hdw = cp->hdw;
mmsk = pvr2_hdw_get_input_available(hdw);
cmsk &= mmsk;
if (cmsk == cp->input_mask) {
/* No change; nothing to do */
return 0;
}
pvr2_context_enter(cp->mc_head);
do {
if (!cmsk) {
cp->input_mask = 0;
pvr2_context_reset_input_limits(cp->mc_head);
break;
}
tmsk = mmsk;
for (p2 = cp->mc_head->mc_first; p2; p2 = p2->mc_next) {
if (p2 == cp) continue;
if (!p2->input_mask) continue;
tmsk &= p2->input_mask;
}
if (!(tmsk & cmsk)) {
ret = -EPERM;
break;
}
tmsk &= cmsk;
if ((ret = pvr2_hdw_set_input_allowed(hdw,mmsk,tmsk)) != 0) {
/* Internal failure changing allowed list; probably
should not happen, but react if it does. */
break;
}
cp->input_mask = cmsk;
pvr2_hdw_commit_ctl(hdw);
} while (0);
pvr2_context_exit(cp->mc_head);
return ret;
}
unsigned int pvr2_channel_get_limited_inputs(struct pvr2_channel *cp)
{
return cp->input_mask;
}
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
int pvr2_channel_claim_stream(struct pvr2_channel *cp,
struct pvr2_context_stream *sp)
{
int code = 0;
pvr2_context_enter(cp->mc_head); do {
if (sp == cp->stream) break;
V4L/DVB (7306): pvrusb2: Fix oops possible when claiming a NULL stream Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2008-04-23 01:45:39 +08:00
if (sp && sp->user) {
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
code = -EBUSY;
break;
}
pvr2_channel_disclaim_stream(cp);
if (!sp) break;
sp->user = cp;
cp->stream = sp;
} while (0); pvr2_context_exit(cp->mc_head);
return code;
}
// This is the marker for the real beginning of a legitimate mpeg2 stream.
static char stream_sync_key[] = {
0x00, 0x00, 0x01, 0xba,
};
struct pvr2_ioread *pvr2_channel_create_mpeg_stream(
struct pvr2_context_stream *sp)
{
struct pvr2_ioread *cp;
cp = pvr2_ioread_create();
V4L/DVB (4288): Clean out a zillion sparse warnings in pvrusb2 Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-30 22:35:28 +08:00
if (!cp) return NULL;
V4L/DVB (4228a): pvrusb2 to kernel 2.6.18 Implement V4L2 driver for the Hauppauge PVR USB2 TV tuner. The Hauppauge PVR USB2 is a USB connected TV tuner with an embedded cx23416 hardware MPEG2 encoder. There are two major variants of this device; this driver handles both. Any V4L2 application which understands MPEG2 video stream data should be able to work with this device. Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2006-06-27 07:58:46 +08:00
pvr2_ioread_setup(cp,sp->stream);
pvr2_ioread_set_sync_key(cp,stream_sync_key,sizeof(stream_sync_key));
return cp;
}
/*
Stuff for Emacs to see, in order to encourage consistent editing style:
*** Local Variables: ***
*** mode: c ***
*** fill-column: 75 ***
*** tab-width: 8 ***
*** c-basic-offset: 8 ***
*** End: ***
*/
Reference in New Issue Copy Permalink