summaryrefslogtreecommitdiff
path: root/drivers/media/dvb/frontends/stv090x_priv.h
diff options
context:
space:
mode:
authorMauro Carvalho Chehab <mchehab@redhat.com>2012-01-17 22:20:37 +0400
committerMauro Carvalho Chehab <mchehab@redhat.com>2012-01-17 22:20:37 +0400
commit51dcb19aaf9448f6547f653b60a9f083845aad4a (patch)
tree0e428e66df6e83c90a5bb0129c15fc117f4ceb75 /drivers/media/dvb/frontends/stv090x_priv.h
parent7bb0f088f8dd1d60b8f5743471cc3db3f820df59 (diff)
downloadlinux-51dcb19aaf9448f6547f653b60a9f083845aad4a.tar.xz
[media] dvb_frontend: Don't call get_frontend() if idle
If the frontend is in idle state, don't call get_frontend. Calling get_frontend() when the device is not tuned may result in wrong parameters to be returned to the userspace. I was tempted to not call get_frontend() at all, except inside the dvb frontend thread, but this won't work for all cases. The ISDB-T specs (ABNT NBR 15601 and ARIB STD-B31) allow the broadcaster to dynamically change the channel specs at runtime. That means that an ISDB-T optimized application may want/need to monitor the TMCC tables, decoded at the frontends via get_frontend call. So, let's do the simpler change here. Eventually, the logic could be changed to work only if the device is tuned and has lock, but, even so, the lock is also standard-dependent. For ISDB-T, the right lock to wait is that the demod has TMCC lock. So, drivers may need to implement some logic to detect if the get_frontend info was retrieved or not. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'drivers/media/dvb/frontends/stv090x_priv.h')
0 files changed, 0 insertions, 0 deletions