| Age | Commit message (Collapse) | Author |
|---|
|
From: Mike Isely <isely@pobox.com>
Previous v4l-dvb changeset id 4cc8ed11e2e0 changed the pvrusb2-hdw
internal API regarding i2c chip debug register access. However that
change failed to also update the corresponding function comment
describing the API. As driver maintained I never saw a request for an
ack on that change; there probably should have been one especially
since the manner in which this API operates was changed - its
interface is now entangled with a v4l specific struct and I would have
preferred to keep this API clear of moving-target v4l-isms such as
this one if at all possible which is why I had done it the way I did
before. But whatever. This commit at least fixes the comment issue.
Priority: normal
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
From: Mike Isely <isely@pobox.com>
Implement a new internal function to create a string device
identifier. This ID stays with the specific device, making it useful
to user space to identify specific devices. We use the serial number
if available; otherwise we give up and just spit out a unit/instance ID.
Priority: normal
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
|
From: Hans Verkuil <hverkuil@xs4all.nl>
Since the i2c driver ID will be removed in the near future we have to
modify the v4l2 debugging API to use the driver name instead of driver ID.
Note that this API is not used in applications other than v4l2-dbg.cpp
as it is for debugging and testing only.
Should anyone use the old VIDIOC_G_CHIP_IDENT, then this will be logged
with a warning that it is deprecated and will be removed in 2.6.30.
Priority: normal
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
|
|
From: Mike Isely <isely@pobox.com>
This builds upon the previous pvrusb2 change to more formally
implement full cropping support. This enables access from the
driver's V4L interface, and enables access to full capabilities from
sysfs as well. Note that this is only effective when in analog mode.
It also will only work when the underlying digitizer's driver (saa7115
or cx25840 depending on the hardware) also implements the appropriate
functions.
Priority: normal
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: vdb128@picaros.org <vdb128@picaros.org>
Implement pvrusb2 driver plumbing to support cropping. Submitted by a
pvrusb2 user.
Priority: normal
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>
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: Adrian Bunk <bunk@kernel.org>
This patch contains the following cleanups:
- make the following needlessly global function static:
- pvr2_hdw_set_cur_freq()
- #if 0 the following unused global functions:
- pvr2_hdw_get_state_name()
- pvr2_hdw_get_debug_info_unlocked()
- pvr2_hdw_get_debug_info_locked()
Signed-off-by: Adrian Bunk <bunk@kernel.org>
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>
There is a callback that is issued to into pvr2_context from pvr2_hdw
after initialization is done. There was a probability that this
callback could get missed. Fixed.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The pvrusb2 driver has used hardcoded logic to control the LED on the
device. However this is really Hauppauge-specific behavior. This
change defines a new device attribute for LED control and sets things
up appropriately for Hauppauge devices.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Most of this originates from Michael Krufky <mkrufky@linuxtv.org>;
these changes move LED control into separate functions. This is the
first step in new work to make LED control a device-specific attribute.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
This is a major pvrusb2 change. The driver core has an algorithm that
is used to cleanly sequence the changes needed to enable / disable
video streaming. The algorithm had originally been written for analog
streaming, but when in digital mode the pipeline is considerably
different - for example the mpeg encoder is not used. These changes
to the core logic implement correct pipeline control when in digital
mode. Knowing which pipeline to handle and how to handle it is
completely driven by the current input selection. So, in theory, to
perform digital stream now all one has to do is switch input to dtv
and start streaming as usual. Well, in theory. The reality is that
digital tuner and demod control are still not in the driver core yet
so until that is present there's nothing to actually stream.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
This code is actually part of a larger set from Mike Krufky
<mkrufky@linuxtv.org>, to support ATSC streaming from within the
pvrusb2 driver. More to come...
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Michael Krufky <mkrufky@linuxtv.org>
Call pvr2_hdw_cmd_powerdown to power down the device
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Previously the pvrusb2 driver just started with the default input to
be "television". But if the device doesn't support an analog tuner
then this default must be different. New logic here selects a
reasonable default based on the actual valid set of available inputs.
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 follows from defining the available inputs as device attributes.
This change causes the driver to adjust its list of inputs based on
those attributes. Now, for example, the FM radio will appear as a
choice only if the hardware supports an FM radio.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Implement additional pvrusb2 device info table entries for a device
identifier and a device description. Export this information via the
driver's internal API. Make this information available via the sysfs
driver interface. Also propagate this information into the v4l2
capability structure. An app can now retrieve and report a
descriptive string about the particular type of hardware device it is
operating.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The pvrusb2 driver currently supports two variants of the Hauppauge
PVR USB2. However there are other hardware types potentially
supportable, but the driver at the moment is not structured to make it
easy to describe these minor variations. This changeset is the first
set of changes to make such additional device support possible.
Device attributes are held in several tables all contained within
pvrusb2-devattr.c; all other device-specific driver behavior now
derives from these tables.
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: Mike Isely <isely@pobox.com>
The pvrusb2 driver already has a method for extracting the FX2's
program memory back out to a user application; this ability is used to
facilitate manual firmware extraction as per the procedure documented
on the pvrusb2 web site. This change follows that pattern and
implements a corresponding method to grab the binary contents of the
PVR USB2 prom (which for PVR USB2 devices can contain information in
addition to the usual Hauppauge metadata).
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mauro Carvalho Chehab <mchehab@infradead.org>
Due to several internal API changes on kernel, kernel backward
compatibility were lost. Basically, compat.h should be the last include
for it to work properly.
This patch basically reorders kernel headers to allow backward compat to
work fine.
Also:
Some includes were added after some non-include macros, on old drivers.
Better to keep all includes at the beginning of the files.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
|
|
From: Mike Isely <isely@pobox.com>
The V4L2 API requires a unique bus_info string returned as part of the
v4l2_capability structure. These changes gather up the USB address
information, from the underlying device, into a string and report that
out through v4l2 and via sysfs (for completeness).
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Hans Verkuil <hverkuil@xs4all.nl>
The chip matching in struct v4l2_register was rather primitive. It could
not be extended to other busses besides i2c and it lacked a way to
differentiate between two i2c chips driven by the same driver on one
board (e.g. a PVR500 with two tuner chips, one for analog TV and one for
radio).
It has now been improved making it much more powerful.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
CC: Mike Isely <isely@isely.net>
CC: Trent Piepho <xyzzy@speakeasy.org>
|
|
From: Mike Isely <isely@pobox.com>
Support 64 bit register IDs internally. Only allow root access to
this API (for both set and get). Note that actual 64 bit access only
becomes possible once the definition for v4l2_register is updated, but
this change clears the way for it from the viewpoint of the pvrusb2
driver.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Trent Piepho <xyzzy@speakeasy.org>
The direct register access ioctls were defined as kernel internal only,
but they are very useful for debugging hardware from userspace and are
used as such. Officially export them.
VIDIOC_INT_[SG]_REGISTER is renamed to VIDIOC_DBG_[SG]_REGISTER
Definition of ioctl and struct v4l2_register is moved from v4l2-common.h
to videodev2.h.
Types used in struct v4l2_register are changed to the userspace
exportable versions (u32 -> __u32, etc).
Use of VIDIOC_DBG_S_REGISTER requires CAP_SYS_ADMIN permission, so move
the check into the video_ioctl2() dispatcher so it doesn't need to be
duplicated in each driver's call-back function.
CAP_SYS_ADMIN check is added to pvrusb2 (which doesn't use video_ioctl2).
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
|
|
From: Mike Isely <isely@pobox.com>
Clean up use of VIDIOC_G_TUNER; we now correctly gather info from all
the I2C client modules. Also abide by V4L2_TUNER_CAP_LOW
appropriately.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Clean up and tighten logic involving stream configuration. This
mainly involves changes to pvrusb2-v4l2.c, where we better clarify how
we use the stream configuration enum and implement a cleaner means to
control streaming for a given device node.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Use separate enum for get/store of minor number; we want pvr2_config
to go away eventually and since it really means something different,
don't use it here
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Pantelis Koukousoulas <pakt223@freemail.gr>
This is the first patch in preparation of the V4L2/IVTV radio interface.
It does away with the assumption of only one minor per device. It also
adds a file to show the radio minor as well. This can be useful for a
program like pvr-radio.c (when it grows up), since this way it can search
for the minor of the /dev/radioX device it opened and use the video minor
of the same driver instance to get to the actual stream.
The implementation looks kinda ugly. Feel free to improve (that is the
reason behind separate patches anyway).
--Pantelis
Signed-off-by: Pantelis Koukousoulas <pakt223@freemail.gr>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Implement VIDIOC_INT_SET_REGISTER and VIDIOC_INT_GET_REGISTER for the
pvrusb2 driver. This is a debugging aid which will not be enabled
unless CONFIG_VIDEO_ADV_DEBUG has been enabled.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Adrian Bunk <bunk@stusta.de>
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 unused global functions
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
|
|
From: Mike Isely <isely@pobox.com>
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>
Subsystem bits are defined as ordinal values now instead of bits in a
mask.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Rework controls internal architecture. Rework video standard
handling. This is a major change.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Rework entire internal controls interface to eliminate the need for
visibly defined control IDs which must otherwise be translated by the
V4L2 public interface. As part of this work, internal structures
which mimiced various V4L2 structures (video standards, audio modes)
have been reworked to actually use the native structures. This
triggered a _significant_ rework for how video standards are dealt
with (and what is in place now should be much more flexible and
forgiving for various handling less-common video standards).
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
When a V4L app queries a pvrusb2 control, make sure we also tell it
what the control's default value is.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Eliminate the need to track the number pvrusb2 CIDs at compile time
from within the pvrusb2 driver. This is part of a control structure
cleanup.
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 change threads logic through the pvrusb2 to make it possible to
command the decoder chip to reset itself. The method is
decoder-agnostic; the part of the pvrusb2 which control's that chip's
module has to provide the final hook. This just lays the foundation.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Rename a pvrusb2 function to reflect its true meaning, and tweak the
driver initialization sequence so that the I2C adapter isn't started
until after the hardware has been given a powerup command.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Hans Verkuil <hverkuil@xs4all.nl>
Add a new audio mode V4L2_TUNER_MODE_LANG1_LANG2 (used by VIDIOC_G/S_TUNER).
This mode allows the user to select both languages of a bilingual transmission,
one language on the left, one on the right audio channel. If there is no
bilingual transmission, or it is not supported, then this mode should act like
V4L2_TUNER_MODE_STEREO.
This mode is introduced for PVR-like drivers where it is useful to be able to
record both languages of a bilingual broadcast.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
|
|
From: Mike Isely <isely@pobox.com>
Clean up a missing const declaration in the initialization pathway of
the pvrusb2 driver.
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: Mike Isely <isely@pobox.com>
The pvrusb2 driver as part of its initialization might have to load
the FX2's firmware image. We must only do this when it is actually
needed. The previous method just detected this requirement by
noticing something unusual about the USB configuration of the device.
Unfortunately with newer PVR USB2 devices this method no longer works.
What we do now is also attempt a simple non-destructive endpoint 1
transaction; failure of that transfer will indicate a need to load the
firmware.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
|
