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

["Robert Schlabbach" <robert_s@gmx.net>]

From: "Oliver Endriss" <o.endriss@gmx.de>
> On Tuesday 15 July 2003 16:23, Matthew Davis wrote:
> > Sorry to jump in so late on this discussion.  I played with the I2C
> > bus awhile back, and found that with the system I was working on it
> > *was* a timing problem.  Two reads just gave the I2C bus enough time
> > to settle.
>
> Well, the way it is done now should always work. We do one dummy read
> and wait 20us, before valid data in IICSTA is expected.

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

Regards,
--
Robert Schlabbach
e-mail: robert_s@gmx.net
Berlin, Germany



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