[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>
Showing
Please register or sign in to comment