1，I2C的总线拓扑
2，I2C S/W topology
linux kernel I2C framework使用如下的软件拓扑抽象I2C硬件（我们可以一起领会一下其中的"设备模型"思想）：
1）platform bus（/sys/bus/platform）是驱动工程师常见的bus，用于挂载和CPU通过系统总线连接的各类外设。在I2C framework中，I2C控制器直接从属于platform bus，我们在linux kernel中常说的I2C driver，都是指I2C controller driver，都是以platform driver的形式存在，当然，对应的控制器是platform device。
2）与此同时，kernel抽象出I2C bus（/sys/bus/i2c），用于挂载和I2C controller通过I2C总线连接的各个I2C slave device。
3）比较特殊的地方是，I2C core使用一个虚拟实体----I2C adapter，抽象I2C controller有关的功能（主要是数据的收发），I2C adapter也挂载在I2C bus上。
4）I2C adapter和I2C slave device都挂载在I2C bus上，就可以方便的进行Master（I2C adapter）和Slave之间的匹配操作，并通过I2C core提供的统一接口，访问I2C salve device，进行数据的收发。
5）以上各实体在sysfs中的位置，已经在"图片2"中通过红色字体标注，大家可自行理解。
3，软件框架
1）I2C framework的最终目标，是提供一种"访问I2C slave devices"的方法。由于这些slave devices由I2C controller控制，因而主要由I2C controller驱动实现这一目标。
2）经过I2C framework的抽象，consumer可以不用关心I2C总线的技术细节，只需要通过简单的API，就可以与slave devices进行数据交互。正常情况下，consumer是位于内核态的其它driver（如HDMI driver、touch screen driver等等）。与此同时，I2C framework也通过字符设备向用户空间提供类似的接口，用户空间程序可以通过该接口访问slave devices。
3）在I2C framework内部，有I2C core、I2C busses、I2C algos和I2C muxes四个模块。
4）I2C core使用I2C adapter和I2C algorithm两个子模块抽象I2C controller的功能，使用I2C client和I2C driver抽象I2C slave device的功能（对应设备模型中的device和device driver）。另外，基于I2C协议，通过smbus模块实现SMBus（System Management Bus，系统管理总线）的功能。
5）I2C busses是各个I2C controller drivers的集合，位于drivers/i2c/busses/目录下，驱动工程师常说的"I2C driver"就是指它们。
6）I2C algos包含了一些通用的I2C algorithm，所谓的algorithm，是指I2C协议包的生成方法，进而组合成I2C的read/write指令，一般情况下，都是由硬件实现，不需要特别关注该目录。
7）I2C muxes用于实现I2C bus的多路复用功能，属于奇葩的冷门功能，暂不过多介绍。
4，源码目录结构
在Linux内核源代码中的drivers目录下有一个i2c目录，而在i2c目录下又包含如下文件和文件夹。
（1）i2c-core.c
这个文件实现了i2c核心的功能以及/proc/bus/i2c*接口。
（2）i2c-dev.c
实现了i2c适配器设备文件的功能，每一个i2c适配器都被分配一个设备。通过适配器访问设备时的主设备号都为89，次设备号为0 ~ 255。应用程序通过"i2c-%d"(i2c-0，i2c-1，... ，i2c-10，...)文件名并使用文件操作接口open()，write()，read(), ioctl()和close()等来访问这个设备。
i2c-dev.c并不是针对特定的设备而设计的，只是提供了通用的read()、write()和ioctl()等接口，应用层可以借用这些接访问挂接在适配器上的i2c设备的存储空间或寄存器，并控制i2c设备的工作方式。
（3）busses文件夹
这个文件夹包含了一些i2c主机控制器驱动，如i2c-tegra.c、i2c-omap.c、i2c-versatile.c、i2c-s3c2410.c等。
（4）algos文件夹
实现了一些i2c总线适配器的通信方法。
5，i2c_adapter/i2c_algorithm/i2c_driver/i2c_client结构体之间的关系
内核中的i2c.h头文件中对i2c_adapter、i2c_algorithm、i2c_driver和i2c_client这4个数据结构进行了定义。他们的定义位于include/linux/i2c.h文件中。
i2c_adapter结构体：
cpp
/*
* i2c_adapter is the structure used to identify a physical i2c bus along
* with the access algorithms necessary to access it.
*/
struct i2c_adapter {
struct module *owner;
unsigned int class; /* classes to allow probing for */
const struct i2c_algorithm *algo; /* the algorithm to access the bus */
void *algo_data;
/* data fields that are valid for all devices */
const struct i2c_lock_operations *lock_ops;
struct rt_mutex bus_lock;
struct rt_mutex mux_lock;
int timeout; /* in jiffies */
int retries;
struct device dev; /* the adapter device */
unsigned long locked_flags; /* owned by the I2C core */
#define I2C_ALF_IS_SUSPENDED 0
#define I2C_ALF_SUSPEND_REPORTED 1
int nr;
char name[48];
struct completion dev_released;
struct mutex userspace_clients_lock;
struct list_head userspace_clients;
struct i2c_bus_recovery_info *bus_recovery_info;
const struct i2c_adapter_quirks *quirks;
struct irq_domain *host_notify_domain;
};
#define to_i2c_adapter(d) container_of(d, struct i2c_adapter, dev)i2c_algorithm结构体：
cpp
/**
* struct i2c_algorithm - represent I2C transfer method
* @master_xfer: Issue a set of i2c transactions to the given I2C adapter
* defined by the msgs array, with num messages available to transfer via
* the adapter specified by adap.
* @master_xfer_atomic: same as @master_xfer. Yet, only using atomic context
* so e.g. PMICs can be accessed very late before shutdown. Optional.
* @smbus_xfer: Issue smbus transactions to the given I2C adapter. If this
* is not present, then the bus layer will try and convert the SMBus calls
* into I2C transfers instead.
* @smbus_xfer_atomic: same as @smbus_xfer. Yet, only using atomic context
* so e.g. PMICs can be accessed very late before shutdown. Optional.
* @functionality: Return the flags that this algorithm/adapter pair supports
* from the ``I2C_FUNC_*`` flags.
* @reg_slave: Register given client to I2C slave mode of this adapter
* @unreg_slave: Unregister given client from I2C slave mode of this adapter
*
* The following structs are for those who like to implement new bus drivers:
* i2c_algorithm is the interface to a class of hardware solutions which can
* be addressed using the same bus algorithms - i.e. bit-banging or the PCF8584
* to name two of the most common.
*
* The return codes from the ``master_xfer{_atomic}`` fields should indicate the
* type of error code that occurred during the transfer, as documented in the
* Kernel Documentation file Documentation/i2c/fault-codes.rst.
*/
struct i2c_algorithm {
/*
* If an adapter algorithm can't do I2C-level access, set master_xfer
* to NULL. If an adapter algorithm can do SMBus access, set
* smbus_xfer. If set to NULL, the SMBus protocol is simulated
* using common I2C messages.
*
* master_xfer should return the number of messages successfully
* processed, or a negative value on error
*/
int (*master_xfer)(struct i2c_adapter *adap, struct i2c_msg *msgs,
int num);
int (*master_xfer_atomic)(struct i2c_adapter *adap,
struct i2c_msg *msgs, int num);
int (*smbus_xfer)(struct i2c_adapter *adap, u16 addr,
unsigned short flags, char read_write,
u8 command, int size, union i2c_smbus_data *data);
int (*smbus_xfer_atomic)(struct i2c_adapter *adap, u16 addr,
unsigned short flags, char read_write,
u8 command, int size, union i2c_smbus_data *data);
/* To determine what the adapter supports */
u32 (*functionality)(struct i2c_adapter *adap);
#if IS_ENABLED(CONFIG_I2C_SLAVE)
int (*reg_slave)(struct i2c_client *client);
int (*unreg_slave)(struct i2c_client *client);
#endif
};i2c_driver结构体：
cpp
/**
* struct i2c_driver - represent an I2C device driver
* @class: What kind of i2c device we instantiate (for detect)
* @probe: Callback for device binding - soon to be deprecated
* @probe_new: New callback for device binding
* @remove: Callback for device unbinding
* @shutdown: Callback for device shutdown
* @alert: Alert callback, for example for the SMBus alert protocol
* @command: Callback for bus-wide signaling (optional)
* @driver: Device driver model driver
* @id_table: List of I2C devices supported by this driver
* @detect: Callback for device detection
* @address_list: The I2C addresses to probe (for detect)
* @clients: List of detected clients we created (for i2c-core use only)
*
* The driver.owner field should be set to the module owner of this driver.
* The driver.name field should be set to the name of this driver.
*
* For automatic device detection, both @detect and @address_list must
* be defined. @class should also be set, otherwise only devices forced
* with module parameters will be created. The detect function must
* fill at least the name field of the i2c_board_info structure it is
* handed upon successful detection, and possibly also the flags field.
*
* If @detect is missing, the driver will still work fine for enumerated
* devices. Detected devices simply won't be supported. This is expected
* for the many I2C/SMBus devices which can't be detected reliably, and
* the ones which can always be enumerated in practice.
*
* The i2c_client structure which is handed to the @detect callback is
* not a real i2c_client. It is initialized just enough so that you can
* call i2c_smbus_read_byte_data and friends on it. Don't do anything
* else with it. In particular, calling dev_dbg and friends on it is
* not allowed.
*/
struct i2c_driver {
unsigned int class;
/* Standard driver model interfaces */
int (*probe)(struct i2c_client *client, const struct i2c_device_id *id);
int (*remove)(struct i2c_client *client);
/* New driver model interface to aid the seamless removal of the
* current probe()'s, more commonly unused than used second parameter.
*/
int (*probe_new)(struct i2c_client *client);
/* driver model interfaces that don't relate to enumeration */
void (*shutdown)(struct i2c_client *client);
/* Alert callback, for example for the SMBus alert protocol.
* The format and meaning of the data value depends on the protocol.
* For the SMBus alert protocol, there is a single bit of data passed
* as the alert response's low bit ("event flag").
* For the SMBus Host Notify protocol, the data corresponds to the
* 16-bit payload data reported by the slave device acting as master.
*/
void (*alert)(struct i2c_client *client, enum i2c_alert_protocol protocol,
unsigned int data);
/* a ioctl like command that can be used to perform specific functions
* with the device.
*/
int (*command)(struct i2c_client *client, unsigned int cmd, void *arg);
struct device_driver driver;
const struct i2c_device_id *id_table;
/* Device detection callback for automatic device creation */
int (*detect)(struct i2c_client *client, struct i2c_board_info *info);
const unsigned short *address_list;
struct list_head clients;
};
#define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)i2c_client结构体：
cpp
/**
* struct i2c_client - represent an I2C slave device
* @flags: see I2C_CLIENT_* for possible flags
* @addr: Address used on the I2C bus connected to the parent adapter.
* @name: Indicates the type of the device, usually a chip name that's
* generic enough to hide second-sourcing and compatible revisions.
* @adapter: manages the bus segment hosting this I2C device
* @dev: Driver model device node for the slave.
* @init_irq: IRQ that was set at initialization
* @irq: indicates the IRQ generated by this device (if any)
* @detected: member of an i2c_driver.clients list or i2c-core's
* userspace_devices list
* @slave_cb: Callback when I2C slave mode of an adapter is used. The adapter
* calls it to pass on slave events to the slave driver.
*
* An i2c_client identifies a single device (i.e. chip) connected to an
* i2c bus. The behaviour exposed to Linux is defined by the driver
* managing the device.
*/
struct i2c_client {
unsigned short flags; /* div., see below */
#define I2C_CLIENT_PEC 0x04 /* Use Packet Error Checking */
#define I2C_CLIENT_TEN 0x10 /* we have a ten bit chip address */
/* Must equal I2C_M_TEN below */
#define I2C_CLIENT_SLAVE 0x20 /* we are the slave */
#define I2C_CLIENT_HOST_NOTIFY 0x40 /* We want to use I2C host notify */
#define I2C_CLIENT_WAKE 0x80 /* for board_info; true iff can wake */
#define I2C_CLIENT_SCCB 0x9000 /* Use Omnivision SCCB protocol */
/* Must match I2C_M_STOP|IGNORE_NAK */
unsigned short addr; /* chip address - NOTE: 7bit */
/* addresses are stored in the */
/* _LOWER_ 7 bits */
char name[I2C_NAME_SIZE];
struct i2c_adapter *adapter; /* the adapter we sit on */
struct device dev; /* the device structure */
int init_irq; /* irq set at initialization */
int irq; /* irq issued by device */
struct list_head detected;
#if IS_ENABLED(CONFIG_I2C_SLAVE)
i2c_slave_cb_t slave_cb; /* callback for slave mode */
#endif
};
#define to_i2c_client(d) container_of(d, struct i2c_client, dev)下面分析i2c_adapter、i2c_algorithm、i2c_driver、i2c_client这4个数据结构的作用及其关系。
（1）i2c_adapter 与 i2c_algorithm
i2c_adapter对应于物理上的一个适配器，而i2c_algorithm对应一套通信方法。一个i2c适配器需要i2c_algorithm提供的通信函数来控制适配器产生特定的访问周期。缺少i2c_algorithm的i2c_adapter什么也做不了，因此i2c_adapter中包含所使用的i2c_algorithm的指针。
i2c_algorithm中的关键函数是master_xfer()用于产生i2c访问周期需要的信号，以i2c_msg（即i2c消息）为单位。i2c_msg结构体也非常重要，它定义于include/uapi/linux/i2c.h（在uapi目录下，证明用户空间也可能使用这个结构体）中该结构体的成员表明了i2c的传输地址、方向、缓冲区、缓冲区长度等信息。
i2c_msg结构体的定义：
cpp
/**
* struct i2c_msg - an I2C transaction segment beginning with START
* @addr: Slave address, either seven or ten bits. When this is a ten
* bit address, I2C_M_TEN must be set in @flags and the adapter
* must support I2C_FUNC_10BIT_ADDR.
* @flags: I2C_M_RD is handled by all adapters. No other flags may be
* provided unless the adapter exported the relevant I2C_FUNC_*
* flags through i2c_check_functionality().
* @len: Number of data bytes in @buf being read from or written to the
* I2C slave address. For read transactions where I2C_M_RECV_LEN
* is set, the caller guarantees that this buffer can hold up to
* 32 bytes in addition to the initial length byte sent by the
* slave (plus, if used, the SMBus PEC); and this value will be
* incremented by the number of block data bytes received.
* @buf: The buffer into which data is read, or from which it's written.
*
* An i2c_msg is the low level representation of one segment of an I2C
* transaction. It is visible to drivers in the @i2c_transfer() procedure,
* to userspace from i2c-dev, and to I2C adapter drivers through the
* @i2c_adapter.@master_xfer() method.
*
* Except when I2C "protocol mangling" is used, all I2C adapters implement
* the standard rules for I2C transactions. Each transaction begins with a
* START. That is followed by the slave address, and a bit encoding read
* versus write. Then follow all the data bytes, possibly including a byte
* with SMBus PEC. The transfer terminates with a NAK, or when all those
* bytes have been transferred and ACKed. If this is the last message in a
* group, it is followed by a STOP. Otherwise it is followed by the next
* @i2c_msg transaction segment, beginning with a (repeated) START.
*
* Alternatively, when the adapter supports I2C_FUNC_PROTOCOL_MANGLING then
* passing certain @flags may have changed those standard protocol behaviors.
* Those flags are only for use with broken/nonconforming slaves, and with
* adapters which are known to support the specific mangling options they
* need (one or more of IGNORE_NAK, NO_RD_ACK, NOSTART, and REV_DIR_ADDR).
*/
struct i2c_msg {
__u16 addr; /* slave address */
__u16 flags;
#define I2C_M_RD 0x0001 /* read data, from slave to master */
/* I2C_M_RD is guaranteed to be 0x0001! */
#define I2C_M_TEN 0x0010 /* this is a ten bit chip address */
#define I2C_M_DMA_SAFE 0x0200 /* the buffer of this message is DMA safe */
/* makes only sense in kernelspace */
/* userspace buffers are copied anyway */
#define I2C_M_RECV_LEN 0x0400 /* length will be first received byte */
#define I2C_M_NO_RD_ACK 0x0800 /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_IGNORE_NAK 0x1000 /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_REV_DIR_ADDR 0x2000 /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_NOSTART 0x4000 /* if I2C_FUNC_NOSTART */
#define I2C_M_STOP 0x8000 /* if I2C_FUNC_PROTOCOL_MANGLING */
__u16 len; /* msg length */
__u8 *buf; /* pointer to msg data */
};（2）i2c_driver与i2c_client
i2c_driver对应于一套驱动方法，其主要成员函数是probe()、remove()、suspend()、resume()等，另外，struct i2c_device_id形式的id_table是该驱动所支持的i2c设备的ID表。i2c_client对应于真实的物理设备，每个i2c设备都需要一个i2c_client来描述。i2c_driver与i2c_client的关系是一对多，一个i2c_driver可以支持多个同类型的i2c_client。
（3）i2c_adapter 与 i2c_client
i2c_adapter 与 i2c_client的关系与i2c硬件体系中适配器和设备的关系一致，即i2c_client依附于i2c_adapter。由于一个适配器可以连接多个i2c设备，所以一个i2c_adapter也可以被多个i2c_client依附，i2c_adapter中包括依附于它的i2c_client的链表。
I2C驱动的各种数据结构的关系：
6，编写I2C驱动需要完成的工作
一方面，适配器驱动可能是Linux内核还不包含的；另一方面，挂接在适配器上的具体的设备驱动可能也是Linux内核还不包含的。因此，工程师需要实现的主要工作如下：
（1）提供I2C适配器的硬件驱动，探测、初始化I2C适配器（如申请I2C的I/O地址和中断号）、驱动CPU控制的I2C适配器从硬件上产生各种信号以及处理I2C中断等。
（2）提供I2C适配器的algorithm，用具体适配器的xxx_xfer()函数填充i2c_algorithm的master_xfer指针，并把i2c_algorithm指针赋值给i2c_adapter的algo指针。
（3）实现I2C设备驱动中的i2c_driver接口，用具体设备yyy的yyy_probe()、yyy_remove()、yyy_suspend()、yyy_resume()函数指针和i2c_device_id设备ID表赋值给i2c_driver的probe、remove、suspend、resume和id_table指针。
（4）实现i2c设备所对应类型的具体驱动，i2c_driver只是实现设备与总线的挂接，而挂接在总线上的设备则千差万别。例如，如果是字符设备，就实现文件操作接口，即实现具体设备的yyy_read()、yyy_write()和yyy_ioctl()函数等；如果是声卡，就实现ALSA驱动。
上述前两个属于I2C总线驱动，后两个属于I2C设备驱动。
参考链接：
<<Linux设备驱动开发详解>>