| 349836 |
08-Jul-2019 |
ian |
MFC r348120:
Add a new 'tr' (transfer) mode to i2c(8) to support more i2c controllers.
Some i2c controller hardware does not provide a way to do individual START,
REPEAT-START and STOP actions on the i2c bus. Instead, they can only do
a complete transfer as a single operation. Typically they can do either
START-data-STOP or START-data-REPEATSTART-data-STOP. In the i2c driver
framework, this corresponds to the iicbus_transfer method. In the userland
interface they are initiated with the I2CRDWR ioctl command.
These changes add a new 'tr' mode which can be specified with the '-m'
command line option. This mode should work on all hardware; when an i2c
controller driver doesn't directly support the iicbus_transfer method,
code in the i2c driver framework uses the lower-level START/REPEAT/STOP
methods to implement the transfer. After this new mode has gotten some
testing on various hardware, the 'tr' mode should probably become the
new default mode.
PR: 189914 |
| 323930 |
22-Sep-2017 |
ian |
MFC r323465:
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.
Reported by: Maxim Filimonov <che@bein.link> |
| 287820 |
15-Sep-2015 |
zbb |
Perform I2C transmission in a single burst when mode is "none" or not set
Some more automated I2C controllers cannot explicitly create
START/STOP/etc. conditions on the bus.
Instead, the correct condition is set automatically according
to the pending transfer status.
This particular behavior can cause trouble if some I2C slave
requires sending address offset within the chip followed by
the actual data or command. In that case we cannot assume that
the driver will not STOP immediately after sending
offset.
To avoid that, do not split offset transfer from data transfer
for default transmission modes and do exactly that if requested
in command line (stop-start and repeated-start modes).
This more generic approach should cover special cases like
the one described.
Reviewed by: imp
Submitted by: Marcin Mazurek <mma@semihalf.com>
Obtained from: Semihalf
|