| 1 |
1275 |
phoenix |
i2c-core is the core i2c module (surprise!) which offers general routines on
|
| 2 |
|
|
which other modules build. You will find that all i2c-related modules depend
|
| 3 |
|
|
on this module, so it will (need to) be loaded whenever another i2c-related
|
| 4 |
|
|
module is loaded. Seen from the outside, the most interesting is the /proc
|
| 5 |
|
|
interface. Note that there is no corresponding sysctl interface!
|
| 6 |
|
|
|
| 7 |
|
|
/proc/bus/i2c
|
| 8 |
|
|
=============
|
| 9 |
|
|
|
| 10 |
|
|
Whenever i2c-core is loaded, you will find a file /proc/bus/i2c, which lists
|
| 11 |
|
|
all currently registered I2C adapters. Each line contains exactly one
|
| 12 |
|
|
I2C adapter. Each line has the following format: "i2c-%d\t%9s\t%-32s't%-32s\n",
|
| 13 |
|
|
which works out to four columns separated by tabs. Note that the file
|
| 14 |
|
|
will be empty, if no adapters are registered at all.
|
| 15 |
|
|
|
| 16 |
|
|
Adapters are numbered from 0 upwards. The first column contains the number
|
| 17 |
|
|
of the adapter, for example "i2c-4" for adapter 4. The name listed is also
|
| 18 |
|
|
the name of the /proc file which lists all devices attached to it, and
|
| 19 |
|
|
of the /dev file which corresponds to this adapter.
|
| 20 |
|
|
|
| 21 |
|
|
The second column documents what kind of adapter this is. Some adapters
|
| 22 |
|
|
understand the full I2C protocol, others only a subset called SMBus,
|
| 23 |
|
|
and yet others are some kind of pseudo-adapters that do not understand
|
| 24 |
|
|
i2c at all. Possible values in here are "i2c", "smbus", "i2c/smbus"
|
| 25 |
|
|
and "dummy". Because the SMBus protocol can be fully emulated by i2c
|
| 26 |
|
|
adapters, if you see "i2c" here, SMBus is supported too. There may
|
| 27 |
|
|
be some future adapters which support both specific SMBus commands and
|
| 28 |
|
|
general I2C, and they will display "i2c/smbus".
|
| 29 |
|
|
|
| 30 |
|
|
The third and fourth column are respectively the algorithm and adapter
|
| 31 |
|
|
name of this adapter. Each adapter is associated with an algorithm,
|
| 32 |
|
|
and several adapters can share the same algorithm. The combination of
|
| 33 |
|
|
algorithm name and adapter name should be unique for an adapter, but
|
| 34 |
|
|
you can't really count on that yet.
|
| 35 |
|
|
|
| 36 |
|
|
|
| 37 |
|
|
/proc/bus/i2c-*
|
| 38 |
|
|
===============
|
| 39 |
|
|
|
| 40 |
|
|
Each registered adapter gets its own file in /proc/bus/, which lists
|
| 41 |
|
|
the devices registered to the adapter. Each line in such a file contains
|
| 42 |
|
|
one registered device. Each line has the following format:
|
| 43 |
|
|
"%02x\t%-32s\t%-32s\n", which works out to three columns separated by
|
| 44 |
|
|
tabs. Note that this file can be empty, if no devices are found on
|
| 45 |
|
|
the adapter.
|
| 46 |
|
|
|
| 47 |
|
|
The first column contains the (hexadecimal) address of the client. As
|
| 48 |
|
|
only 7-bit addresses are supported at this moment, two digits are
|
| 49 |
|
|
enough.
|
| 50 |
|
|
|
| 51 |
|
|
The second and third column are respectively the client name and the
|
| 52 |
|
|
driver name of this client. Each client is associated with a driver,
|
| 53 |
|
|
and several clients can share the same driver.
|
