[linux-dvb] Re: Frontend experimental patch v1

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

> > 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.
> >
> > Maybe Andreas Oberritter could say anything about this...
>
> Weird, I see what you mean; the code doesn't do the clr_bit() if its a
> ves1993... although it _will_ have been having it done previously because
of
> the old call to FE_RESET.
>
> Why then would there need to be multiple clr_bit() calls for the ves1893
then
> I wonder if only one is really needed?

Hi,

i donīt know, but i have tested several times with only one clr_bit() (the
one in set_symbolrate) over the last week, and i have no seen any difference
between this and multiple clr_bit() in tuning. As Andreas have no problem if
we break the driver for ves1993 i mentioned following:

Removing the clr_bit() in set_symbolrate
Set up the frontend for FE_NEEDS_POLL
Do only one clr_bit() in case FE_POLL (after tuning)
Set up some short delay around ~20ms (ddelay(2)) after tuning, and before
the clr_bit(), i think this is nessasary because the old 0.9.4 driver works
in this way.

BTW: In the old 0.9.4 driver code the clr_bit() was doing twice, but i think
somebody have forgot to remove one of the "resets".

But i will do some more tests over the weekend.

Greetings

Andreas Share



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