i2c驱动如何通过设备树注册sysbusi2cdrivers下的设备名

i2c驱动通过设备树注册sys/bus/i2c/drivers下的设备名的方法如下

在没有出现dts之前，linux会将一些板级信息写在arch/arm下和你的板所匹配的c文件里，一般定义一个struct i2c_board_info结构体，将i2c的地址以及i2c的名称信息写入到此结构体中。

在出现了dts之后，为了去耦合，将这些的板级信息全部都定义在设备树中，在移植的时候只要修改设备树的硬件信息即可，设备树信息位于arch/arm/boots/dts中，以i2c设备为例。

将硬件设备添加到设备链表之后，现在就分析内核是怎么向i2c总线动态注册这些设备的。

Linux and the Device Tree

Linux内核设备树数据使用模型。

Open Firmware Device Tree (DT) 是一个数据结构，也是一种描述硬件的语言。准确地说，它是一种能被 *** 作系统解析的描述硬件的语言，这样 *** 作系统就不需要把硬件平台的细节在代码中写死。

从结构上来说，DT是一个树形结构，或者有名结点组成的非循环图，结点可能包含任意数量的有名属性，有名属性又可以包含任意数量的数据。同样存在一种机制，可以创建从一个结点到正常树形结构之外的链接。

从概念上讲，一套通用的使用方法，即bindings。Bindings定义了数据如何呈现在设备树中，怎样描述典型的硬件特性，包括数据总线，中断线，GPIO连接以及外设等。

尽可能多的硬件被描述从而使得已经存在的bindings最大化地使用源代码，但是由于属性名和结点名是简单字符串， 可以通过定义新结点和属性的方式很方便地扩展已经存在的bindings或者创建一个新的binding。在没有认真了解过已经存在的bindings的情况下，创建一个新的binding要慎之又慎。对于I2C总线，通常有两种不同的，互不相容的bindings出现，就是因为新的binding创建时没有研究I2C设备是如何在当前系统中被枚举的。

1. 历史

略

2. 数据模型

请参考Device Tree Usage章节

2.1 High Level View

必须要认识到的是，DT是一个描述硬件的数据结构。它并没有什么神奇的地方，也不能把所有硬件配置的问题都解决掉。它只是提供了一种语言，将硬件配置从Linux Kernel支持的board and device driver中提取出来。DT使得board和device变成数据驱动的，它们必须基于传递给内核的数据进行初始化，而不是像以前一样采用hard coded的方式。

观念上说，数据驱动平台初始化可以带来较少的代码重复率，使得单个内核映像能够支持很多硬件平台。

Linux使用DT的三个主要原因：

1） 平台识别 (Platform Identification)

2） 实时配置 (Runtime Configuration)

3） 设备植入 (Device Population)

2.2 平台识别

第一且最重要的是，内核使用DT中的数据去识别特定机器。最完美的情况是，内核应该与特定硬件平台无关，因为所有硬件平台的细节都由设备树来描述。然而，硬件平台并不是完美的，所以内核必须在早期初始化阶段识别机器，这样内核才有机会运行特定机器相关的初始化序列。

大多数情况下，机器识别是与设备树无关的，内核通过机器的核心CPU或者SOC来选择初始化代码。以ARM平台为例，setup_arch()会调用setup_machine_fdt()，后者遍历machine_desc链表，选择最匹配设备树数据的machine_desc结构体。它是通过查找设备树根结点的compatible属性并与machine_desc->dt_compat进行比较来决定哪一个machine_desc结构体是最适合的。

Compatible属性包含一个有序的字符串列表，它以确切的机器名开始，紧跟着一个可选的board列表，从最匹配到其他匹配类型。以TI BeagleBoard的compatible属性为例，BeagleBoard xM Board可能描述如下：

compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3"

compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3"

在这里，”ti, omap3-beagleboard-xm”是最匹配的模型，"ti,omap3450"次之，"ti,omap3"再次之。

机敏的读者可能指出，Beagle xM也可以声明匹配"ti,omap3-beagleboard"，但是要注意的是，板级层次上，两个机器之间的变化比较大，很难确定是否兼容。从顶层上来看，宁可小心也不要去声明一个board兼容另外一个。值得注意的情况是，当一个board承载另外一个，例如一个CPU附加在一个board上。（两种CPU支持同一个board的情况）

假设手上有一块从淘宝上买来的开发板，我要在开发板的I2C总线上增加一个从设备（如at24c08），那么我要怎样写这个“I2C设备驱动”，让

应用程序可以访问at24c08呢?

先来看一个最简单的i2c设备驱动：

static struct i2c_board_info at24cxx_info = { //所支持的i2c设备的列表

I2C_BOARD_INFO("at24c08", 0x50), //一项代表一个支持的设备，它的名字叫做“at24c08”，器件地址是0x50

}

static struct i2c_client *at24cxx_client

static int at24cxx_dev_init(void)

{

struct i2c_adapter *i2c_adap //分配一个适配器的指针

i2c_adap = i2c_get_adapter(0) //调用core层的函数，获得一个i2c总线。这里我们已经知道新增的器件挂接在编号为0的i2c总线上

at24cxx_client = i2c_new_device(i2c_adap, &at24cxx_info) // 把i2c适配器和新增的I2C器件关联起来，这个用了i2c总线0，地址是0x50。这就组成了一个客户端

at24cxx_client i2c_put_adapter(i2c_adap)

return 0

}

static void at24cxx_dev_exit(void)

{

i2c_unregister_device(at24cxx_client)

}

module_init(at24cxx_dev_init)

module_exit(at24cxx_dev_exit)

从上面的程序可以看到，写一个i2c设备驱动程序，与写普通的字符驱动基本一样。特别之处是它调用了i2c的core层的函数，以获得对i2c总线的控制。因为用的是开发板，板上的与soc芯片（一般来说就是arm的芯片）i2c总线驱动一般都做好了，直接调用core层的函数就可以控制soc的i2c模块了。也就是说，写i2c设备驱动不需要关注arm内部的i2c模块的寄存器，我们需要关注的是设备(at24c08)的寄存器以及它的datasheet对时序的要求。

其实，添加i2c设备的方法很灵活。根据Linux的官方文档《linux-3.4.2\Documentation\i2c\instantiating-devices》，添加i2c设备的方法总结有4种：

1. i2c_register_board_info：根据总线编号、设备名字（“at24c08”）、设备地址（0x50）注册一个字符驱动。这种方法最简单、最粗暴，最贴近平时在开片机上开发i2c器件的。

2. i2c_new_device：根据i2c总线的编号，声明一个i2c设备：这种方法就是上面例子用的方法。这种方法也简单，但是需要事先知道器件挂接在哪条总线上。对于设备，还实现知道了设备地址0x50，总线适配器也支持名字为“at24c08”的设备

3. i2c_new_probed_device：

4.从用户空间实例化一个器件：这个方法相当智能快速，如下输入指令，即可增加一个i2c设备，同时增加了对应的设备文件。

# echo eeprom 0x50 >/sys/bus/i2c/devices/i2c-3/new_device

根据英文文档的标题，添加i2c设备有称之为“i2c设备的实例化”。

从上述可以知道，在实例化一个i2c设备之前，除了有对应的驱动支持总线外（这里是总线0），还需要有一个驱动使用了总线0发送时序，支持名字为"at24c08"的器件。这个驱动用总线驱动的函数，配置了at24c08的寄存器。

---