From: Mauro Carvalho Chehab <m.chehab@samsung.com>
Date: Sun, 15 Dec 2013 09:41:20 +0000 (-0200)
Subject: [media] dib8000: Don't let tuner hang due to a call to get_frontend()
X-Git-Tag: v3.14-rc1~20^2~238
X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=70315b3eafabd35ce5f2d43dc82517f66d8ce066;p=pandora-kernel.git

[media] dib8000: Don't let tuner hang due to a call to get_frontend()

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: Mauro Carvalho Chehab <m.chehab@samsung.com>
Acked-by: Patrick Boettcher <pboettcher@kernellabs.com>
---

Reading git-diff-tree failed