summaryrefslogtreecommitdiff
path: root/mm
diff options
context:
space:
mode:
authorDaniel Scheller <d.scheller@gmx.net>2017-07-14 17:23:36 -0400
committerMauro Carvalho Chehab <mchehab@s-opensource.com>2017-07-20 15:16:48 -0400
commitd105d083448e79ec3f4b1d3f501b869a4515a1d0 (patch)
tree3cf1a6a324ae81c48821f0897a339e0bcdcaaf2b /mm
parent552636be7afc86531d1931b5104d7002850d3af7 (diff)
downloadlinux-next-d105d083448e79ec3f4b1d3f501b869a4515a1d0.tar.gz
linux-next-d105d083448e79ec3f4b1d3f501b869a4515a1d0.zip
media: dvb-frontends/stv0367: improve QAM fe_status
While cab_state->state gives a quite accurate indication of the demod signal status, it might be incorrect if cab_algo() wasn't able to determine the exact status, with cab_algo() being the only place where this status was updated from, and it is only called upon tuning to new parameters passed to set_frontend(). Thus, the status will be wrong until the demod is retuned. With the cab_signal_type parsing in read_status(), this results in unusual fe_states like FE_HAS_SIGNAL | FE_HAS_CARRIER | FE_HAS_LOCK, which, while userspace applications check for FE_HAS_LOCK and work fine, leads to missing CNR or UCB stats. Fix this by re-reading CAB_FSM_STATUS and updating cab_state->state() in read_status(). While at it, refactor the fsm/qamfeclock and the fsm->signaltype parsing into separate functions to make things cleaner and deduplicate code. Also, assume full QAM FEC lock equals full FE_STATUS. Signed-off-by: Daniel Scheller <d.scheller@gmx.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions