DVB-S/S2 satellite television demodulator driver.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

PER/UCB statistics are collected once on each 1 second.
However, it doesn't provide the total number of packets
needed to calculate PER.

Yet, as we know the bit rate, it is possible to estimate
such number. So, do it.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>

On dib8000, the BER statistics are updated on every 1.25e6 bits.
Adjust the code to only update the statistics after having it
done.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>

On dib8000, the block error count is a monotonic 32 bits register.
With DVBv5 stats, we use a 64 bits counter, that it is reset
when a new channel is tuned.

Change the UCB counting start from 0 and to be returned with
64 bits, just like the API requests.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>

Use multiple linear segments to better interpolate the dBm
for the signal strength.

The table that converts from linear strength to dB was
empirically determinated with the help of a signal generator
(DTA-2111).

The entries from -35dBm to -22.5dBm were taken using just
the signal generator and the board.

For the entries from -36dBm to -51dBm, a 16 dB tap was used,
in order to extend its range.

Signals below to -51dBm are just linearly interpolated.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>

Better to have Signal strength in dB.
This takes a very rough estimation for the signal strength,
that was calibrated using a Dektec DTA-2111 Gold RF generator
and a Pixelview dib8076 stick.

It estimates the signal strength using a linear equation where:
	- the max is -22.5 dBm, with returns 55953
	- the min is -35.0 dBm, with returns 50110

With -22dBm, the signal strengh is returned as 65535.
Unfortunately, the min strength generated with DTA-2111 is
-35dBm.

It should be noticed that approximating it by a linear equation
is not right. I should probably be splitting it into 0.5 dB
linear segments, in order to get a higher precision, just like
it is done on mb86a20s, but that would force me to add some
attenuators, in order to get dB levels below -35dBm, which is,
btw, strong enough to get signal lock.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>

The advantage of DVBv5 stats is that it allows adding proper
scales to all measures. use it for this frontend.

This patch adds a basic set of stats, basically cloning what's already
provided by DVBv3 API. Latter patches will improve it.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>

On ISDB-T, the valid values for interleaving are 0, 1, 2 and 4.
While the first 3 are properly reported, the last one is reported
as 3 instead. Fix it.

Tested with a Dektec DTA-2111 RF generator.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>

The logic that detects if auto search mode should be used is too
complex.

Also, it doesn't cover all cases, as the dib8000_tune logic
requires either auto mode or a fully specified manual mode.
So, move it to a separate function and add some extra debug
data to help identifying when it falled back to auto mode,
because the manual settings are invalid.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>

Both dvbv5-scan and dvbv5-zap tools call FE_GET_PROPERTY inside the
loop that checks for stats. If the frontend doesn't support DVBv5, it
falls back to call the DVBv5 stats APIs(FE_READ_BER, FE_READ_SIGNAL,
FE_READ_SNR and FE_READ_UNCORRECTED_BLOCKS).

A call to FE_GET_PROPERTY makes dvb-frontend core to call get_frontend().

However, due to a race condition on dib8000 between dib8000_get_frontend
and dib8000_tune, if get_frontend occurs too early, it causes the
tune state machine to fail and not get any lock.

This patch adds a workaround code that makes get_frontend() to just
return if none of the frontends have a SYNC. This change fixed the issue
with dvbv5-scan/dvbv5-zap, but a fine-tuned logic might be needed in
the future, when we implement DVBv5 stats on this frontend.

The procedure to test the bug and the fix is the one below:

1) tune into a non-existing frequency with:

	$ dvbv5-zap -I dvbv5 -c non_existing_freqs -m 679142857 -t3

2) tune/lock into an existing frequency with:

	$ dvbv5-zap -I dvbv5 -c isdb-test -m 479142857
    or
	$ dvbv5-scan isdb-test

In this case, 679 MHz carrier doesn't exist. Only 479 MHz does.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>

As the dvb-frontend kthread can be called anytime, it can race
with some get status ioctl. So, it seems better to avoid one to
race with the other while reading a 32 bits register.
I can't see any other reason for having a mutex there at I2C, except
to provide such kind of protection, as the I2C core already has a
mutex to protect I2C transfers.

Note: instead of this approach, it could eventually remove the dib8000
specific mutex for it, and either group the 4 ops into one xfer or
to manually control the I2C mutex. The main advantage of the current
approach is that the changes are smaller and more puntual.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>

Commit 173a64cb broke support for some dib807x versions.

Fix it by providing backward compatibility with the older versions.

[mkrufky@linuxtv.org: conflict handling and CodingStyle fixes]
Signed-off-by: NOlivier Grenie <olivier.grenie@parrot.com>
Acked-by: NPatrick Boettcher <pboettcher@kernellabs.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

PCTV 461e requires that small delay.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

i2c i2c-6: adapter [RTL2830 tuner I2C adapter] registered
BUG: unable to handle kernel NULL pointer dereference at 0000000000000220
IP: [<ffffffffa0002900>] i2c_register_adapter+0x130/0x390 [i2c_core]
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix various spelling errors in strings and comments throughout the media
tree. The majority of these were found using Lucas De Marchi's codespell
tool.

[m.chehab@samsung.com: discard hunks with conflicts]
Signed-off-by: NJonathan McCrohan <jmccrohan@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This patch should fix/enhance the set_voltage function for
the cx24117 demodulator.
Signed-off-by: NLuis Alves <ljalvs@gmail.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This patch adds the complete list of all the commands known
for the cx24117 demodulator.
Signed-off-by: NLuis Alves <ljalvs@gmail.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Driver did not work anymore since I2C has gone broken due
to recent commit:
commit 37ebaf68
[media] dvb-frontends: Don't use dynamic static allocation
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Cc: stable@vger.kernel.org

