Currently there are two different implementations (in the firmware) for
the QAM demodulator command: one takes 4 and the other takes 2
parameters. The driver shows an error in dmesg When using the
4-parameter command with firmware that implements the 2-parameter
command. Unfortunately this happens every time when chaning the
frequency (on DVB-C).

This patch simply makes configurable, how many command parameters will
be used. All existing drxk_config instances using the "drxk_a3.mc" were
updated because this firmware is the only loadable firmware where the
QAM demodulator command takes 4 parameters. Some firmwares in the ROM
might also use it. The drxk instances in the em28xx-dvb driver were also
updated to silence the warnings.

If no qam_demod_parameter_count is given in the drxk_config struct, then
the correct number of parameters will be auto-detected.

[mchehab@redhat.com: Fix a small CodingStyle issue at one comment]
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Drivers that refer to a __devexit function in an operations
structure need to annotate that pointer with __devexit_p so
replace it with a NULL pointer when the section gets discarded.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The output of "make versioncheck" told us that the file
drivers/media/dvb/ddbridge/ddbridge-code.c has a incorrect include of
version.h:

linux/drivers/media/dvb/ddbridge/ddbridge-core.c: 34 linux/version.h not
needed.

After take a look in the code, we can agree to remove it.

Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: <linux-media@vger.kernel.org>
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Move the ngene/ddbridge firmware into their drivers.

There are two reasons for that:
	1) The firmware used there didn't work for a few devices
I tested here (Terratec H5, H6 and H7);
	2) At least Terratec H7 doesn't seem to require a firmware
for it to work.

After this change, if firmware is not specified, the driver will
use a rom-based firmware (this seems to be the case for Terratec
H7, although I need to better check the USB dumps to be sure about
that).

In any case, the firmware seems to be optional, as the DRX-K driver
don't return the firmware load error.
Signed-off-by: NMauro 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: NMauro Carvalho Chehab <mchehab@redhat.com>

both callers of device_get_devnode() are only interested in lower 16bits
and nobody tries to return anything wider than 16bit anyway.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

'off' was unused and 'ret' really had to be used to return -EFAULT.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There were a several problems in this function:

1) Potential integer overflow in the comparison:
	if (fio.write_len + fio.read_len > 1028) {

2) If the user gave bogus values for write_len and read_len then
   returning -EINVAL is more appropriate than returning -ENOMEM.

3) wbuf was set to the address of an array and could never be NULL
   so I removed the pointless NULL check.

4) The call to vfree(wbuf) was improper.  That array is part of a
   larger struct and isn't allocated by itself.

5) flashio() can't actually fail, but we may as well add error
   handling in case this changes later.

6) In the default case where an ioctl is not implemented then
   returning -ENOTTY is more appropriate than returning -EFAULT.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently, the only parameter to be configured is the I2C
address. However, Terratec H5 logs shows that it needs a different
setting for some things, and it has its own firmware.

So, move the addr into a config structure, in order to allow adding
the required configuration bits.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

WARNING: Use #include <linux/io.h> instead of <asm/io.h>
+#include <asm/io.h>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/dvb/ddbridge/built-in.o: In function `my_dvb_dmx_ts_card_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/ddbridge/ddbridge-core.c:718: multiple definition of `my_dvb_dmx_ts_card_init'
drivers/media/dvb/ngene/built-in.o:/home/v4l/v4l/patchwork/drivers/media/dvb/ngene/ngene-dvb.c:227: first defined here
drivers/media/dvb/ddbridge/built-in.o: In function `my_dvb_dmxdev_ts_card_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/ddbridge/ddbridge-core.c:737: multiple definition of `my_dvb_dmxdev_ts_card_init'
drivers/media/dvb/ngene/built-in.o:/home/v4l/v4l/patchwork/drivers/media/dvb/ngene/ngene-dvb.c:246: first defined here
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Codingstyle fixes
Signed-off-by: NOliver Endriss <o.endriss@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Driver support for Digital Devices ddbridge-based cards:
Octopus, Octopus mini, Octopus LE, cineS2(v6)
with DuoFlex S2 and/or DuoFlex CT tuners.

Driver was taken from ddbridge-0.6.1.tar.bz2.
Signed-off-by: NRalph Metzler <rmetzler@digitaldevices.de>
Signed-off-by: NOliver Endriss <o.endriss@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>