see also the last part of i2c/TODO which contains archived mail about
algo-bit vs. algo-biths issues.
Axel Thimm wrote:
> Hi,
>
> On Sat, Jun 04, 2005 at 06:02:54PM +0200, Jean Delvare wrote:
>
>>>currently the bit shift algorithm in i2c-algo-bit.c is using at least
>>>27 udelays per byte (3 per bit and another 3 per byte).
>>>
>>>Can this be optimized for a block transfer? Does one need to check for
>>>a timeout on each bit or is there a persistent error flag that can be
>>>checked after a larger transaction?
>>
>>I don't see any "check for timeout" thing in i2c-algo-bit.
>
>
> There are checks like
>
> if (sclhi(adap)<0) { /* timed out */
>
> but on second reading this is needed anyway.
>
>
>>The delays are simply meant to control the frequency of the
>>transmission. What you may be confused by is simply the fact that
>>the implemented algorithm leads to a 33/67 duty cycle rather than a
>>50/50 one as you would expect. There is nothing wrong with that,
>>nothing in the I2C specification prevents you from doing so.
>>
>>
>>>The background is an i2c interface on a TV capture card which is used
>>>for a firmware upload (a Hauppauge WinTV 150). The firmware is 14kB
>>>and takes ~4-5 seconds of upload time on 100kHz.
>>
>>14kB at 100kHz should take no more than 1.5 second. More likely your bus
>>is running at 33kHz rather than 100kHz. This is what you get when
>>specifying .udelay = 10 for i2c-algo-bit. Each bit takes three delays,
>>1/(3*10us) = 33kHz. If you know all the chips on the bus can handle
>>100kHz (presumably guaranteed at 50/50 duty cycle), then you can try to
>>lower .udelay to 5, I'd expect it to work.
>
>
> That's probably my error in thinking, I thought a 100kHz bus would
> imply a minimal udelay of 10us, but if 33/66 is allowed within the
> 10us, e.g. ~ 3us/6us then I'm already happy! :)
>
>
>>You may want to look at i2c-algo-biths in the lm_sensors project. This
>>was an attempt to get a 50/50 duty cycle bit-banging algorithm,
>>supposedly faster than the original one. I'd expect "faster" to mean
>>lower CPU load, as the speed itself merely depends on the chosen delays.
>>It is no more built by default because it is unmaintained (it has no
>>user and was never ported to Linux 2.6), but if you want to revive it
>>and can prove it to be useful, it could replace the original
>>implementation in the long run.
>
>
> OK, thanks for the pointer, I will check this!
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors at lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
