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>
Make Checkpatch tool happy:
-:2349: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
On all cases, it were just a blank line at the wrong place. Yet, fixing it is trivial
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The ir-keymaps.c has frequent additions. As people tend to copy an old
keyboard entry, a bad CodingStyle at an ancient entry may result on a
freshly bad CodingStyle patch.
So, better to fix the CodingStyle for the entire file.
This patch is the first of a series of patches fixing it, generated by
some perl magic plus manual handling.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for the remote control that comes with the Cinergy Hybrid T USB XS
Thanks to Jelle de Jong for providing sample hardware to test with.
Cc: Jelle de Jong <jelledejong@powercraft.nl>
Signed-off-by: Devin Heitmueller <dheitmueller@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
A user discovered that the Geniatech x8000 encountered a regression when
the xc3028 power management was introduced. The xc3028 never recovers after
setting the powerdown register, which is probably because the xc3028 reset
GPIO is not properly configured. Since I do not have access to the hardware
and thus cannot determine the correct GPIO configuration, just disable xc3028
power management on this board, which fixes the regression.
Thanks to user "ritec" for reporting the issue and testing the fix.
Cc: rictec <rictec@netcabo.pt>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixes stack corruption bug present in dump_regs function of zl10353 and
qt1010 drivers: the buffer buf was one byte smaller than required -
there are 4 chars for address prefix, 16 * 3 chars for dump of 16 eeprom
bytes per line and 1 byte for zero ending the string required, i.e. 53
bytes, but only 52 were provided.
The one byte missing in stack based buffer buf can cause stack
corruption possibly leading to kernel oops, as discovered originally
with af9015 driver (af9015: fix stack corruption bug).
Signed-off-by: Jan Nikitenko <jan.nikitenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following patch should fix 7 MHz DVB-T with the XC3028 using the
DTV7 firmware from the xc3028-v27.fw firmware image.
Tested-by: Terry Wu <terrywu2009@gmail.com>
[mchehab@redhat.com: thanks to John Ferlito, we have a real test in Australia]
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add an IR profile for the EVGA inDtube remote control (which is an NEC type
remote)
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Change order data of buffer in FM simple_tune function. It is usefull for:
1. Set data of tuner with CP bit UP. 0xCE for MK5 or 0xC6 for MK3
2. When call simple_fm_tune, read this byte from config and overwrite
this byte in function simple_radio_bandswitch for set CP bit to OFF.
Of course it can be usefull for other tuner for overwrite default
settings of FM.
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Both ATSC and DVB @ 6MHz bandwidth require the same offset.
While we're fixing it, let's cleanup the bandwidth setup to better
reflect the fact that it is a function of the bandwidth.
Thanks to Terry Wu <terrywu2009@gmail.com> for pointing this issue and
to Andy Walls <awalls@radix.net> for an initial patch for this fix.
Cc: Terry Wu <terrywu2009@gmail.com>
Acked-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The only two countries that are known to use 6MHz bandwidth are Taiwan
and Uruguay. Both use QAM subcarriers at OFTM.
This patch fixes the firmware load for such countries, where the
required firmware is the QAM one.
This also confirms the previous tests where it was noticed that the 6MHz
QAM firmware doesn't work for cable. So, this patch also removes support
for DVB-C, instead of just printing a warning.
Thanks to Terry Wu <terrywu2009@gmail.com> for pointing this issue and
to Andy Walls <awalls@radix.net> for an initial patch for this fix.
Cc: Terry Wu <terrywu2009@gmail.com>
Acked-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of polling at 100ms intervals for register writes, poll at 5ms
intervals. This is consistent with the xc5000 specification, and improves
tuning time by up to 500 ms on devices that such as the au0828 which do not
properly implement i2c clock stretching (since the five register writes that
occur for a tuning request often do not complete immediately but do complete
far before 100ms has gone by).
The net amount of time we wait before timing out is unchanged (500ms).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds XC5000 supports for DVB-T 6MHz and 8MHz bandwidth.
Signed-off-by: David T.L. Wong <davidtlwong@gmail.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Xceive has graciously allowed us to now freely redistribute the xc5000
firmware, which eliminates the need for users to manually extract the blob
from the Hauppauge driver.
Thanks to Brian Mathews <bmathews@xceive.com> for providing this code
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There was a typo in the module description for the "no_poweroff" option, where the
help was being associated with the "debug" option instead.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Alan Cox