V4L/DVB (6238): bw-qcam: use data_reverse instead of manually poking the control register
Fixes use of parport_write_control() to match the newer interface that
requires explicit parport_data_reverse() and parport_data_forward() calls.
This eliminates the following error message and restores the original
intended behavior:
parport0 (bw-qcam): use data_reverse for this!
Also increases threshold in qc_detect() from 300 to 400, as my camera often
results in a count of approx 330. Added a kernel error message to indicate
detection failure.
Thanks Ray and Randy for your comments, and for pointing out that I
needed to reset the port to forward mode!
Signed-off-by: Brett T. Warden <brett.warden@gmail.com> Acked-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Andres Salomon [Wed, 19 Sep 2007 05:44:18 +0000 (02:44 -0300)]
V4L/DVB (6235): cafe_ccic: default to allocating DMA buffers at probe time
By default, we allocate DMA buffers when actually reading from the video
capture device. On a system with 128MB or 256MB of ram, it's very easy
for that memory to quickly become fragmented. We've had users report
having 30+MB of memory free, but the cafe_ccic driver is still unable to
allocate DMA buffers.
Our workaround has been to make use of the 'alloc_bufs_at_load' parameter
to allocate DMA buffers during device probing. This patch makes DMA
buffer allocation happen during device probe by default, and changes
the parameter to 'alloc_bufs_at_read'. The camera hardware is there,
if the cafe_ccic driver is enabled/loaded it should do its best to ensure
that the camera is actually usable; delaying DMA buffer allocation
saves an insignicant amount of memory, and causes the driver to be much
less useful.
Signed-off-by: Andres Salomon <dilinger@debian.org> Acked-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Michael Krufky [Fri, 7 Sep 2007 21:27:43 +0000 (18:27 -0300)]
V4L/DVB (6230): dvb-pll: add module option to force dvb-pll desc id (for debug use only)
Add a module option to force the dvb-pll module to use an alternate dvb-pll
description without having to recompile the kernel.
Having a module option like this is useful in some cases, where the vendor
may release an alternate revision of the hardware using a different tuner,
but without changing the pci subsystem / usb device ids.
This option is intended for debugging purposes _only_.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Michael Krufky [Fri, 7 Sep 2007 21:19:57 +0000 (18:19 -0300)]
V4L/DVB (6228): dvb-pll: add module option to specify rf input
Add a module option to dvb-pll, called "input" to specify which rf
input to use on devices with multiple rf inputs. If the module option
is not specified, then the driver will autoselect the rf input, as per
previous behavior.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Michael Krufky [Fri, 7 Sep 2007 21:03:58 +0000 (18:03 -0300)]
V4L/DVB (6226): dvb-pll: pass fe pointer into dvb_pll_configure() and set() functions
The pll-specific set() function will need access to the dvb_pll_priv
structure for new functionality. This patch gives access to this
structure to the required functions.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
V4L/DVB (6215): Bugfix for saa6588.c, add forgotten spin_lock_init()
There's a serious bug in saa6588.c, it uses a non-initialized spin_lock.
Funny thing is that it works fine with bttv, but completly freezes the
machine if e.g. saa7134 is loaded.
Thanks to Derek Philip for reporting this bug on the rdsd-devel list.
This patch adds the missing spin_lock_init().
Signed-off-by: Hans J. Koch <hjk@linutronix.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Jean Delvare [Sun, 9 Sep 2007 09:17:44 +0000 (06:17 -0300)]
V4L/DVB (6214): usbvision: Don't support I2C_M_REV_DIR_ADDR
I2C adapters should only support I2C_M_REV_DIR_ADDR if they really have
to (i.e. if they are connected to a broken I2C device which needs this
deviation from the standard I2C protocol.) As no media chip driver
uses I2C_M_REV_DIR_ADDR, I don't think that the usbvision driver needs
to support it.
Jean Delvare [Sun, 9 Sep 2007 02:19:32 +0000 (23:19 -0300)]
V4L/DVB (6212): pvrusb2: I2C adapter tweaks from Jean Delvare
* I2C adapters aren't expected to handle I2C_M_NOSTART unless they
really have to. As the pvrusb2 driver doesn't support it, I take it
that it doesn't need it so it shouldn't mention it at all.
* I2C_FUNC_SMBUS_EMUL includes I2C_FUNC_SMBUS_BYTE_DATA so listing
both is redundant.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Mike Isely [Sun, 9 Sep 2007 01:32:12 +0000 (22:32 -0300)]
V4L/DVB (6211): pvrusb2: Allocate a debug mask bit for reporting video standard things
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>
Mike Isely [Sun, 9 Sep 2007 01:28:51 +0000 (22:28 -0300)]
V4L/DVB (6210): pvrusb2: Do a far better job at setting the default initial video standard
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>
Mike Isely [Sun, 9 Sep 2007 01:18:50 +0000 (22:18 -0300)]
V4L/DVB (6209): pvrusb2: Better discriminate among device types
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>
Mike Isely [Sun, 9 Sep 2007 01:16:27 +0000 (22:16 -0300)]
V4L/DVB (6208): pvrusb2: Implement programmatic means to extract prom contents
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>
Simon Farnsworth [Mon, 10 Sep 2007 16:37:26 +0000 (13:37 -0300)]
V4L/DVB (6203): Fix SVideo input on KWorld DVB-T 220 boards
Fix SVideo input on KWorld DVB-T 220 boards. Without this patch, the
luma pin on the SVideo input is treated as a composite in, and the
chroma pin is ignored.
Also, fix the radio, and provide a second composite input for people who
are used to the existing composite on SVideo connector behaviour.
Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Reviewed-by: Hermann Pitton <hermann-pitton@arcor.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Michael Krufky [Sat, 8 Sep 2007 18:17:13 +0000 (15:17 -0300)]
V4L/DVB (6196): cx23885: add support for DViCO FusionHDTV 5 Express
This patch adds digital ATSC / QAM support for the DViCO FusionHDTV5 Express.
Remote control is supported by ir-kbd-i2c, RTC is supported by rtc-isl1208.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Steven Toth <stoth@hauppauge.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
V4L/DVB (6184): cx88-alsa: Make volume control stereo
Use the balance control to make the mono volume control stereo.
Note that full range isn't supported. The balance control attenuates one
channel by 0 to -63 dB, and the volume control provides additional attenuation
to both channels by another 0 to -63 dB.
So the channel with the most attenuation has a range of 0 to -126 dB, while
the other channel only has a range of 0 to -63 dB. ALSA volume controls don't
appear to support this concept. I just limited the range to 0 to -63 total.
Once you get to -63 dB, you're already at silence, so additional attenuation
is pretty much pointless anyway.
Steven Toth [Wed, 5 Sep 2007 00:50:49 +0000 (21:50 -0300)]
V4L/DVB (6173): cx23885: Minor cleanup and important NMI comment placed in code
I wanted to document the NMI assert issue inside the code, even though
it's already documented in the patch history. If/when the next cx23887
revision appears, is may need to be enabled on that also.
Signed-off-by: Steven Toth <stoth@hauppauge.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Steven Toth [Tue, 20 Mar 2007 18:27:53 +0000 (15:27 -0300)]
V4L/DVB (6158): Fix MT2131 tuner lock status problem
The mt2131 tuner reports lock even when the hardware should not
lock. This patch allows the s5h1409 demodulator to be configured to query
either the tuner driver for status, or the demodulator status when the
application requests lock status. This avoids returning false CARRIER
and/or SIGNAL lock status.
S5H1409 and MT2131 drivers. This is the remainder of the changeset, which
only touches cx23885-dvb.c
Signed-off-by: Steven Toth <stoth@hauppauge.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Steven Toth [Mon, 19 Mar 2007 21:01:07 +0000 (18:01 -0300)]
V4L/DVB (6155): Cleanup/remove code to access the sram memory maps
The cx23885 and cx23887 family use two different memory maps which govern
how the internal SRAM is configured. This patch streamlines the access to those
structures.
Signed-off-by: Steven Toth <stoth@hauppauge.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Steven Toth [Mon, 19 Mar 2007 20:46:03 +0000 (17:46 -0300)]
V4L/DVB (6154): NMI hang and corrupt transport packet fixes
The sram allocations for the cx23887 differ slightly from the cx23885.
This patch modifies the cx23887 specific sram memory map to reflect this.
As a result, interrupts and DMA handling have also been enabled in
cx23885_start_dma() for 887 specific boards.
ATSC streaming is now available on cx23885 and cx23887 bridges.
Signed-off-by: Steven Toth <stoth@hauppauge.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Michael Krufky [Fri, 31 Aug 2007 02:00:43 +0000 (23:00 -0300)]
V4L/DVB (6136): dvb_frontend: add get_rf_strength function pointer to dvb_tuner_ops
Add get_rf_strength function pointer to dvb_tuner_ops, so that rf signal
strength can be read directly from the tuner driver by the dvb demodulator
driver and / or the analog tuning system.
This is an internal api addition -- userspace is not affected.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Acked-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Michael Krufky [Tue, 28 Aug 2007 00:59:35 +0000 (21:59 -0300)]
V4L/DVB (6134): tuner: alter build to produce separate modules
Break tuner.ko into separate modules. This was a quick change -
Tuner sub-drivers are still static-linked to tuner.ko, this will
change after using dvb_attach and removing the probing functions.
After this change, one can deselect undesired tuner sub-drivers via Kconfig.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Acked-by: Mike Isely <isely@pobox.com> Acked-by: Steven Toth <stoth@hauppauge.com> Acked-by: Patrick Boettcher <pb@linuxtv.org> Acked-by: Jarod Wilson <jwilson@redhat.com> Acked-by: Trent Piepho <xyzzy@speakeasy.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Michael Krufky [Tue, 28 Aug 2007 00:24:27 +0000 (21:24 -0300)]
V4L/DVB (6132): tea5767: convert from tuner sub-driver into dvb_frontend module
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Acked-by: Mike Isely <isely@pobox.com> Acked-by: Steven Toth <stoth@hauppauge.com> Acked-by: Patrick Boettcher <pb@linuxtv.org> Acked-by: Jarod Wilson <jwilson@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Michael Krufky [Tue, 28 Aug 2007 00:23:40 +0000 (21:23 -0300)]
V4L/DVB (6131): tea5761: convert from tuner sub-driver into dvb_frontend module
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Acked-by: Mike Isely <isely@pobox.com> Acked-by: Steven Toth <stoth@hauppauge.com> Acked-by: Patrick Boettcher <pb@linuxtv.org> Acked-by: Jarod Wilson <jwilson@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Michael Krufky [Tue, 21 Aug 2007 04:24:42 +0000 (01:24 -0300)]
V4L/DVB (6127): tuner: kill i2c_client interface to tuner sub-drivers
To ease the conversion of the analog tuner sub-drivers into dvb_frontend
style tuner modules, we must remove the i2c_client interface.
dvb_frontend style tuner modules use i2c_transfer directly on the i2c_adapter.
This change only alters the interface between tuner.ko and the tuner
sub-drivers. The v4l2 / i2c_client interface to tuner.ko remains intact.
This patch adds inline functions tuner_i2c_xfer_send, and tuner_i2c_xfer_recv,
to replace i2c_master_send and i2c_master_recv inside the tuner sub-drivers.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Acked-by: Mike Isely <isely@pobox.com> Acked-by: Steven Toth <stoth@hauppauge.com> Acked-by: Patrick Boettcher <pb@linuxtv.org> Acked-by: Jarod Wilson <jwilson@redhat.com> Acked-by: Trent Piepho <xyzzy@speakeasy.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Michael Krufky [Tue, 28 Aug 2007 20:20:42 +0000 (17:20 -0300)]
V4L/DVB (6126): tuner: add warning for obsolete i2c address range 0x64 thru 0x6f
The tuner module has a rather aggressive range of possible i2c addresses.
As per the specs available, it appears as if there are no 4-byte tuners that
actually use i2c addresses in the range 0x64 thru 0x6f, yet, tuner-core claims
the address range 0x60 thru 0x6f.
Allowing tuner.ko to probe these addresses can cause potential damage to
certain IR receivers, RTC chips or any other IC's that might otherwise reside
on the i2c bus using one of these addresses.
The plan is to remove these i2c addresses from the i2c address range of the
tuner module. If any devices are discovered that actually do have tuners at
one of these addresses, the newer i2c probing methods will be used to handle
those cases.
In order to collect this information and avoid any potential regressions,
the following warning has been added upon successful detection of a tuner
using an i2c address in the range 0x64 thru 0x6f:
====================== WARNING! ======================
Support for tuners in i2c address range 0x64 thru 0x6f
will soon be dropped. This message indicates that your
hardware has a {tuner name} tuner at i2c address {addr}.
To ensure continued support for your device, please
send a copy of this message, along with full dmesg
output to v4l-dvb-maintainer@linuxtv.org
Please use subject line: "obsolete tuner i2c address."
====================== WARNING! ======================
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Tyler Trafford [Tue, 28 Aug 2007 20:56:47 +0000 (17:56 -0300)]
V4L/DVB (6124): cx25840: add a few 10 microsecond delays
There were a couple of places in the cx25840 initialization where the
datasheet called for a 10 microsecond delay, which we ignored because
of the 10 usec I2C delay. Put them in anyway now that the I2C delay
was decreased to 5 usec.
Hans Verkuil [Sun, 26 Aug 2007 09:04:10 +0000 (06:04 -0300)]
V4L/DVB (6119): ivtvfb: renamed ivtv-fb to ivtvfb, move header to include/linux
The convention for framebuffer devices is to call them xxxfb, not xxx-fb.
Conform to this. Also move the ivtvfb.h header to include/linux: it is a
public header. The FBIO_WAITFORVSYNC ioctl is now also defined in the
ivtvfb.h header, no more need to include matroxfb.h for just this ioctl.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Hans Verkuil [Sat, 25 Aug 2007 17:11:23 +0000 (14:11 -0300)]
V4L/DVB (6116): ivtv: VBI cleanups and fixes
Besides some VBI cleanups this patch also fixes a subtle problem with the
VBI re-insertion stream where the PIO work handler wasn't called quickly
enough, resulting in occasional corrupt data.
Furthermore the CC output didn't disable CC correctly and at the right time,
causing duplicates to be sent.
An saa7127 fix for VPS output was also added: the wrong data was sent.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Hans Verkuil [Sun, 26 Aug 2007 13:53:16 +0000 (10:53 -0300)]
V4L/DVB (6112): cx25840: use a workqueue to load the firmware
Loading the firmware using the i2c bit-banging code blocks the kernel.
Move the firmware load code into a workqueue so that it plays well with
other processes.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
projects / linux-2.6-omap-h63xx.git / log