The changeset 240ab508aa is incomplete, as the first thing that
happens at cache clear is to do a memset with 0 to the cache.
So, the delivery system needs to be explicitly preserved there.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by Lawrence[1], MythTV 0.24.1 does the wrong thing
with a DVBv5 call: it fills the delivery system with
SYS_UNDEFINED, expecting that the DVB core would work with that.
This used to work by accident, as the DVB core were missing the
check for the supported delivery systems. Yet, fixing it
is easy, so let's add a logic to handle this case, to
provide backward compatibility.
[1] http://patchwork.linuxtv.org/patch/8314/
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I added it by mistake. It is useless as no real hardware.
It even uses even Cypress FX2, general USB bridge chip, default IDs
that makes driver load all FX2 devices having default ID...
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some time ago, Manoel sent us a patch adding more stuff
to the init sequence. However, his patch were also doing
non-related stuff, by changing the init logic without
any good reason. So, it was asked for him to submit a
patch with just the data that has changed, in order to
allow us to better analyze it.
As he didn't what it was requested, I finally found some
time to dig into his init sequence and add it here.
Basically, new stuff is added there. There are a few changes:
1) The removal of the extra (duplicated) logic that puts
the chip into the serial mode;
2) Some Viterbi VBER measurement init data was changed from
0x00 to 0xff for layer A, to match what was done for
layers B and C.
None of those caused any regressions and both make sense
on my eyes.
The other parameters additions actually increased the
tuning quality for some channels. Yet, some channels that
were previously discovered with scan disappered, while
others appeared instead. This were tested in Brasilia,
with an external antena.
At the overall, it is now a little better. So, better to
add these, and then try to figure out a configuration that
would get even better scanning results.
Reported-by: Manoel Pinheiro <pinusdtv@hotmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On mb86a20s, some registers have sub-addresses, while others not.
In order to make easier to compare different settings, group them.
No functional changes in this patch.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As a DVBv3 application may be relying on the delivery system,
don't reset it at DTV_CLEAR. For DVBv5 applications, the
delivery system should be set anyway.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix some issues pointed out by Mauro.
Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Allow use of that general callback for demod too.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The af9005_properties and af9015_properties tables make use of USB ids
from the USB id tables with hardcoded indices, as in
"&af9015_usb_table[30]". Adding new entries before the end breaks
such references, so everyone has had to carefully tiptoe to only add
entries at the end of the list.
In the spirit of "dw2102: use symbolic names for dw2102_table
indices", use C99-style initializers with symbolic names for each
index to avoid this. In the new regime, properties tables referring
to the USB ids have names like "&af9015_usb_table[CINERGY_T_STICK_RC]"
that do not change meaning when items in the USB id table are
reordered.
Encouraged-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Luca Olivetti <luca@ventoso.org>
Acked-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by Toralf:
the build failed with :
CC [M] drivers/media/dvb/dvb-core/dvb_ca_en50221.o
In file included from arch/x86/include/asm/uaccess.h:573:0,
from include/linux/poll.h:14,
from drivers/media/dvb/dvb-core/dvbdev.h:27,
from drivers/media/dvb/dvb-core/dvb_ca_en50221.h:27,
from drivers/media/dvb/dvb-core/dvb_ca_en50221.c:41:
In function "copy_from_user", inlined from "dvb_ca_en50221_io_write" at drivers/media/dvb/dvb-core/dvb_ca_en50221.c:1314:26: arch/x86/include/asm/uaccess_32.h:211:26: error: call to "copy_from_user_overflow" declared with attribute error: copy_from_user() buffer size is not provably correct
Reported-by: Toralf Foerster <toralf.foerster@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The patch "dm1105: handle errors from dvb_net_init" moved the
initialization of dvbnet to before frontend attachment but forgot
to adjust the error handling when frontend attachment fails.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This module does some printks with the loglevel missing.
pr_err() takes care of adding the KERN_ERR tag and the module name.
So we can simplify the code and add the missing printk loglevel by
using it.
Also add a #define pr_fmt() to make this work, and remove a few
unnecessary periods at the end of messages and bump the loglevel of
"Unknown bttv card type" from KERN_WARNING to KERN_ERR while at it.
Inspired-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This way, the messages will be tagged with KERN_DEBUG and not clutter
the log from dmesg unless the "debug" module parameter is set.
[mchehab@redhat.com: whitespace fixes]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This code is wrong as I should have coded it as SYS_DVBC, instead of
SYS_DVBS & friends. Anyway, this check has other problems
1) it does some "magic" by assuming that all QAM modulations are below
QAM_AUTO;
2) it checks modulation parameters only for one delivery system.
Or the core should check invalid parameters for all delivery
systems, or it should let the frontend drivers do it;
3) frontend drivers should already be checking for invalid parameters
(most of them do it, anyway);
4) not all modulations are mapped at fe->ops.info.caps, so it is not
even possible to check for the valid modulations inside the core
for some delivery systems;
5) The core check is incomplete anyway: it only checks for a few
parameters. If moved into the core other parameters like bandwidth
and fec should also be checked;
6) 2nd gen DVB-C uses OFDM. So, that test would fail for it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by Oliver, some old dead code were preserved there.
Thanks-to: Oliver endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is just a cleanup, it doesn't change how the code works. These
are compound conditions and not bitwise operations so it should be &&
and not &.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On Thu, 2011-12-15 at 16:42 +0000, Malcolm Priestley wrote:
> > [ 1103.536156] it913x: Chip Version=ec Chip Type=5830
> > [ 1104.336178] it913x: Dual mode=92 Remote=92 Tuner Type=92
> > [ 1106.248116] dvb-usb: found a 'ITE 9135(9006) Generic' in cold state,
> > will try to load a firmware
> > [ 1106.253773] dvb-usb: downloading firmware from file
> > 'dvb-usb-it9135-02.fw'
> > [ 1106.452123] it913x: FRM Starting Firmware Download
> > [ 1130.756039] it913x: FRM Firmware Download Failed (ffffff92)
> > [ 1130.956168] it913x: Chip Version=79 Chip Type=5823
> > [ 1131.592192] it913x: DEV it913x Error
> > [ 1131.592271] usbcore: registered new interface driver it913x
> >
> > No frontend is generated anyway.
>
> Looks like the the firmware is not at all compatible with your device.
>
> Have you applied the patch cleanly to the latest media_build?
>
> These appear to be new version of the 9006. A supplier is sending me one
> of these devices.
>
> As a last resort see if the device works with dvb-usb-it9137-01.fw
>
> You will have force to use this firmware
> dvb-usb-it913x firmware=1
Here is a modified firmware loader for version 2 types.
The firmware must be as in original
./dvb_get_firmware it9135
dd if=dvb-usb-it9135.fw ibs=1 skip=12866 count=5817 of=dvb-usb-it9135-02.fw
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes an obvious typo in the get_frontend() function
of the af9013 driver, recently rewritten by Antti Palosaari.
Signed-off-by: Gianluca Gennari <gennarone@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Correction to tuner ID 0x51.
Don't force tuner ID 0x60 unless eprom data zero.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some channels appear weak signal after warm boot.
Because tuner id is not present in eprom 0x38 is
assigned.
9006 devices are now always assigned 0x60.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixes issues with PID filter
Stalling of some channels when PID is on.
PID filter not turning off fully.
PID filter can now turn on and off each index.
Removed PID_RST from it913x_pid_filter_ctrl.
Replaced with PID_EN removed from it913x_pid_filter
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is not common for dvb_net_init to fail, but after the patch
"dvb_net_init: return -errno on error" it can fail due to running out
of memory. Handle this.
From an audit of dvb_net_init callers.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
From an audit of dvb_net_init callers, now that that function
returns -errno on error.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Clean up and error out if dvb_net_init fails (for example due to
ENOMEM). This involves moving the dvb_net_init call to before
frontend_init to make cleaning up a little easier.
From an audit of dvb_net_init callers, now that dvb_net_init lets
callers know about errors.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Clean up and error out if dvb_net_init fails (for example when
running out of memory).
From an audit of dvb_net_init callers, now that dvb_net_init
has learned to return a nonzero value from time to time.
[mchehab.redhat.com: codingstyle fix: printk() should include KERN_ facility level]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Bail out if dvb_net_init encounters an error (for example an
out-of-memory condition), now that it reports them.
[mchehab@redhat.com: CodingStyle fix: don't use "if ((ret = foo()) < 0)"]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Avoid some repetition by adopting the usual "goto err" idiom for error
handling.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Repeating the same cleanup code in each error handling path makes life
unnecessarily difficult for reviewers, who much check each instance of
the same copy+pasted code separately. A "goto" to the end of the
function is more maintainable and conveys the intent more clearly.
While we're touching this code, also lift some assignments from "if"
conditionals for simplicity.
No functional change intended.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
dvb_net_init unconditionally returns 0. Callers such as
videobuf_dvb_register_frontend examine dvbnet->dvbdev instead of the
return value to tell whether the operation succeeded. If it has been
set to a valid pointer, success; if it was left equal to NULL,
failure.
Alas, there is an edge case where that logic does not work as well:
when network support has been compiled out (CONFIG_DVB_NET=n), we want
dvb_net_init and related operations to behave as no-ops and always
succeed, but there is no appropriate value to which to set dvb->dvbdev
to indicate this.
Let dvb_net_init return a meaningful error code, as preparation for
adapting callers to look at that instead.
The only immediate impact of this patch should be to make the few
callers that already check for an error code from dvb_net_init behave
a little more sensibly when it fails.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Turn the pid filter off by caps option only.
This is so the full stream is passed to demuxer and not limited
by pid count.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Turn the pid filter off by caps option only.
This is so the full stream is passed to demuxer and not limited
by pid count.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
dw2102_properties et al refer to entries in the USB-id table using
hard-coded indices, as in "&dw2102_table[6]", which means adding new
entries before the end of the list has the potential to introduce bugs
in code elsewhere in the file.
Use C99-style initializers with symbolic names for each index to avoid
this. This way, other device tables wanting to reuse the USB ids can
use expressions like "&dw2102_table[TEVII_S630]" that do not change as
the entries in the table are reordered.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Support for IT1935 9006 devices.
9006 have version 2 type chip.
9006 devices should use dvb-usb-it9135-02.fw firmware.
On the device tested the tuner id was set to 0 which meant
the driver used tuner id 0x38. The device functioned normally.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of creating two DVB frontend entries for the same device,
create just one entry, and fill the delivery_system according with
the supported standards.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
ops.info.frequency_stepsize is used only for DVB-T & friends. For
DVB-C, the step size is calculated using the symbol rate.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While this patch change some things, the updated fields there are
used just on printk, so it shouldn't cause any functional changes.
Yet, this routine is a little complex, so explain a little more
how it works.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of changing the ops.info.type struct, updates only
the data that will be returned to userspace.
Also add some debug messages to help tracking such issues.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now, ops->info.type is handled inside the dvb_frontend
core, only for DVBv3 calls, and according with the
delivery system. So, drivers should not care or use it,
otherwise, it may have issues with DVBv5 calls.
The drivers that were still using it were detected via
this small temporary hack:
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -29,13 +29,16 @@
#include <linux/types.h>
typedef enum fe_type {
+#if defined(__DVB_CORE__) || !defined (__KERNEL__)
FE_QPSK,
FE_QAM,
FE_OFDM,
FE_ATSC
+#else
+FE_FOOO
+#endif
} fe_type_t;
-
typedef enum fe_caps {
FE_IS_STUPID = 0,
FE_CAN_INVERSION_AUTO = 0x1,
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While the driver has support for both serial and parallel mode,
There's was way to select serial mode via configuration. Add
a config option for that, while keeping the default in serial mode.
Also, at debug mode, it will now print a message when mpeg is
enabled/disabled, and showing if parallel or serial mode were
selected, helping developers to double-check if the DRX-K is at
the right mode.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
