On Tue, 2017-10-10 at 19:23 +0300, Andriy Gapon wrote: > On 10/10/2017 19:12, Ian Lepore wrote: > > > > On Tue, 2017-10-10 at 17:45 +0300, Andriy Gapon wrote: > > > > > > On 12/09/2017 00:49, Ian Lepore wrote: > > > > > > > > > > > > Author: ian > > > > Date: Mon Sep 11 21:49:38 2017 > > > > New Revision: 323465 > > > > URL: https://svnweb.freebsd.org/changeset/base/323465 > > > > > > > > Log: > > > > Make i2c -s (device scan) work on hardware that supports only full > > > > xfers. > > > > > > > > The existing scan code is based on sending an i2c START condition and > > > > if > > > > there is no error it assumes there is a device at that i2c address. > > > > Some > > > > i2c controllers don't support sending individual start/stop signals > > > > on the > > > > bus, they can only perform complete data transfers with start/stop > > > > handled > > > > in the silicon. > > > > > > > > This adds a fallback mechanism that attempts to read a single byte > > > > from each > > > > i2c address. It's less reliable than looking for an an ACK repsonse > > > > to a > > > > start, because some devices will NAK an attempt to read that isn't > > > > preceeded > > > > by a write of a register address. Writing to devices to probe them > > > > is too > > > > dangerous to even consider. The user is told that a less-reliable > > > > scan is > > > > being done, so even if the read-scan comes up empty too, it's still a > > > > vast > > > > improvement over the old situation where it would just claim there > > > > were no > > > > devices on the bus even though the devices were there and working > > > > fine. > > > > > > > > If the i2c controller responds with a proper ENODEV (device doesn't > > > > support > > > > operation) or an almost-proper EOPNOTSUPP, the START/STOP scan is > > > > switched > > > > to a read-scan right away. Most controllers respond with ENXIO or > > > > EIO if > > > > they don't support START/STOP, so no quick-out is available. For > > > > those, > > > > if a scan of all 127 addresses and come up empty, the scan is re-done > > > > using > > > > the read method. > > > Perhaps the new scan method should have been added as a separate option > > > that has > > > to be explicitly activated... My concern is that there are some extremely > > > simple I2C devices out there that do no sanity checking and may get > > > confused > > > > > i2c -s is not a thing that's done routinely in a production system or > > normal system operations... it's something a person does manually when > > trying to configure or debug a system. > Right. And another point, it's not extremely hard to type another option on > the > command line. I haven't suggested that the functionality should not have been > added at all, I have just suggested adding a new option to unlock it. >
This conversation is making me think harder about what's happening on the bus during the two different kinds of scans, and I'm realizing the answer is "almost exactly the same thing in both cases". A "normal" scan is a START, followed by 9 clocks during which the slave address is put on the bus and either an ACK or NAK happens, followed by a STOP. A new-style "read" scan is a START, followed by 9 clocks during which the slave address is put on the bus and either an ACK or NAK happens, followed by 9 more clocks for transferring a byte+NAK, followed by a STOP. So the entire difference is 9 extra clocks, in terms of bus behavior. Operationally, the slave device already indicated a willingness to service a read operation when it ACK'd its address following the start. Actually doing the read shouldn't put the device into a bad state, but I guess we could theorize it might... maybe it likes to work in 16-bit chunks and a STOP after 8 bits confuses it. But before the stop comes a NAK from the master which says "I don't want to read anymore" and if that confuses the device, it's violating the protocol. All in all, I'm now wondering if what should change is removing the wording about the read-based scan being somehow "less reliable", I don't think it really is. -- Ian _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
