[linux-dvb] Re: Transponder switching taking considerably longer

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Oliver Endriss wrote:
> 
> On Wednesday 30 July 2003 18:11, Klaus Schmidinger wrote:
> > Johannes Stezenbach wrote:
> > > Klaus Schmidinger wrote:
> > > > There are 3 xfer() calls in alps_bsrv2.c, but only the first one
> > > > appears to be relevant - a udelay(500) after the other two didn't
> > > > change anything.
> > > >
> > > > So I did the following:
> > > >
> > > > --- alps_bsrv2.c.001    Sat May 10 11:32:33 2003
> > > > +++ alps_bsrv2.c        Tue Jul 29 18:11:41 2003
> > > > @@ -20,6 +20,7 @@
> > > >
> > > >  */
> > > >
> > > > +#include <linux/delay.h>
> > > >  #include <linux/module.h>
> > > >  #include <linux/init.h>
> > > >
> > > > @@ -83,6 +84,7 @@
> > > >                 dprintk ("%s: writereg error (err == %i, reg ==
> > > > 0x%02x, data == 0x%02x)\n", __FUNCTION__, err, reg, data); return
> > > > -EREMOTEIO;
> > > >         }
> > > > +        udelay(300);
> > > >
> > > >          return 0;
> > > >  }
> > >
> > > OK, that's a lot better than slowing down I2C globally.
> > > I reckon that it would be sufficient to put udelays after
> > > the ves1893_writereg()s in ves1893_clr_bit() and maybe
> > > ves1893_set_voltage(). Could you please try that?
> >
> > I did that by adding a udelay(300) after each ves1893_writereg()
> > in these two functions, but I can't say that this actually improved
> > things. After going back to the udelay(300) in ves1893_writereg()
> > itself things were better again.
> 
> I would try to add udelay(300) after *every* ves1893_writereg() call in
> the file. Hm, maybe it's easier to add a call *before* every call
> because of the "return ves1893_writereg()" statements.
> This should produce identical results as one udelay() in
> ves1893_writereg().
> 
> Then I would remove one udelay(300) after the other until the problem
> appears. This would produce a better fix and improve our understanding
> what's going wrong here.

I did that, and it turned out that ves1893_set_symbolrate() is where it happens.
With this diff...

--- alps_bsrv2.c.001    Sat May 10 11:32:33 2003
+++ alps_bsrv2.c        Thu Jul 31 17:58:42 2003
@@ -20,6 +20,7 @@
 
 */    
 
+#include <linux/delay.h>
 #include <linux/module.h>
 #include <linux/init.h>
 
@@ -71,7 +72,6 @@
         1,1,1,0,1,1
 };
 
-
 static
 int ves1893_writereg (struct dvb_i2c_bus *i2c, u8 reg, u8 data)
 {
@@ -268,18 +268,22 @@
        ves1893_writereg (i2c, 0x06, 0xff & BDR);
        ves1893_writereg (i2c, 0x07, 0xff & (BDR >> 8));
        ves1893_writereg (i2c, 0x08, 0x0f & (BDR >> 16));
+        udelay(800);
 
        ves1893_writereg (i2c, 0x09, BDRI);
        ves1893_writereg (i2c, 0x20, ADCONF);
        ves1893_writereg (i2c, 0x21, FCONF);
+        udelay(800);
 
        if (srate < 6000000) 
                ves1893_writereg (i2c, 0x05, init_1893_tab[0x05] | 0x80);
        else
                ves1893_writereg (i2c, 0x05, init_1893_tab[0x05] & 0x7f);
+        udelay(800);
 
        ves1893_writereg (i2c, 0x00, 0x00);
        ves1893_writereg (i2c, 0x00, 0x01);
+        udelay(800);
 
        ves1893_clr_bit (i2c);
 
...I get pretty good switching times, just as if I had the udelay() right inside
ves1893_writereg() itself. Note that this diff is against the 2003-07-25 version
and does not include the change Johannes made yesterday (which is obsolete if
you apply _this_ change). I tried to leave out some of these udelay()s and also
used various time values, but this is pretty much what gives the best results.

There is still the occasional dvb_frontend_recover, but overall it works a lot
better than without the udelay()s.

> > > > Athough I still get the feeling that the driver dated 2003-07-13
> > > > switches between transponders a little faster, with the above
> > > > change things are now a lot better in the current driver.
> > >
> > > Hm, since I2C is faster now, slower tuning would then be due to
> > > tuning problems covered by the zig-zag scan. You could put a
> > > printk() in dvb_frontend.c:dvb_frontend_recover() to find out.
> > > Maybe a small delay is necessary between DiSEqC/tone/volt and
> > > FE_SET_FRONTEND. A delay in ves1893_set_voltage() should then
> > > do the trick.
> >
> > I enabled the dprintk() at the beginning of dvb_frontend_recover()
> > and got occasional outputs. With the udelay(300) in
> > ves1893_writereg() I get this only very rarely (if ever), but with
> > the udelays only in the two functions you mentioned I get the output
> > frequently (and apparently whenever there is a longer pause between
> > transponder switches).
> >
> > Sorry for not being able to provide better news, but apart from the
> > previous (2003-07-13) DVB driver I get the best results with
> > udelay(300) in ves1893_writereg(). Even a udelay(10000) in
> > ves1893_set_voltage() (as you suggested) didn't help.
> 
> You mentioned that the 2003-07-13 driver appears to tune slightly
> faster, even with udelay(300). Did you check how often
> dvb_frontend_recover() is called in the old driver?

I activated the dprintk() in that driver version, too, but I never got
a log message from there during some heavy channel switching (a test sequence
that usually brings at least one dvb_frontend_recover in the new version,
even with the above patch).

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


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