Currently, the driver assumes that all QAM carriers are spaced with
8MHz. This is wrong, and may decrease QoS on Countries like Brazil,
that have DVB-C carriers with 6MHz-spaced.

Fortunately, both ITU-T J-83 and EN 300 429 specifies a way to
associate the symbol rate with the bandwidth needed for it.

For ITU-T J-83 2007 annex A, the maximum symbol rate for 6 MHz is:
	6 MHz / 1.15 = 5217391 Bauds
For  ITU-T J-83 2007 annex C, the maximum symbol rate for 6 MHz is:
	6 MHz / 1.13 = 5309735 Bauds.

As this tuner is currently used only for DRX-K, and it is currently
hard-coded to annex A, I've opted to use the roll-off factor of 0.15,
instead of 0.13.

If we ever support annex C, the better would be to add a DVB S2API
call to allow changing between Annex A and C, and add the 0.13 roll-off
factor to it.

This code is currently being used on other frontends, so I think we
should later add a core function with this code, to warrant that
it will be properly implemented everywhere.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The signal state field in G_TUNER is typically scaled from 0-100%.  Since we
don't know the signal level, we really would prefer the field to contain 100%
than 1/256, which in many utilities (such as v4l2-ctl) rounds to 0% even when
a signal is actually present.

This patch makes the behavior consistent with other drivers.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix the DRX-K logic that selects between DVB-C annex A and C

Fix a typo where DVB-C annex type is set via setEnvParameters, but
the driver, uses, instead, setParamParameters[2].

While here, cleans up the code, fixing a bad identation at the fallback
code for other types of firmware, and put the multiple-line comments
into the Linux CodingStyle.
Acked-by: NOliver Endriss <o.endriss@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

After return, we don't need any other statement to change the
function flux ;)
Reported-by: NOliver Endriss <o.endriss@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The error propagation changeset c23bf4402 broke the DVB-T
code.

The legacy way for propagate errors was:

do {
	status = foo_func()
	if (status < 0)
		break;
} while (0);
return status;

However, on a few places, it was doing:
do {
	switch(foo) {
	case bar:
		status = foo_func()
		if (status < 0)
			break;
		break;
	}
	switch(foo2) {
	case bar:
		status = foo_func()
		if (status < 0)
			break;
		break;
	}
	...
} while (0);
return (status)

The inner error break were not working, as it were breaking only
the switch, instead of the do. The solution used were to do a
s/break/goto error/ at the inner breaks, but preserving the last
break. Onfortunately, on a few switches, the replacement were
applied also to the final break for the case statements.

Fix the broken logic, by reverting them to break, where pertinent,
in order to fix DVB-T support.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Both ngene and ddbrige calls dvb_attach once for drxk_attach.
The logic used there, and by tda18271c2dd driver is different
from similar logic on other frontends.

The right fix is to change them to use the same logic, but,
while we don't do that, we need to patch em28xx-dvb in order
to do cope with ngene/ddbridge magic.

While here, document why drxk_t_release should do nothing.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This reverts commit a3e4adf274f86b2363fedaa964297cb38526cef0.

As pointed by Andread Oberritter <obi@linuxtv.org>:

	That's wrong, because the array size is DTV_MAX_COMMAND + 1.
	Using the ARRAY_SIZE macro instead might reduce the confusion.

Also, changeset 3995223038 already fixed this issue.
Reported-by: NAndread Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NEmilio David Diaus Lopez <reality_es@yahoo.es>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It is useless. There is only one physical I2C-adapter.

2nd adapter was added originally due to some plans for allowing only one
demod to access bus at time. But I never implemented proper locking...
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remove old code which is not used anymore since IR code is read
directly from memory nowadays.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Return EOPNOTSUPP for too long messages.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Reported-by: NJacek M. Holeczek <jacek.m.holeczek@gmail.com>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

That's this tuner:

The credit card sized remote more or less works if I set remote=4,
so I added the hash to get it autodetected.  (`more or less' there
meaning sometimes buttons are `stuck on repeat', i.e. ir-keytable -t
keeps repeating the same scancode until i press another button.)
Signed-off-by: NJuergen Lock <nox@jelal.kn-bremen.de>
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In drivers/media/dvb/frontends/drxd_hard.c::load_firmware() I see 3
small issues:

 1) When the 'fw' variable goes out of scope we'll leak the memory
 allocated to it by request_firmware() by neglecting to call
 release_firmware().

 2) After a successful request_firmware() we allocate fw->size bytes
 of memory using kzalloc() only to immediately overwrite all that
 memory with memcpy(), so asking for zeroed memory seems like wasted
 effort - just use kmalloc().

 3) In one of the error messages "no memory" lacks a space and is
 written as "nomemory".

