kernel/git/stable/linux.git/drivers/media/dvb-frontends, branch linux-4.8.y

mn88473: fix chip id check on probe

2017-01-09T07:21:59+00:00

commit d930b5b5bf122a61952cfebabb1e618682a2631a upstream. A register used to identify chip during probe was overwritten during firmware download and due to that later probe's for warm chip were failing. Detect chip from the another register, which is located on different register bank 2. Fixes: 7908fad99a6c ("[media] mn88473: finalize driver") Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

mn88472: fix chip id check on probe

2017-01-09T07:21:59+00:00

commit 365fe4e0ce218dc5ad10df17b150a366b6015499 upstream. A register used to identify chip during probe was overwritten during firmware download and due to that later probe's for warm chip were failing. Detect chip from the another register, which is located on different register bank 2. Fixes: 94d0eaa41987 ("[media] mn88472: move out of staging to media") Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

mb86a20s: fix demod settings

2016-10-28T07:45:24+00:00

commit 505a0ea706fc1db4381baa6c6bd2e596e730a55e upstream. With the current settings, only one channel locks properly. That's likely because, when this driver was written, Brazil were still using experimental transmissions. Change it to reproduce the settings used by the newer drivers. That makes it lock on other channels. Tested with both PixelView SBTVD Hybrid (cx231xx-based) and C3Tech Digital Duo HDTV/SDTV (em28xx-based) devices. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

mb86a20s: fix the locking logic

2016-10-28T07:45:24+00:00

commit dafb65fb98d85d8e78405e82c83e81975e5d5480 upstream. On this frontend, it takes a while to start output normal TS data. That only happens on state S9. On S8, the TS output is enabled, but it is not reliable enough. However, the zigzag loop is too fast to let it sync. As, on practical tests, the zigzag software loop doesn't seem to be helping, but just slowing down the tuning, let's switch to hardware algorithm, as the tuners used on such devices are capable of work with frequency drifts without any help from software. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

drivers/media/dvb-frontends/cxd2841er.c: avoid misleading gcc warning

2016-08-04T12:50:07+00:00

The addition of jump label support in dynamic_debug caused an unexpected warning in exactly one file in the kernel: drivers/media/dvb-frontends/cxd2841er.c: In function 'cxd2841er_tune_tc': include/linux/dynamic_debug.h:134:3: error: 'carrier_offset' may be used uninitialized in this function [-Werror=maybe-uninitialized] __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^~~~~~~~~~~~~~~~~ drivers/media/dvb-frontends/cxd2841er.c:3177:11: note: 'carrier_offset' was declared here int ret, carrier_offset; ^~~~~~~~~~~~~~ The problem seems to be that the compiler gets confused by the extra conditionals in static_branch_unlikely, to the point where it can no longer keep track of which branches have already been taken, and it doesn't realize that this variable is now always initialized when it gets used. I have done lots of randconfig kernel builds and could not find any other file with this behavior, so I assume it's a rare enough glitch that we don't need to change the jump label support but instead just work around the warning in the driver. To achieve that, I'm moving the check for the return value into the switch() statement, which is an obvious transformation, but is enough to un-confuse the compiler here. The resulting code is not as nice to read, but at least we retain the behavior of warning if it gets changed to actually access an uninitialized carrier offset value in the future. Link: http://lkml.kernel.org/r/20160713204342.1221511-1-arnd@arndb.de Signed-off-by: Arnd Bergmann Acked-by: Abylay Ospan Cc: Sergey Kozlov Cc: Mauro Carvalho Chehab Cc: Jason Baron Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[media] cxd2841er: Reading SNR for DVB-C added

2016-07-16T10:01:31+00:00

Now driver returns correct values for DVB-C: SNR (in dB) [mchehab@s-opensource.com: fix a new function to be static] Signed-off-by: Abylay Ospan Signed-off-by: Mauro Carvalho Chehab

[media] cxd2841er: Reading BER and UCB for DVB-C added

2016-07-16T09:59:43+00:00

now driver returns correct values for DVB-C: BER (post_bit_count and post_bit_error values) UCB (count of uncorrected errors) also, some code cleanup was done - checkpatch.pl now is happy Signed-off-by: Abylay Ospan Signed-off-by: Mauro Carvalho Chehab

[media] cxd2841er: fix switch-case for DVB-C

2016-07-16T09:58:59+00:00

DVB-C should use cxd2841er_read_agc_gain_c() to get the gain. The same function is used for all DVB-C annex delivery systems. Signed-off-by: Abylay Ospan Signed-off-by: Mauro Carvalho Chehab

[media] cxd2841er: fix signal strength scale for ISDB-T

2016-07-16T09:56:28+00:00

The scale for ISDB-T was wrong too: it was inverted, and on a relative scale. Use a linear interpolation to make it look better. The formula was empirically determined, using 3 frequencies (175 MHz, 410 MHz and 800 MHz), measuring from -50dBm to -12dBm in steps of 0.5dB. Signed-off-by: Mauro Carvalho Chehab

[media] cxd2841er: adjust the dB scale for DVB-C

2016-07-16T09:56:03+00:00

Instead of using a relative frequency range, calibrate it to show the results in dB. The callibration was done getting samples with a signal generated from -50dBm to -12dBm, incremented in steps of 0.5 dB, using 3 frequencies: 175 MHz, 410 MHz and 800 MHz. The modulated signal was using QAM64, and it was used a linear interpolation of all the results. Signed-off-by: Mauro Carvalho Chehab