We know that the 300msec settling time after starting the digitizer is
only really needed when the digitizer is a SAA7115. So if we're not
using a SAA7115, skip the delay.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After implementing a 300msec wait between digitizer start and encoder
start, it has been determined that we don't need to wait quite as long
before configuring the encoder. This reduces the wait period from
100msec back to 50msec.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Martin Dauskardt <martin.dauskardt@gmx.de> has determined that the
encoder has a much better chance of starting cleanly if we
deliberately hold off starting it util the video digitizer has had a
chance to run for at least 300msec first. These changes implement an
enforced 300msec wait in the state machine that orchestrates streaming
start / stop.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This change attempts to fix the ivtv tinny audio problem by keeping digitizer
to encoder audio clocks running, while disabling the video clocks as needed to
avoid unpredictable PCI bus hangs.
To accomplish this, for the cx25840 module enabling of audio streaming had
to be separated from enabling video streaming, requiring an additional
v4l2_subdev_audio_op and calls to this new op in the pvrusb2 and ivtv drivers.
The cx231xx and cx23885 driver use the cx25840 module for affecting only
video on s_stream calls, so those drivers needed no change.
The CX23418 hardware does not exhibit either the tinny audio problem nor the PCI
bus hang, so the cx18 driver did not need corresponding changes.
CX2341[56] based cards that are not using the CX2584x family of chips
do not seem to be affected by the tinny audio problem, and this change should
not affect how they are configured. It will delay their first capture by
starting by another 300 msec though.
Many thanks go to Argus <pthorn-ivtvd@styx2002.no-ip.org> and
Martin Dauskardt <martin.dauskardt@gmx.de> whose persistent testing and
investigation of this problem will hopefully fix this problem once and for all
for many ivtv users.
Reported-by: Martin Dauskardt <martin.dauskardt@gmx.de>
Reported-by: Argus <pthorn-ivtvd@styx2002.no-ip.org>
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix all device drivers to use the new video_device_node_name function.
This also strips kernel log messages from the "/dev/" prefix, has the device
node location is a userspace policy decision unknown to the kernel.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (345 commits)
V4L/DVB (13542): ir-keytable: Allow dynamic table change
V4L/DVB (13541): atbm8830: replace 64-bit division and floating point usage
V4L/DVB (13540): ir-common: Cleanup get key evdev code
V4L/DVB (13539): ir-common: add __func__ for debug messages
V4L/DVB (13538): ir-common: Use a dynamic keycode table
V4L/DVB (13537): ir: Prepare the code for dynamic keycode table allocation
V4L/DVB (13536): em28xx: Use the full RC5 code on HVR-950 Remote Controller
V4L/DVB (13535): ir-common: Add a hauppauge new table with the complete RC5 code
V4L/DVB (13534): ir-common: Remove some unused fields/structs
V4L/DVB (13533): ir: use dynamic tables, instead of static ones
V4L/DVB (13532): ir-common: Add infrastructure to use a dynamic keycode table
V4L/DVB (13531): ir-common: rename the debug routine to allow exporting it
V4L/DVB (13458): go7007: subdev conversion
V4L/DVB (13457): s2250: subdev conversion
V4L/DVB (13456): s2250: Change module structure
V4L/DVB (13528): em28xx: add support for em2800 VC211A card
em28xx: don't reduce scale to half size for em2800
em28xx: don't load audio modules when AC97 is mis-detected
em28xx: em2800 chips support max width of 640
V4L/DVB (13523): dvb-bt8xx: fix compile warning
...
Fix up trivial conflicts due to spelling fixes from the trivial tree in
Documentation/video4linux/gspca.txt
drivers/media/video/cx18/cx18-mailbox.h
These are additional fixes to enable proper pvrusb2 support of 16KB
sized FX2 firmware.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The device text description in pvrusb2-devattr.c get mapped into a V4L
API string field that is unfortunately shorter than I expected. No
sense fighting City Hall here - this change shortens the descriptions
to fit the limit.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This pvrusb2 change is in support of an existing feature used to help
identify and locate newer vendor supplied firmware. This change makes
the feature work for the newer larger firmware size.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
New FX2 firmware from Hauppauge is no longer 8KB in size - it's 16KB.
This is true for HVR-1950 and HVR-1900 devices. Without this change,
new pvrusb2 users with that hardware are unable to use the driver
(because the CD shipped with the hardware only has the 16KB firmware).
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After detecting failure due to module initialization error, get out.
Don't report jammed hardware. Problem due to a missing break statement.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver also contains a piece of configuration data that produces a
one line description of the specific hardware being driver
(e.g. "Hauppauge 24xxx", "OnAir", etc). This change generates an
informational message to the kernel log reporting the hardware type
being driven. This is a very useful thing to know when diagnosing
problems.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It used to be that the only real detectable reason for the driver to
fail during initialization would be that if the hardware is simply
jammed. However with the advent of the sub-device mechanism in V4L it
is possible now to detect if a sub-device module fails to load
successfully. The pvrusb2 driver does in fact react to this by also
(correctly) failing, however the original diagnostic message "hardware
is jammed" was still being reported. This misleads the user because
in fact it might not actually be a hardware failure. This change adds
logic to tell the difference and then report a more appropriate
message to the kernel log.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
pvrusb2: Encoder failures are mostly recoverable by the driver. While
it would sure be nice not to have the failure happen in the first
place, this has been going on for years and I doubt that a real
solution will ever present itself. I think that part's firmware is
just slightly flakey and we have to deal with it. The driver does
deal with it just fine, but the warning message going into the kernel
log is probably a little more alarming than it should be. So try to
soften up the warning somewhat.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
pvrusb2: Associate V4L device node in sysfs with the underlying USB
device. This opens the door to device information tracking in udev
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rewrite v4l2_i2c_new_subdev as a simplified version of v4l2_i2c_new_subdev_cfg
and remove v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr.
This simplifies this API substantially.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Enable the standby mode optimization to disable the tda18271
slave tuner output / loop thru options when in low power mode
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is no point in defining I2C adapter IDs when no code is using
them. As this field might go away in the future, stop using it when
we don't need to.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This change does not change any outward behavior; it merely chops down
some large if-conditions with embedded assignments into something a
little more maintainable for others (I of course never had a problem
with this...).
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The pvrusb2 driver has a concept of "routing scheme" which defines
which physical inputs should be connected based on application's
choice of logical input. The correct "routing scheme" depends on the
specific device since different devices might wire up their muxes
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change default frequency to be US Broadcast channel 3 - with the
transition to d igital the previous value has now become useless.
This change is PURELY to help with my testing (I need to set some kind
of default so it might as well be some thing usable).
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The cx25840 module's VBI initialization logic uses the current video
standard as part of its internal algorithm. This therefore means that
we probably need to make sure that the correct video standard has been
set before initializing VBI. (Normally we would not care about VBI,
but as described in an earlier changeset, VBI must be initialized
correctly on the cx25840 in order for the chip's hardware scaler to
operate correctly.)
It's kind of messy to force the video standard to be set before
initializing VBI (mainly because we can't know what the app really
wants that early in the initialization process). So this patch does
the next best thing: VBI is re-initialized after any point where the
video standard has been set.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The cx25840 module requires that its VBI initialization entry point be
called in order for hardware-scaled video capture to work properly -
even if we don't care about VBI. Making this behavior even more
subtle is that if the capture resolution is set to 720x480 - which is
the default that the pvrusb2 driver sets up - then the cx25840
bypasses the hardware scaler. Therefore this problem does not
manifest itself until some other resolution, e.g. 640x480, is tried.
MythTV typically defaults to 640x480 or 480x480, which means that
things break whenever the driver is used with MythTV.
This all has been known for a while (since at least Nov 2006), but
recent changes in the pvrusb2 driver (specifically in regards to
sub-device support) caused this to break again. VBI initialization
must happen *after* the chip's firmware is loaded, not before. With
this fix, 24xxx devices work correctly again.
A related fix that is part of this changeset is that now we
re-initialize VBI any time after we issue a reset to the cx25840
driver. Issuing a chip reset erases the state that the VBI setup
previously did. Until the HVR-1950 came along this subtlety went
unnoticed, because the pvrusb2 driver previously never issued such a
reset. But with the HVR-1950 we have to do that reset in order to
correctly transition from digital back to analog mode - and since the
HVR-1950 always starts in digital mode (required for the DVB side to
initialize correctly) then this device has never had a chance to work
correctly in analog mode! Analog capture on the HVR-1950 has been
broken this *ENTIRE* time. I had missed it until now because I've
usually been testing at the default 720x480 resolution which does not
require scaling... What fun. By re-initializing VBI after a cx25840
chip reset, correct behavior is restored.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
pvrusb2: Ensure we specify I/F's for all bandwidths
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Acked-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that the ir-kbd-i2c driver has been converted to a new-style i2c
driver, we can instantiate the ir_video I2C device by default. The
pvr2_disable_ir_video is kept to disable the IR receiver, either
because the user doesn't use it, or for debugging purpose.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
... else DVB-T tuning will not work.
Signed-off-by: Steven Toth <stoth@linuxtv.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The i2c core used to maintain a list of client for each adapter. This
is a duplication of what the driver core already does, so this list
will be removed as part of a future cleanup. Anyone using this list
must stop doing so.
For pvrusb2, I propose the following change, which should lead to an
equally informative output. The only difference is that i2c clients
which are not a v4l2 subdev won't show up, but I guess this case is
not supposed to happen anyway.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Kick up the pvrusb2 version number advertised through the v4l
interface. This value really has almost no meaning because I don't
make a serious attempt to version the driver in this manner (otherwise
this one line becomes a nasty hotspot of changes and merge
conflicts). The value that is here is really a historical thing.
However Hans Verkuil thought it might be a good idea to bump up the
number anyway right now since the driver's mechanism for communicating
with the v4l core has pretty much completely changed. Sending out a
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This sets the disable_autoload_ir_video module option to being set,
which disables any attempt by the driver to autoload IR support. This
changes preserves previous behavior, for now. This change can be set
back concurrent with other changes that finally update i2c-kbd-i2c to
use the new i2c binding model.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The ir-kbd-i2c module is about to be updated to match the new style
i2c binding model. These pvrusb2 changes maintain compatibility with
that change. Note that this does not actually break anything even
without the expected ir-kbd-i2c changes yet because previously the
pvrusb2 didn't autoload ir-kbd-i2c anyway.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This change defines all possible "IR schemes" related to the pvrusb2
driver, on a per-device basis. That information is then set according
to the hardware in use. The idea here is to make possible a more
intelligent future decision on which, if any, IR receiver driver might
be loaded during initialization.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the near future, the driver core is going to not allow direct access
to the driver_data pointer in struct device. Instead, the functions
dev_get_drvdata() and dev_set_drvdata() should be used. These functions
have been around since the beginning, so are backwards compatible with
all older kernel versions.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Wireless USB endpoint state has a sequence number and a current
window and not just a single toggle bit. So allow HCDs to provide a
endpoint_reset method and call this or clear the software toggles as
required (after a clear halt, set configuration etc.).
usb_settoggle() and friends are then HCD internal and are moved into
core/hcd.h and all device drivers call usb_reset_endpoint() instead.
If the device endpoint state has been reset (with a clear halt) but
the host endpoint state has not then subsequent data transfers will
not complete. The device will only work again after it is reset or
disconnected.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The client_register and client_unregister methods are optional so
there is no point in defining stub ones. Especially when these methods
are likely to be removed soon.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is no longer needed to use a struct pointer as argument, since v4l2_subdev
doesn't require that ioctl-like approach anymore. Instead just pass the input,
output and config (new!) arguments directly.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The functions v4l2_i2c_new_subdev and v4l2_i2c_new_probed_subdev relied on
i2c_get_adapdata to return the v4l2_device. However, this is not always
possible on embedded platforms. So modify the API to pass the v4l2_device
pointer explicitly.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
s_std didn't belong in the tuner ops. Stricly speaking it should be part of
the video ops, but it is used by audio and tuner devices as well, so it is
more efficient to make it part of the core ops.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The init callback was used in several places to load firmware. Make a separate
load_fw callback for that. This makes the code a lot more understandable.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Any time a struct (especially one not defined by this driver) is
allocated, we MUST zero its underlying storage. This makes our usage
of the struct predictable and robust against future changes where
fields might be added that we don't know about. Failing to do this
with tuner_setup left the config field uninitialized which then caused
trouble with the tuner type used for HVR-1950 devices.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Mike Isely