I2C驱动的4个数据结构间的关系
一、i2c_driver, i2c_client, i2c_adapter, i2c_algorithm 这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为单位。
/**
* 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_TEN 0x0010 /* this is a ten bit chip address */
#define I2C_M_RD 0x0001 /* read data, from slave to master */
#define I2C_M_NOSTART 0x4000 /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_REV_DIR_ADDR 0x2000 /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_IGNORE_NAK 0x1000 /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_NO_RD_ACK 0x0800 /* if I2C_FUNC_PROTOCOL_MANGLING */
#define I2C_M_RECV_LEN 0x0400 /* length will be first received byte */
__u16 len; /* msg length */
__u8 *buf; /* pointer to msg data */ //消息数据
};
2. i2c_driver and i2c_client.
i2c_driver是一套驱动方法，用于辅助作用的数据结构，不对应任何物理实体。
i2c_client对应真实的物理设备，每个I2C设备都需要一个i2c_client来描述。
i2c_client一般被包含在I2C字符设备的私有信息结构体中,private_data.
i2c_driver的attach_adapter()函数被运行时，i2c_adapter()会探测物理设备，当确定一个client存在时，把该client使用的i2c_client数据结构的adapter指针指向对应的i2c_adapter, driver指针指向i2c_driver,并会调用i2c_adapter的client_register()函数。
相反的过程发生在i2c_driver的detach_client()函数被调用的时候。
3.i2c_adapter 与 i2c_client
i2c_adapter 与 i2c_client 关系相当于适配器和设备的关系，i2c_client 依附于 i2c_adapter.
一个适配器可以连接多个I2C设备，所以一个 i2c_adapter 可以被多个 i2c_client 依附。
i2c_adapter 中有依附于它的 i2c_client 的链表。
二、I2C模块中工程师需要实现的工作：
1. 写I2C适配器的驱动： 探测、初始化I2C适配器（如申请I2C的I/O地址，中断号）、驱动I2C适配器在硬件上产生各种信号，及处理I2C中断等。
2. 写I2C适配器的algorithm：用具体适配器的xxx_xfer函数填充i2c_algorithm的master_xfer指针，并把i2c_algorithm指针赋值给i2c_adapter的algo指针。
3. 写I2C设备驱动：实现I2C设备驱动与i2c_driver的接口，用具体设备yyy的yyy_attach_adapter()函数指针，yyy_detach_client()函数指针，和yyy_commond()函数指针，赋值给i2c_driver的attach_adater,detach_adapter,和detach_client指针。
4.实现I2C设备驱动的文件操作接口: 即实现具体设备yyy的 yyy_read(),yyy_write(),yyy_ioctl().
前两个工作属于I2C总线驱动，后两个属于I2C设备驱动。
来源：http://blog.chinaunix.net/space.php?uid=20748774&do=blog&id=1747412