LinuxI2C几个结构体间的关系以及对于一个I2C设备的移植，我们需要做些什么工作

在Linux内核源代码中的drivers目录下包含一个i2c目录，而在i2c目录下又包含如下文件和文件夹：
•  i2c-core.c
这个文件实现了I2C核心的功能以及/proc/bus/i2c*接口。
•  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设备的工作方式。
•  chips文件夹
这个目录中包含了一些特定的I2C设备驱动，如Dallas公司的DS1337实时钟芯片、EPSON公司的RTC8564实时钟芯片和I2C接口的EEPROM驱动等。
•  busses文件夹
这个文件中包含了一些I2C总线的驱动，如S3C2410的I2C控制器驱动为i2c-s3c2410.c。
•  algos文件夹
实现了一些I2C总线适配器的algorithm。
此外，内核中的i2c.h这个头文件对i2c_driver、i2c_client、i2c_adapter和i2c_algorithm这4个数据结构进行了定义。理解这4个结构体的作用十分关键，代码清单15.1、15.2、15.3、15.4分别给出了它们的定义。
代码清单15.1 i2c_adapter结构体
1  struct i2c_adapter {
2   struct module *owner;/*所属模块*/
3  unsigned int id;   /*algorithm的类型，定义于i2c-id.h，以I2C_ALGO_开始*/
4  unsigned int class;
5  struct i2c_algorithm *algo;/*总线通信方法结构体指针 */
6  void *algo_data; /* algorithm数据 */
7  int (*client_register)(struct i2c_client *);  /*client注册时调用*/
8  int (*client_unregister)(struct i2c_client *); /*client注销时调用*/
9  struct semaphore bus_lock;    /*控制并发访问的自旋锁*/
10 struct semaphore clist_lock;
11 int timeout;
12 int retries;    /*重试次数*/
13 struct device dev;  /* 适配器设备 */
14 struct class_device class_dev; /* 类设备 */
15 int nr;
16 struct list_head clients;  /* client链表头*/
17 struct list_head list;
18 char name[I2C_NAME_SIZE];  /*适配器名称*/
19 struct completion dev_released;    /*用于同步*/
20 struct completion class_dev_released;
21};
代码清单15.2 i2c_algorithm结构体
1  struct i2c_algorithm {
2   int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg *msgs, 
3                      int num);  /*i2c传输函数指针*/
4   int (*smbus_xfer) (struct i2c_adapter *adap, u16 addr,   /*smbus传输函数指针*/
5                      unsigned short flags, char read_write,
6                      u8 command, int size, union i2c_smbus_data * data);
7   int (*slave_send)(struct i2c_adapter *,char*,int);/*当i2c适配器为slave时，发送函数*/
8   int (*slave_recv)(struct i2c_adapter *,char*,int); /*当i2c适配器为slave时，接收函数*/
9   int (*algo_control)(struct i2c_adapter *, unsigned int, unsigned long); /*类似ioctl*/
10  u32 (*functionality) (struct i2c_adapter *);/*返回适配器支持的功能*/
11 };
上述代码第4行对应为SMBus传输函数指针，SMBus大部分基于I2C总线规范，SMBus不需增加额外引脚。与I2C总线相比，SMBus增加了一些新的功能特性，在访问时序也有一定的差异。
代码清单15.3 i2c_driver结构体
1  struct i2c_driver {
2   int id;
3   unsigned int class;
4   int (*attach_adapter)(struct i2c_adapter *); /*依附i2c_adapter函数指针 */
5   int (*detach_adapter)(struct i2c_adapter *); /*脱离i2c_adapter函数指针*/
6   int (*detach_client)(struct i2c_client *);  /*i2c client脱离函数指针*/
7   int (*command)(struct i2c_client *client,unsigned int cmd, void *arg); /*类似ioctl*/
8   struct device_driver driver;    /*设备驱动结构体*/
9   struct list_head list;         /*链表头*/
10 };
代码清单15.4 i2c_client结构体
1  struct i2c_client {
2   unsigned int flags;  /* 标志 */
3   unsigned short addr;     /* 低7位为芯片地址 */
4   struct i2c_adapter *adapter; /*依附的i2c_adapter*/
5   struct i2c_driver *driver;    /*依附的i2c_driver */
6   int usage_count;     /* 访问计数  */
7   struct device dev;     /* 设备结构体 */
8   struct list_head list;       /* 链表头 */ 
9   char name[I2C_NAME_SIZE]; /* 设备名称 */
10  struct completion released;   /* 用于同步 */
11 };
下面分析一下i2c_driver、i2c_client、i2c_adapter和i2c_algorithm这4个数据结构的作用及其盘根错节的关系。
•  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结构体也非常关键，代码清单15.5给出了它的定义。
代码清单15.5 i2c_msg结构体
1 struct i2c_msg {
2  __u16 addr; /* 设备地址*/
3   __u16 flags; /* 标志 */ 
4   __u16 len;  /* 消息长度*/
5   __u8 *buf;  /* 消息数据*/
6 };
•  i2c_driver与i2c_client
i2c_driver对应一套驱动方法，是纯粹的用于辅助作用的数据结构，它不对应于任何的物理实体。i2c_client对应于真实的物理设备，每个I2C设备都需要一个i2c_client来描述。i2c_client一般被包含在i2c字符设备的私有信息结构体中。
i2c_driver 与i2c_client发生关联的时刻在i2c_driver的attach_adapter()函数被运行时。attach_adapter()会探测 物理设备，当确定一个client存在时，把该client使用的i2c_client数据结构的adapter指针指向对应的i2c_adapter， driver指针指向该i2c_driver，并会调用i2c_adapter的client_register()函数。相反的过程发生在 i2c_driver 的detach_client()函数被调用的时候。
•  i2c_adpater与i2c_client
i2c_adpater 与i2c_client的关系与I2C硬件体系中适配器和设备的关系一致，即i2c_client依附于i2c_adpater。由于一个适配器上可以连 接多个I2C设备，所以一个i2c_adpater也可以被多个i2c_client依附，i2c_adpater中包括依附于它的i2c_client 的链表。
假设I2C总线适配器xxx上有两个使用相同驱动程序的yyy I2C设备，在打开该I2C总线的设备结点后相关数据结构之间的逻辑组织关系将如图15.2所示。
  图15.2 I²C驱动各数据结构关系    从上面的分析可知，虽然I2C硬件体系结构比较简单，但是I2C体系结构在Linux中的实现却相当复杂。当工程师拿到实际的电路板，面对复杂的 Linux I2C子系统，应该如何下手写驱动呢？究竟有哪些是需要亲自做的，哪些是内核已经提供的呢？理清这个问题非常有意义，可以使我们面对具体问题时迅速地抓住 重点。
