[linux-dvb] Re: Frontend experimental patch v1

[Andrew de Quincey <adq_dvb@lidskialf.net>]

> I have done some more tests arount crl_bit() in ves1x93 with my Rev 1.3
> DVB-S (ves1893). Realy only one "soft reset" is needed for this demod (and
> i think for the ves1993 too) to aquire lock. But the ves1893 needs some
> short delay (according to the ves1893 appnote), up to ~500.000 Symbols
> after the reset.
>
> I think, we should hold dvb_frontend.c(h) most common as possible, so all
> this RESET Stuff should be moved completly into the lowlevel frontend
> drivers (if possible/ if nessasary).

Cool! In that case, you sort out the ves1893 driver, and I'll remove the 
unneeded FE_POLL/FE_RESET stuff. I don't have any information on any of those 
tuners so I can't really do much myself.

> BTW: Do you or somebody else know, why we do FE_SET_FRONTEND twice (via
> before/after_ioctl) ? On my machines the driver will call SET_TONE,
> FE_SET_FRONTEND, than closing Pids/Filters (and demux, i think), and then
> call again SET_TONE, FE_SET_FRONTEND. This doubles tuning time, especialy
> if the frontend needs some delays....

I'm not really sure whats going on with that stuff. The code seems to do:

call before_ioctl()
if that returned -EOPNOTSUPP: call ioctl()
if that returned -EOPNOTSUPP: call after_ioctl()

I assume this is to allow cards which may do things in a funny way.. e.g. the 
DISEQC is done by the card itself, and not by the frontend.

It certainly shouldn't cause multiple calls to be directed at the frontend 
unless something is really knackered... I don't remember seeing this 
behaviour myself.


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.