On Tuesday 15 July 2003 18:50, Ralph Metzler wrote: > 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...
Sure. Another reason why I did the delay stuff: We *know* that the transfer has not been completed yet when we enter the loop... > > ...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. That's bad! Does it simply not work or are there I2C errors? Maybe we could add some fallback mechanism. Oliver -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