This patch fixes all 3 issues.
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If the tvp->cmd == DTV_MAX_COMMAND then we read past the end of the
array.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Should be folded with the next patch when sending upstream
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If those demods are unselected, but a bridge driver requires them,
produce a runtime message, instead of missing symbols.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The QAM standard is set using this scu_command:
	SCU_RAM_COMMAND_STANDARD_QAM |
	SCU_RAM_COMMAND_CMD_DEMOD_SET_PARAM

The driver implements a version that has 4 parameters, however,
Terratec H5 needs to break this into two separate commands, otherwise,
DVB-C doesn't work.

With this fix, scan is now properly working and getting the
channel list:
>>> tune to: 609000000:INVERSION_AUTO:5217000:FEC_3_4:QAM_256
>>> tuning status == 0x00
>>> tuning status == 0x07
>>> tuning status == 0x1f

0x0093 0x0026: pmt_pid 0x0758 (null) -- SporTV2 (running, scrambled)
0x0093 0x0027: pmt_pid 0x0748 (null) -- SporTV (running, scrambled)
0x0093 0x0036: pmt_pid 0x0768 (null) -- FX (running, scrambled)
0x0093 0x0052: pmt_pid 0x0788 (null) -- The History Channel (running, scrambled)
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Now, it outputs:

[10927.639641] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:
[10927.646283] drxk: 02 00 00 00 10 00 07 00 03 02                    ..........

Better than ERROR -3. This happens with Terratec H5 firmware.

It adds 2 new error conditions, and something useful to track
what the heck is that.

I suspect that the scu_command is dependent on the firmware
revision.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The driver is too limited: it assumes that UIO is used only for
controlling the antenna, and that only UIO-1 is in usage. However,
from Terratec H7 driver [1], 3 UIO's can be used. In fact, it seems
that H7 needs to use all 3. So, make the code generic enough to handle
the most complex scenario. For now, only antena GPIO can be specified,
but is is easier now to add the other GPIO/UIO needs.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

DRX-K configuration is interesting when writing/testing
new devices. Add an info line showing the discovered info.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Terratec H5 doesn't require to switch mode, but generates
an error due to this logic. Also, GPIO's are board-dependent.

So, add it at the board config struct.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The set mode routines assume that state were changed to the
new mode, otherwise, they'll fail.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This driver is very big and complex. An error happening in the middle
of any initialization may cause the frontend to not work. So, it
needs to properly propagate error codes internally and to userspace.

Also, printing the error codes at the places it happened helps to
discover were's a bug at the code.

Before this change, a do { } while (0) loop and lots of breaks inside
were used to propagate errors. While this works, if there are
loops inside other loops, it could be easy to forget to add another
break, causing the error to not abort the function.

Also, as not all functions were reporting errors, it is hard to
discover why something failed.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

On em28xx, tda18271C2 is accessible when the i2c port
is not touched. Touching on it breaks the driver.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The microcode firmware provided on Terratec H5 seems to be
different. Add a parameter to allow specifying a different
firmware per-device.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If something bad happens during firmware load, an error
should be printed at dmesg.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Don't read paste the buffer, if the firmware is corrupted.
Instead, print an error message.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of using #ifdef I2C_LONG_ADR for some devices, convert
it into a parameter. Terratec H5 logs from the original driver
seems to need this mode.
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>

The normal 16-bits read routine is called as "Read16_0". This is
due to a flags that could optionally be passed. Yet, on no places
at the code, a flag is passed there.

The same happens with 16-bits write and 32-read/write routines,
and with WriteBlock.

Also, using flags, is an exception: there's no place currently using
flags, except for an #ifdef at WriteBlock.

Rename the function as just "read16", and the one that requires flags,
as "read16_flags".

This helps to see where the flags are used, and also avoid using
CamelCase on Kernel.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is a complex driver. Adding support for other devices with drxk
requires to be able to debug it and see where it is failing. So, add
optional printk messages to allow debugging it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It is hard to identify the origin for those errors without a
prefix to indicate which driver produced them:

[ 1390.220984] i2c_write error
[ 1390.224133] I2C Write error
[ 1391.284202] i2c_read error
[ 1392.288685] i2c_read error
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>