i2c设备驱动的来龙去脉

一个i2c设备驱动的实现过程：

１首先在设备树中配置，将设备挂载i2c总线的设备树节点上,如下图中的my_i2c＠68节点：

２那么设备树配置好了，接下来就该开始写我们的设备驱动了，第一步该干什么呢，首先你得实例化一个i2c_driver驱动对象，如下：

1. staticstruct i2c_driver my_i2c_client_driver={
2. .driver={
3. .name="my_i2c",
4. .owner= THIS_MODULE,
5. .of_match_table= my_i2c_client_match_table,
6. },
7. .id_table= my_i2c_client_id,
8. .probe= my_i2c_client_probe,
9. .remove= my_i2c_client_remove,
10. };

这个driver中有一个of_match_table,还有一个id_table，到底他们有什么用，是不是必须的后面会讲到，先来看看他们长什么样子

1. staticconststruct i2c_device_id my_i2c_client_id[]={
2. {"my_i2c",0},
3. {}
4. };
5. staticstruct of_device_id my_i2c_client_match_table[]={
6. {.compatible="my_i2c",},
7. {},
8. };

从上面的类图可以看到，i2c_driver其实相当于继承于device_driver,其中这个of_match_table是device_driver的成员，在设备与驱动的匹配过程中，优先级高于i2c_driver的id_table,什么意思呢，后面慢慢讲，先还是来看创建一个简单的i2c设备驱动的过程吧！

３i2c_driver对象实例话之后，就需要填充这个对象的proble,remove等函数了，probe函数会在设备与驱动匹配成功后调用，remove函数会在设备卸载后调用。这两个函数实现好以后，接下来将这个driver注册进系统就好了，注册代码如下

1. module_i2c_driver(my_i2c_client_driver);

这样一个简单的i2c设备驱动的框架就搭建好了

那下面来具体分析一下我们所关注的问题吧，这个of_match_table 和id_table有什么用，在什么时候用，缺一不可吗？

在匹配设备的时候，系统会首先会检查是调用of_driver_match_device,检查of_match_table中是否包含该设备，包含就匹配成功直接返回，如果匹配失败后，会继续检查id_table,如果包含该设备，就匹配成功并返回，否则匹配失败，返回－ENODEV

到这大家是不是觉得两个table有其中任何一个都可以保证匹配成功呀，答案是肯定的，就匹配过程而言，两个table描述其中一个都能导致匹配成功，但是你会发现，缺少id_table的时候你写的设备驱动程序的probe不会调用，这是为什么呢，下面我们来看一下匹配过程牛逼的时序图

从上图可以看出来，要想自己的驱动的probe能被调用，必须要配置id_table,如果不配置id_table,在i2c_device_probe中发现没有id_table，直接就返回了，到这是不是豁然开朗了呢！

那么接下来大家肯定会疑惑，到底什么时候系统会调用这个match过程，那我们就从我们的驱动程序注册开始说起，让大家了解整个来龙去脉！

老样子，还是先看牛逼的时序图

从途中可以看到，match实在注册到总线的过程中去调用的。

driver注册成功以后，系统会遍历总线上说有的adapter,并检测总线上支持的设备，并去实例化这些设备的adapter，并做填充，如果向我们前面的一样通过设备树的方式配置过了，这个检测直接返回成功，因为client与adapter的绑定过程在解析设备树之后就已经绑定。

那么这个i2c_client是在哪个阶段创建的呢，在设备树或者i2c_board_info中配置以后，系统会调用i2c_new_device创建i2c_client,如果知道这个设备链接在i2c总线上，但是又不知道这个设备的地址，会调用i2c_new_probed_device创建。

写到这，大家是不是对i2c设备驱动的整个来龙去脉都了解的差不多了呢。