Don't allow the tda8290 module to probe and attach the tuner module,
causing incorrect use counts when using dvb_attach.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Prevent the tda8290 module from probing for tuners during tda829x_attach,
by passing:
.probe_tuner = TDA829X_DONT_PROBE,
...in struct tda829x_config
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Identify the silicon during attach, return NULL if unsupported device.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Bit 7 of both Main Divider byte 1 and Cal Divider byte 1 is always zero.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Fixes all occurences of assignment in if
checkpatch marks them as ERROR.
Signed-off-by: Matthias Schwarzott <zzam@gentoo.org>
Reviewed-by: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Add module option 'alt_tuner' disabled by default.
When set to one, the dvb_frontend of HVR1800 will consist of:
s5h1409 demod + tda18271 tuner
When set zero (default), the dvb_frontend of HVR1800 will consist of:
s5h1409 demod + mt2131 tuner
If the tda18271 is used in digital mode, you will not be able to
tune an analog channel at the same time.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
If we are selecting the S-Code firmware to load by name, then we must mask
off the HAS_IF bit during the search.
Signed-off-by: Chris Pascoe <c.pascoe@itee.uq.edu.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Fix the following build warning:
xc5000.c:560: warning: format '%d' expects type 'int',
but argument 2 has type 'size_t'
On many architectrues size_t is unsigned long, and may not be printed with %d.
Use %Zu instead.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
xc2028_attach was returning an integer when disabled from the build, where it
should instead be returning NULL. Declare xc2028_attach as type dvb_frontend *
instead of void *.
The prototype declaration must be marked as extern in the header.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
We want to set bits 1 & 2 on easy programming byte 4, not extended byte 4.
Thanks to David Wong for pointing this out.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Cc: David Wong <davidtlwong@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This translates much of the xceive coding style, adds
some result codes and generally cleans up whitespace
and function arguments.
Signed-off-by: Steven Toth <stoth@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This is an all formats tuner, QAM, ATSC, DVB-T and others.
Only ATSC and QAM have been tested.
Signed-off-by: Steven Toth <stoth@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Rather than using a pointer, include struct analog_demod_ops directly
inside struct dvb_frontend. This will allow us to use dvb_attach in
the future, along with removing the need to check the ops structure
before having to check the pointer to the method being called.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
struct analog_tuner_ops no longer has any dependencies specific
to v4l2, so we can move this into dvb_frontend.h with the rest
of the tuning structures.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
tuner_count is already declared as "extern unsigned const int"
in <media/tuner-types.h> -- Remove it from tuner-driver.h
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
In my testing yesterday, I was using a scan file tailored specifically
for a unique test situation -- As it turns out, this scan file was bad,
and I will use the one included inside dvb-apps for testing for now on.
I've tested with other ATSC tuners just to confirm, using:
us-ATSC-center-frequencies-8VSB
Anyhow, as it turns out, the tuner-xc2028 *does* require a tuning offset
for ATSC. Even though the linux-dvb api passes in center frequencies
from userspace, apparantly the xceive firmware is already factoring in
the tuning offset to center.
In order to make the device function using the same scan files /
channels.conf configurations as other atsc devices, we must offset by
1.75 MHz.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
do { \
if (debug) printk(KERN_DEBUG "mt312: " args); \
} while (0)
So no caller need to specify KERN_DEBUG.
Signed-off-by: Matthias Schwarzott <zzam@gentoo.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
For some reason the include header wasn't changed from v4l2-i2c-drv-legacy.h
to v4l2-i2c-drv.h in the previous patch. This is now corrected.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Thanks to Steve Toth from Hauppauge with providing me with the information
needed to add support for these models.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
When an I2C message specifies a write then a read from the same I2C address,
we need to tell the chip to not release the bus between the message parts.
Signed-off-by: Chris Pascoe <c.pascoe@itee.uq.edu.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Some more I2C traces and a experimentation with register values on
both the ZL10353 and MT352 mean that I can now guess at what more
of the ZL10353 registers do.
Guess at the registers' names (based on the equivalent names in MT352)
and update set_parameters/get_parameters with the new knowledge.
Signed-off-by: Chris Pascoe <c.pascoe@itee.uq.edu.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
It seems that the DTV78 firmware is intended for use in locations where
VHF channels have 7MHz bandwidth and UHF channels have 8MHz bandwidth.
If we switch to DTV78 firmware when we detect this condition, we can
avoid firmware reloads when switching between VHF and UHF transponders.
Place the state for this in the control structure so that card drivers
can hint to us to use DTV78 firmware from the first tuning attempt.
Signed-off-by: Chris Pascoe <c.pascoe@itee.uq.edu.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
We have been inserting a mystery 500kHz offset for tuning 7MHz channels,
however some experimentation reveals it is only needed under certain
conditions with specific firmware combinations. Document these and only
apply the offset when we know it is required.
Signed-off-by: Chris Pascoe <c.pascoe@itee.uq.edu.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
When searching for the right S-Code table to load, check the HAS_IF flag
against the firmware we are checking instead of against the the "type"
requested. We already ignore the scode type requested if the caller passed
an int_freq; this makes the search by frequency consistent with that behaviour.
Signed-off-by: Chris Pascoe <c.pascoe@itee.uq.edu.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Don't modify the control structure that was provided at attach when applying
an offset to the S-Code, otherwise it will be incorrect on subsequent tunes.
Signed-off-by: Chris Pascoe <c.pascoe@itee.uq.edu.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Add "int_freq" to the debugging output when selecting firmware and the
HAS_IF flag when dumping firmware during load.
Signed-off-by: Chris Pascoe <c.pascoe@itee.uq.edu.au>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The patch below adds the "Pinnacle Dazzle DVC 100" to the list of
cards supported by the em28xx driver. As the configuration is the same
as the DVC 90 one, it simply adds a new USB ID to the list of devices
supported by the DVC 90 configuration.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>