[U-Boot-Users] ack problem in common/soft_i2c.c?

[Andrew Dyer <amdyer@gmail.com>]

I am working with the soft i2c code on my target and I believe
there is a problem in the send_ack() function.

My hardware (au1550) uses standard push-pull drivers which
can be tri-stated by changing them to inputs, so I have
I2C_ACTIVE and I2C_TRISTATE defined as per the README.

When reading the real time clock (ST M41T60) on my board
I could never get 8 successive reads of the device to complete.
Somewhere in the middle of reading the data the clock would
start returning 0xff.  If I read the registers one at a time, it
worked fine.

read_byte() leaves the clock high at the end of shifting in the
read data.  usually the internal state of the data out register on
the CPU was low from generating the last ack and the data line
is tristate on the CPU (done at the start of read_byte()).
The physical data line is in an unknown state depending on
the last data bit read.

Looking at the beginning of the send_ack() code it goes:

I2C_ACTIVE;
I2C_SCL(0);
I2C_DELAY;

If the external data line is high and the internal register for the I/O
on the CPU is low, this will generate a repeated start condition.
It might be missed by a lot of parts since the edges happen with
minimal delay in between.

In my case changing the order to:

I2C_SCL(0);
I2C_DELAY;
I2C_ACTIVE;

seems to fix my issues.  Unfortunately due to internal CVS/firewall/VPN 
issues I can't get a patch together easily right now.


-- 
Hardware, n.:
        The parts of a computer system that can be kicked.