Andrew Dyer wrote: > NAK. > > I2C_TRISTATE is supposed to be persistent until I2C_ACTIVE is called, > so in the original code it should still be in effect when I2C_SDA(1) > is executed and there should be no contention. This patch causes the > code to actively drive SDA high at the same time the addressed device > might be driving it low, causing contention until the I2C_TRISTATE > takes effect. > Right. Whenever possible by the hardware, I make I2C_SDA/SCL(1) do a tri-state and I2C_TRISTATE and I2C_ACTIVE are empty. > In some sense the code is misleadingly written, as it is not allowed > in the spec to actively drive a '1' on the bus, a chip is only > supposed to drive 'z' or '0', and the platform is supposed to provide > the pullup current. This comes more into play if the i2c bus supports > clock stretching or arbitration among multiple masters. > I might point out that the soft I2C as it is does not support clock stretching. Unless you add the wait for SCL high into I2C_SCL(1) yourself.
Reinhard _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