一方面，适配器驱动可能是Linux内核本身还不包含的。另一方面，挂接在适配器上的具体设备驱动可能也是Linux不存在的。即便上述设备驱动都存在于Linux内核中，其基于的平台也可能与我们的电路板不一样。因此，工程师要实现的主要工作将包括：
•  提供I2C适配器的硬件驱动，探测、初始化I2C适配器（如申请I2C的I/O地址和中断号）、驱动CPU控制的I2C适配器从硬件上产生各种信号以及处理I2C中断等。
•  提供I2C适配器的algorithm，用具体适配器的xxx_xfer()函数填充i2c_algorithm的master_xfer指针，并把i2c_algorithm指针赋值给i2c_adapter的algo指针。
•  实现I2C设备驱动与i2c_driver接口，用具体设备yyy的yyy_attach_adapter()函数指针、 yyy_detach_client()函数指针和yyy_command()函数指针的赋值给i2c_driver的attach_adapter、 detach_adapter和detach_client指针。
•  实现I2C设备驱动的文件操作接口，即实现具体设备yyy的yyy_read()、yyy_write()和yyy_ioctl()函数等。
上述工作中1、2属于I2C总线驱动，3、4属于I2C设备驱动，做完这些工作，系统会增加两个内核模块。本章第3～4节将详细分析这些工作的实施方法，给出设计模板，而5~6节将给出两个具体的实例。