Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Friday 25 July 2003 19:32, Johannes Stezenbach wrote:
> I wrote:
> > Anyway, we should find out if it's really the I2C speed that's
> > causing problems (I2C errors), or if some other timing is the
> > problem. I'm going tpo enable some debug prints to find out.
> > IIRC Robert Schlabbach suggested that we need to sleep some usecs
> > after writing to the PLL. We could try that.
> >
> >
> > I get tuning errors with scan which go away on the second tuning
> > attempt. I've notice no tuning slowdown with other programs.
>
> These were due to a bug in scan. Now everything works rock solid
> with the fast I2C timings; the max. number of iterations in
> i2c_busy_rise_and_fall() with udelay(20) is 4, so I don't see
> what the udelay(500) could change (except make things slower).

Well, it addes 420us after each I2C transfer. Since there are more than 
10 I2C transfers per tuning attempt, the pll/frontend has much more 
time to lock before the status gets checked.

> Klaus, can you change the
> 	hprintk("saa7146: i2c_busy_rise_and_fall: timeout #2\n");
> to
> 	printk("saa7146: i2c_busy_rise_and_fall: timeout #2\n");
>
> and report if you get timeouts with the fast I2C timing?

Yes, that's another possibility.

Oliver


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



Home | Main Index | Thread Index