i2c i2c-6: adapter [RTL2830 tuner I2C adapter] registered
BUG: unable to handle kernel NULL pointer dereference at 0000000000000220
IP: [<ffffffffa0002900>] i2c_register_adapter+0x130/0x390 [i2c_core]
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix various spelling errors in strings and comments throughout the media
tree. The majority of these were found using Lucas De Marchi's codespell
tool.

[m.chehab@samsung.com: discard hunks with conflicts]
Signed-off-by: NJonathan McCrohan <jmccrohan@gmail.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

fixes tuning for DVB-C
Signed-off-by: NEvgeny Plehov <EvgenyPlehov@ukr.net>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
       drivers/media/dvb-frontends/stv090x.c:750:1: warning: 'stv090x_write_regs.constprop.6' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for	the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
 On most cases, the limit is a way lower than that, but	this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
	drivers/media/dvb-frontends/stv0367.c:791:1: warning: 'stv0367_writeregs.constprop.4' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for	the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
 On most cases, the limit is a way lower than that, but	this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
	drivers/media/dvb-frontends/stb0899_drv.c:540:1: warning: 'stb0899_write_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for	the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
 On most cases, the limit is a way lower than that, but	this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
	drivers/media/dvb-frontends/af9013.c:77:1: warning: 'af9013_wr_regs_i2c' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/af9033.c:188:1: warning: 'af9033_wr_reg_val_tab' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/af9033.c:68:1: warning: 'af9033_wr_regs' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/cxd2820r_core.c:84:1: warning: 'cxd2820r_rd_regs_i2c.isra.1' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/rtl2830.c:56:1: warning: 'rtl2830_wr' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/rtl2832.c:187:1: warning: 'rtl2832_wr' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/tda10071.c:52:1: warning: 'tda10071_wr_regs' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/tda10071.c:84:1: warning: 'tda10071_rd_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for	the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
 On most cases, the limit is a way lower than that, but	this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: NHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
	drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/itd1000.c:69:1: warning: 'itd1000_write_regs.constprop.0' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/mt312.c:126:1: warning: 'mt312_write' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/nxt200x.c:111:1: warning: 'nxt200x_writebytes' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/stb6100.c:216:1: warning: 'stb6100_write_reg_range.constprop.3' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/stv6110.c:98:1: warning: 'stv6110_write_regs' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/stv6110x.c:85:1: warning: 'stv6110x_write_regs' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/tda18271c2dd.c:147:1: warning: 'WriteRegs' uses dynamic stack allocation [enabled by default]
	drivers/media/dvb-frontends/zl10039.c:119:1: warning: 'zl10039_write' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
 On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
	drivers/media/dvb-frontends/s5h1420.c:851:1: warning: 's5h1420_tuner_i2c_tuner_xfer' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this frontend, only ttpci uses it. The maximum
number of messages there is two, on I2C read operations. As the logic
can add an extra operation, change the size to 3.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Use R820T config for R828D too as those are about same tuner.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

drivers/media/dvb-frontends/drxk_hard.c:1086:62: warning: Using plain integer as NULL pointer
drivers/media/dvb-frontends/drxk_hard.c:2784:63: warning: Using plain integer as NULL pointer
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Reviewed-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

drivers/media/dvb-frontends/drxd_hard.c:1017:70: warning: Using plain integer as NULL pointer
drivers/media/dvb-frontends/drxd_hard.c:1038:69: warning: Using plain integer as NULL pointer
drivers/media/dvb-frontends/drxd_hard.c:2836:33: warning: Using plain integer as NULL pointer
drivers/media/dvb-frontends/drxd_hard.c:2972:30: warning: Using plain integer as NULL pointer
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Reviewed-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

drivers/media/dvb-frontends/cxd2820r_core.c:34:32: error: cannot size expression
drivers/media/dvb-frontends/cxd2820r_core.c:68:32: error: cannot size expression
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NAntti Palosaari <crope@iki.fi>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Reviewed-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

These aren't necessary after switch and while statements.
Signed-off-by: NJoe Perches <joe@perches.com>
Reviewed-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This patch will fix the situation where the mutex was left in a
locked state if for some reason the FE init failed.
Signed-off-by: NLuis Alves <ljalvs@gmail.com>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

...and remove the frontend pointer param from cx24117_attach()
Signed-off-by: NLuis Alves <ljalvs@gmail.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Add support for the cx24117 dual DVB-S/S2 frontend.
Signed-off-by: NLuis Alves <ljalvs@gmail.com>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Changeset 9e8da9e8 added a parameter to specify the frequency
divisor, used by the driver. However, not all places are passing
this parameter. So, preserve the previous default, to avoid breaking
the existing drivers.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

[media] media: dvb-frontends: ts2020: Added in a option for frequency divider value for s600 devices

When the tuner part of the ds3000 driver was split to share code with the m88rs2000 driver, the ts2020 driver used
the frequency divider value from the m88rs2000 driver.  However the ds3000 driver requires a different value, and this
resulted in some frequecies being invisible to the tuner.  This patch adds back in the value needed for the ds3000 driver
and configured as an option in the dw2102 frontend driver.
It may also apply to su3000 devices, which use the same ds3000 driver, but for now it is only applied to the s660 device.
Signed-off-by: NJohn Horan <knasher@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Thanks-to: Joe Perches <joe@perches.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Make sure that a format string cannot accidentally
leak into the printk buffer.
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

SIZEOF_ARRAY is not used (anymore). Besides, ARRAY_SIZE, defined in
include/linux/kernel.h, should be used rather than explicitly coding some
variant of it.
Signed-off-by: NChristoph Jaeger <christophjaeger@linux.com>
Reviewed-by: NSakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>