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