Don't trigger a pathway state change if it's already been triggered
(eliminates some wasted processing and some debug output noise)
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the
beginning of the declaration specifiers in a declaration is an
obsolescent feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
The pvrusb2 tear-down logic was clearing two timers before stopping
its internal work queue. That left a tiny window open where the work
queue might run after the timers are stopped, possibly starting them
again. This could lead to dangling pointers and an oops. Solution:
Kill the work queue first, then delete the timers.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The encoder is not a part of the pipeline when in digital mode, so
streaming is OK in this case even when the encoder's firmware is not
loaded. Modify the driver core handling of this scenario to permit
streaming.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This is a major pvrusb2 change. The driver core has an algorithm that
is used to cleanly sequence the changes needed to enable / disable
video streaming. The algorithm had originally been written for analog
streaming, but when in digital mode the pipeline is considerably
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Unlike analog control, control of the digital side is not nearly as
uniform among different devices. So we have to specify the correct
digital control scheme as a new device attribute.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
- Static memory is always initialized with 0.
- Replaced in some cases C99 comments for /* */
Signed-off-by: Douglas Schilling Landgraf <dougsland@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
None of these files use any of the functionality promised by
asm/semaphore.h. It's possible that they rely on it dragging in some
unrelated header file, but I can't build all these files, so we'll have
fix any build failures as they come up.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
The pvrusb2 driver tries to keep all device specific attributes in a
single data structure in one source file. This change further cleans
up how that table is set up. We now try to group everything together
for each specific device, and the number of symbols exported from this
module has now been reduced to a single global.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
pvrusb2: When a per-device-type default video standard is declared,
handle it in such a way that it can be correctly and unambiguously
reported in the system log.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This adds a default video standard setting to the pvr2_device_desc
structure for describing device types. With this change it is
possible to set a reasonable default standard based on device type.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Arrange so that the pvrusb2 driver can optionally work without a
Hauppauge ROM being present - which is fairly important for devices
that happen to not come from Hauppauge. The expected existence of a
Hauppauge ROM is now a device attribute. The tuner type is now also a
device attribute, which is consulted if there is no ROM.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Correctly mark when a tuner type is set. Report more faithfully
information about known supported device video standards.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Device-specific driver behavior is now defined by generic device
characteristics rather than by specific device model information.
With this change, the hardware type field can go away, thus this
change.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
This is a minor change to help with tracking the viability of the
encoder chip within the PVR USB2 device.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
It's useful to see specific details for how the pvrusb2 driver is
figuring out things related to the video standard, independent of
other initialization activities. So let's set up a separate debug
mask bit for this and turn it on.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The v4l tveeprom logic tells us what video standards are supported by
the hardware, however it doesn't directly tell us what should be the
preferred initial standard. For example "NTSC/NTSC-J" devices are
reported by tveeprom as support NTSC-M and PAL-M, and while that might
be true, in the vast majority of cases NTSC-M is really what the user
is going to want. However the driver previously just arbitrarily
picked the "lowest numbered" standard as the initial default, which in
that case would have been PAL-M. (And making matters more confusing -
this only caused real problems on 24xxx devices because the saa7115 on
29xxx seems to autodetect the right answer anyway.) This change
implements an algorithm that uses the set of "supported" standards as
a hint to decide on the initial standard. This algorithm ONLY comes
into play if the driver isn't specifically told what to do; said
another way - the user can always still change the standard via the
sysfs interface, via the usual V4L methods, or even specified as a
module parameter. The idea here is only to pick a better starting
point if the user (or app) doesn't otherwise do something to set the
standard; otherwise this change has no real impact.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This is a bunch of cleanup in various places to improve behavior based
on actual device type being driven. While this doesn't actually
affect operation with existing devices, it cleans things up so that it
will be easier / more deterministic when other devices are added.
Ideally we should make stuff like this table-driven, but for now this
is just a series of small incremental (read: safe) improvements.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The driver should now pass the 'busy' state of the device to the cx2341x
module whenever controls are set or tried. -EBUSY will be returned if
the device is busy and the user attempts to modify certain 'dangerous'
controls. It concerns controls that change the audio or video
compression mode and bitrates.
The cx88-blackbird and pvrusb2 drivers currently always pass '0' (not busy)
to the cx2341x, effectively keeping the old behavior for now.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The pvrusb2 driver use a semaphore as mutex. use the mutex API instead
of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke <matthias.kaehlcke@gmail.com>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The chip matching in struct v4l2_register for VIDIOC_DBG_G/S_REGISTER
was rather primitive. It could not be extended to other busses besides
i2c and it lacked a way to.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The pvrusb2 driver previously rejected encoder firmware whose size was
not a multiple of 8192. But this is a false check because it's
possible to find cx23416 firmware whose size doesn't conform to this
limit. So change the firmware loader implementation to be more
forgiving of the image size.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
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>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Several special-case FX2 commands were being issued through
pvr2_write_u16() and pvr2_write_8(), but there's really nothing
special case about them. These date from a very early time in the
driver development. This patch removes these functions and replaces
their use with calls to pvr2_send_request.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This is a maintainability cleanup; use nice names for all the FX2
commands instead of raw bytes. This way we can easily find where we
issue FX commands.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
