Hi, On Wed, Dec 05, 2007 at 01:15:45PM +0100, Michael Schnell wrote: > > >(We are using all the devices with a bit-banging driver > >on a different controller, so I know quite exactly what the slaves are > >doing.) > > > This is true if you design the hardware and the driver you are right, > but a standard driver should be configurable for any external chip.
well, first of all, any I2C device should comply to the I2C specification. If there are devices that do not comply to the spec, it might be desirable to make the driver configurable to handle these, too. Breaking the standard in the driver without explicit configuration to do so just to handle broken devices is IMHO inacceptable. There is no ambiguity in the specification that a missing acknowledge is an error condition, and the driver should report this (like e.g. the parallel port bit-banging driver does, BTW). > >There currently are two different problems: > >- the driver in its current state (without my modification) does not > > return an error if there is no acknowledge at all. In this case there > > is no timeout needed because there is no client that could do clock > > stretching. IMHO, this is a straight bug and should be fixed if > > the hardware in all supported processors supports this. I was hoping > > that maybe somebody here has an overview about the I2C controller > > evolution in the coldfire family. > > > I seem to remember that (some years ago) I read a documentation of an > I²C driven chip that issued the ACK not before some internal state was > reached and thus there could be a sequence of dummy clock cycles before > the ACK. But maybe this is off-standard. I did not yet meet this device. AFAIK the only way to force the master to wait is clock-stretching (although it is sometimes called differently), but there you definitely do not have more clock cycles, but the rising edge of the clock is prohibited by the slave pulling the SCL line down until it is done with its internal processing. Thus, it can be reliably detected by the master (by SCL being held low externally) and be handled accordingly. Silently aborting the transfer without an error message is definitely not an option here. (A chip using/needing clock stretching is some MSP34xx (audio decoder) by ITT, not sure about others at the moment.) Regards, Wolfgang _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
