| Age | Commit message (Collapse) | Author |
|---|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Hans Verkuil <hverkuil@xs4all.nl>
Phase 4 removes the compatibility support for kernels < 2.6.16.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
In the pvrusb2 driver, different interfaces (e.g. V4L, DVB) have
different abilities to handle various inputs. While the driver core
can handle them all, the interfaces currently are not able to do this.
Also, due to the fact that the DVB interface is directly touching the
hardware, this limits what the V4L side can possibly do with digital
reception, i.e. it has no means to control the digital tuner. This
change implements a critical new feature in the driver where the
interface instance can declare which inputs it is able to handle. The
driver core then uses this information to narrow the list of legal
input selections based on which interface(s) are active at the moment.
The driver core will also perform an input switch (and consequently a
mode switch) if the new narrowed list doesn't include the current
mode. The overall effect of all of this is that now when a user opens
the DVB interface, then the driver flips to dtv mode and likewise when
the V4L video device is opened, the driver will disallow dtv
selection. This also cleans up the handling of the V4L radio device -
open that device and the driver will narrow to just the radio input.
If the narrowing request results in the null set, e.g. attempting to
narrow to dtv only while streaming analog, then the operation is
disallowed and the caller gets an error. This has the effect of
locking out mutually incompatible interfaces. For example, an attempt
to operate a V4L interface will definitively fail when DVB is active.
Thus we have locking and enforcement between the DVB and V4L sides.
Hopefully at some point in the future we can expand the supported
inputs in each interface, and at that point, the interface can just
declare an expanded set of handled inputs and everything should
continue to work itself out. This is a significant feature; it
finally enables cooperative handling of pvrusb2-driven devices between
DVB and V4L.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
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>
|
|
From: Mike Isely <isely@pobox.com>
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>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
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>
|
|
From: Trent Piepho <xyzzy@speakeasy.org>
Add -include linux/version.h to the cflags. Now code can have backward
compatibility test without including compat.h first.
Linux headers included from compat.h are removed, so that code will get
the same headers when compiling in v4l-dvb as it does in the kernel.
Many drivers have compat.h moved to the end of their include list, as
this lets compat.h do things it can't do at the beginning. Such as test
of something is defined to include compat code, or to put a wrapper
around a function without changing the function's name.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
|
|
From: Mike Isely <isely@pobox.com>
Trying to temporarily check that the stream is not claimed during open
of the radio device is at best a race condition. What's to stop
another app from claiming the stream anyway the instant after the
check is done? The implementation for this was dicey anyway. So it's
removed. The only "price" for this is that if /dev/radioX is opened
while streaming video, then the video stream is just going to switch
to radio mode anyway. If a user does this, he gets what he expects...
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Pantelis Koukousoulas <pakt223@freemail.gr>
Add (and expose) a new function, pvr2_channel_check_stream_no_lock(), in
pvrusb2-context.c. This is hopefully the last V4L2 interface related patch
to change anything outside pvrusb2-v4l2.c.
We need this to implement the open() for the radio device. The reason is
that within the *enter_context() section of open() we need to ensure nobody
is streaming and if we cannot, we should cleanup after ourselves and return
-EBUSY. We cannot just use claim_stream() because
1) That would cause a deadlock trying to re-acquire the context lock
2) We only need to ensure that nobody is streaming. We don't need to
actually acquire the stream.
Again, this is a kinda ugly patch. Feel free to improve.
Signed-off-by: Pantelis Koukousoulas <pakt223@freemail.gr>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The correct mutex header to grab is linux/mutex.h, and while
asm/mutex.h seems to work for x86 architecture, it has been reported
not to work for amd64 architecture. So let's just do this right.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The PVR USB2 hardware seems to like emitting some garbage data before
real stream data appears. This problem has been present all along,
but with the older 29xxx model series it was benign because the
garbage data in question didn't seem to bother mpeg2 players. But
with the 24xxx model series, the garbage data includes what looks like
a corrupted mpeg2 packet, which kills mythtv and ffmpeg. This fix
causes incoming stream data to be discarded until valid mpeg2 data is
seen.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Notice and track actual hardware type of device. This information is
also used now to select the correct FX2 firmware file to load (because
they can be different, unfortunately).
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
|
