[linux-dvb] Re: Frontend experimental patch v1

[a.share@t-online.de (Andreas Share)]

> On Wednesday 03 March 2004 20:32, Andreas Share wrote:
> > > > the ves1x93 driver do FE_RESET (aka ves1x93_clr_bit) also at the end
of
> > > > ves1x93_set_symbolrate (after tuning), so i think we should remove
this
> > > > also. Or need this tuner clr_bit twice?
> > >
> > > Are you able to test to see if it can work without it? I don't have
one
> > > of these tuners to find out myself unfortunately.
> >
> > Hi,
> >
> > i have tested this last week, only one clr_bit is needed after tuning.
So,
> > if you "FE_RESET" after tuning in the core frontend stuff with FE_POLL
(if
> > i have understand this correct), there is no need for doing this after
> > setting the symbolrate.
> >
> > Or, possilbe the better way, we donīt do a "RESET" in the core stuff for
> > the ves1x93 and let the clr_bit stay as is in the symbolrate routine.
This
> > is maybe better, because the tuxbox project share the ves1x93 driver
with
> > "us"; the dbox2 uses the same demod. So the frontend driver have a
chance
> > to differ between ves1893 who need the "reset" and the ves1993 who will
> > irritate by this.
>
> The FE_POLL stuff resets the frontend up to 10 times after tuning. I was
told
> these frontends (or one of them at least) need this behaviour to lock on
at
> all.
>
> Which one did you test and find only one reset was needed? I assume it
must be
> the _other_ one that needs the horrible FE_POLL stuff.
>
> Is there any way of telling the difference between these two... if so, it
> would be best only to set FE_NEEDS_POLL for the one which needs it, which
> should solve the problem.
>

Hi Andrew,

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).

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....

Greetings

Andreas Share



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