Mailing List archive

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

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



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).

Except that I2C devices are allowed to stretch out the time to
complete an I2C transfer, so if e.g. the PLL is really slow
the timeout of SAA7146_I2C_TIMEOUT (100) * 20 usec would be
too short.


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?

If yes, we should not change the udelay() value but SAA7146_I2C_TIMEOUT.


Johannes


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



Home | Main Index | Thread Index