diff options
author | Mauro Carvalho Chehab <mchehab@redhat.com> | 2012-01-17 22:20:37 +0400 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@redhat.com> | 2012-01-17 22:20:37 +0400 |
commit | 51dcb19aaf9448f6547f653b60a9f083845aad4a (patch) | |
tree | 0e428e66df6e83c90a5bb0129c15fc117f4ceb75 /drivers/media/dvb/frontends/stv090x_priv.h | |
parent | 7bb0f088f8dd1d60b8f5743471cc3db3f820df59 (diff) | |
download | linux-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