Adds support for Maxim MAX2165 silicon tuner.
It is tested on Mygica X8558Pro, which has MAX2165, ATBM8830 and CX23885
Signed-off-by: David T. L. Wong <davidtlwong@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The HVR-1600 doesn't use the standard mechanism for computing the gain when
in QAM mode, instead always forcing it to be 0x02. Provide the ability to
override the algorithm on a per-board basis.
This change results in an improvement of 0.4-0.6 dB for QAM tuning.
This work was sponsored by ONELAN Limited.
Cc: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the changeset entitled, "tda18271: add support for the set_config method",
the initialization order was changed such that the standard map overrides
were being applied before loading the default standard map, based on the
stepping of the silicon. This changeset restores the proper order by
processing the standard map overrides both within the tda18271_set_config()
and the tda18271_attach() functions, after we read the id register of the
tuner.
Thanks to Michael Obst for his testing, helping me to identify the regression.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Michael Obst <mike.obst@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The variables are unsigned so the test `>= 0' is always true,
the `< 0' test always fails. In these cases the other part of
the test catches wrapped values.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In buffer_release() the previously allocated pagetables are not
freed, which might result in a memory leak in certain application
use-cases, where the frame format is changed from planar format to
non-planar format. The fix explicitely frees the page tables when a
format change is done and when buffer_release() is called.
Signed-off-by: Johann Friedrichs <johann.friedrichs@web.de>
Signed-off-by: Michael Hunold <hunold@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
consolidate common code used to determine if calibration on startup is needed
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If rf_cal_on_startup is enabled in the structure passed into
tda18271_attach, and the cal module option isn't disabled, then we
should run the initialization and calibration procedures during the
tda18271_attach function call, regardless of how many instances of the
driver have been attached. If the device is already calibrated, the
driver will detect that and will only calibrate again if necessary.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If rf_cal_on_startup is enabled in the structure passed into
tda18271_set_config, and the cal module option isn't disabled,
then we should run the initialization and calibration procedures
during the tda18271_set_config function call.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add the set_config method to allow drivers to configure the
tda18271 driver options after attach.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is already an option for sending 16 byte chunks rather that writing
39 bytes all at once during the tuner's initialization. Some i2c buses
can't send 16 bytes at once, so create an option for sending 8 byte chunks.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Xc5000 tuning attempts shouldn't return zero in the case where the firmware
did not load successfully.
Thanks to Michael Krufky for pointing out this issue.
Cc: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The patch brings infrared remote support for some cx88 based cards.
Such as TeVii S460,S420.
Signed-off-by: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The patch brings infrared remote support for some cx88 based cards.
Such as:
TeVii S460,S420; Omicom SS4; SatTrade ST4200;
TBS 8920,8910; Prof 7300,6200.
Signed-off-by: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert tda18271_rf_tracking_filter_cal.rf_[ab][12] from int to s32.
Convert tda18271_priv.tm_rfcal from unsigned int to u8.
Cast subtractions between u32 values as s32.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use temporary variables for signed calulations between unsigned values
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This adds a forgotten module_param macro needed to set a deemphasis of 50us.
It is the standard setting for commercial FM radio broadcasts outside the US.
Signed-off-by: Henk Vergonet <Henk.Vergonet@gmail.com>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove hard-coded definition of the xc5000 FM radio input, making it a
parameter passed in when doing the attach call.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Edwin Török found the following:
In function ‘memset’,
inlined from ‘ir_input_init’ at drivers/media/common/ir-functions.c:67:
/home/edwin/builds/linux-2.6/arch/x86/include/asm/string_64.h:61:
warning: call to ‘__warn_memset_zero_len’ declared with attribute
warning: memset used with constant zero length parameter; this could be
due to transposed parameters
memset(ir->ir_codes, sizeof(ir->ir_codes), 0);
In actual practice the only caller I can find happens to already have cleared
the buffer before calling ir_input_init.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While having tda18271 module set with debug=17 (cal & info prints) and
cal=0 (delay calibration process until first use) - I discovered that
during the calibration process, if the frequency test for 69750000
returned a bcal of 0 (see tda18721-fe.c in tda18271_powerscan func) that
the tuner wouldn't be able to pickup any of the frequencies in the range
(all the other frequencies bands returned bcal=1). I spent some time
going over the code and the NXP's tda18271 spec (ver.4 of it i think) and
adding a lot of debug prints and walking/stepping through the calibration
process. I found that when the powerscan fails to find a frequency, the
rf calibration is not run and the default value is supposed to be used in
its place (pulled from the RF_CAL_map table) - but something was getting
goofed up there.
Now, my c coding skills are very rusty, but i think root of the problem is
a signedness issue with the math operation for calculating the rf_a1 and
rf_a2 values in tda18271_rf_tracking_filters_init func, which results in
values like 20648 for rf_a1 (when it should probably have a value like 0,
or so slightly negative that it should be zero - this bad value for rf_a1
would in turn makes the approx calc within
tda18271c2_rf_tracking_filters_correction go out of whack). The simplest
solution i found was to explicitly convert the signedness of the
denominator to avoid the implicit conversion. The values placed into the
u32 rf_freq array should never exceed about 900mhz, so i think the s32 max
value shouldn't be an issue in this case.
I've tested it out a little, and even when i get a bcal=0 with the
modified code, the default calibration value gets used, rf_a1 is zero, and
the tuner seems to lock on the stream and mythtv seems to play it fine.
Signed-off-by: Seth Barry <seth@cyberseth.com>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Multiplication by 62500 causes an overflow in the 32 bit freq variable,
which is later divided by 1000 when using FM radio.
This patch prevents the overflow by scaling the frequency value correctly
upfront. Thanks to Henk Vergonet for spotting the problem and providing
a preliminary patch, which this changeset was based upon.
Cc: Henk Vergonet <Henk.Vergonet@gmail.com>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
CC: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for NXP TDA18271 as a standalone tuner, allowing the use of
analog demodulators other than the Philips/NXP TDA829x.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixed one value and removed a duplicate in tda18271_cid_target[],
based on table 54 "CID_Target_map" in Rev.04 of the TDA18271HD datasheet.
Signed-off-by: Henk Vergonet <Henk.Vergonet@gmail.com>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Update the tda18271c2_rf_tracking_filters_correction function to include
the modified temperature compensation calculatation formula as described
in Rev.04 of the TDA18271HD datasheet.
Signed-off-by: Henk Vergonet <Henk.Vergonet@gmail.com>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Don't display "no agc configuration provided" unless DBG_ADV is set.
Fix comments in function, tda18271_agc. This config variable is not
for LNA configuration -- it is for external AGC configuration.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Display function parameters, idx and len, in error log.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
For the case of multiple tuner instances, ensure that non-default
configuration options are saved into the driver's state.
This resolves an issue where a configuration option may not be
carried into the driver if the analog side of a hybrid driver
initializes before the digital side.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
minor cleanup: move small_i2c assignment to the state config block
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
For better readability, treat the low power standby mode configuration
as an output option feature configuration, and change it to a bitmask.
If left unconfigured, all features will remain enabled, just as the
default configuration was before these changes were introduced.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
By default, the driver enters standby mode with slave tuner output
loop thru enabled and xtal oscillator on.
Not all designs require that slave tuner output loop thru and
xtal oscillator remain active while in standby mode, so two
additional standby modes have been added:
- standby mode with xtal oscillator on (loop thru off)
- total power off
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently, V4L uses a scancode table whose index is the scancode and
the value is the keycode. While this works, it has some drawbacks:
1) It requires that the scancode to be at the range 00-7f;
2) keycodes should be masked on 7 bits in order for it to work;
3) due to the 7 bits approach, sometimes it is not possible to replace
the default keyboard to another one with a different encoding rule;
4) it is different than what is done with dvb-usb approach;
5) it requires a typedef for it to work. This is not a recommended
Linux CodingStyle.
This patch is part of a larger series of IR changes. It basically
replaces the IR_KEYTAB_TYPE tables by a structured table:
struct ir_scancode {
u16 scancode;
u32 keycode;
};
This is very close to what dvb does. So, a further integration with DVB
code will be easy.
While we've changed the tables, for now, the IR keycode handling is still
based on the old approach.
The only notable effect is the redution of about 35% of the ir-common
module size:
text data bss dec hex filename
6721 29208 4 35933 8c5d old/ir-common.ko
5756 18040 4 23800 5cf8 new/ir-common.ko
In thesis, we could be using above u8 for scancode, reducing even more the size
of the module, but defining it as u16 is more convenient, since, on dvb, each
scancode has up to 16 bits, and we currently have a few troubles with rc5, as their
scancodes are defined with more than 8 bits.
This patch itself shouldn't be doing any functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[mchehab@redhat.com: Fix a few wrong IR keymaps]
Signed-off-by: Shine Liu <shinel@foxmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On certain master / slave dual tuner configurations, tuning performance
improves when the RF tracking filter calibration is performed sequentially.
This patch allows for the bridge driver to specify this behavior in the
configuration structure at attach-time.
The "cal" module option will continue to override this attach-time
configuration: set cal=0 to prevent RF tracking filter calibration
on startup, and set cal=1 to force it.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Reviewed-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
remove excess spacing from the tda_foo printk macros & line things up better
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rename dprintk to tda_dprintk to be consistent with the other tda_foo macros.
Move KERN_DEBUG facility level to tda_dprintk.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
KEY_CAMERA is already used for a long time with webcam drivers to take a picture.
On other media drivers, due to the lack of a snapshot button, random KEY codes
were sent, being KEY_SHUFFLE the most used one, probably due to cut-and-paste
from other remotes, since one of them uses the same key for snapshot and shuffle.
The better is to use KEY_CAMERA on all drivers solving this issue. This
follows the IR standard map as defined at:
http://linuxtv.org/wiki/index.php/Remote_Controllers
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use standard definitions for channel controls, as defined at:
http://linuxtv.org/wiki/index.php/Remote_Controllers
While here, fix a few broken up/down/left/right mappings
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Each remote were using a different keycode for timeshift. Use the same
keycode for all of them, using the map as defined at:
http://linuxtv.org/wiki/index.php/Remote_Controllers
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are several IR's that were using IR to type a letter that it is
known by some random application. Instead, the better is to use
the standard definitions found at:
http://linuxtv.org/wiki/index.php/Remote_Controllers
And, if needed, submit a patch for the application to understand the
media keys.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While we're still discussing it, let's point to the wiki page. In
the future, this should be added at V4L2 API spec DocBooks.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>