[linux-dvb] Re: Busy waiting in i2c_busy_rise_and_fall (was: Re: Re: full featured card without signal and required video memory investigation)

[Ralph Metzler <rjkm@metzlerbros.de>]

Robert Schlabbach writes:
 > FWIW, I found the IICSTA bug with a Siemens DVB-Cable card, which had an
 > SAA7146A with a manufacturing date in 2000 on it (if I understand the
 > markings on the chip correctly). Maybe Philips has fixed the bug in an
 > updated revision of the chip...?
 > 
 > As to the delay, keep in mind that the 33MHz PCI clock gives you a pretty
 > solid timing, completely independent of CPU speed. So just reading the
 > IICSTA register twice should still be enough, even with the fastest CPUs.
 > But since it will take a few loop runs for the transfer to finish anyway,
 > it doesn't matter whether you read or delay first either...
 > 
 > ...assuming the Linux kernel really does have such a fine-grained delay
 > resolution. Does it really only wait 20us? FWIW, the reason I removed the
 > delays in my _Windows_ driver code was that while the delay resolution
 > could be specified in 100ns units, it would in fact delay with a
 > granularity of 10 _milli_seconds (the resolution of the system timers in
 > the uniprocessor NT HAL), so just a single delay call would take much
 > longer than the actual transfer...

Yes, udelay() really waits about 20us if it is not interrupted by the
scheduler or other interrupts. It is calibrated at boot time.

Btw., on one PC (Duron 1200, KT7) here the faster I2C timing 
breaks tuning. Anything below BUS_BIT_RATE_3200 does not work 
reliably. On a different board (Athlon XP2400+, KT400) with the same
DVB card type it works fine.


Ralph


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