> > 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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
