原文地址：https://blog.csdn.net/qq_28992301/article/details/53321610
设备树详解
在Linux3.x版本后，arch/arm/plat-xxx和arch/arm/mach-xxx中，描述板级细节的代码（比如platform_device、i2c_board_info等）被大量取消，取而代之的是设备树，其目录位于arch/arm/boot/dts
1.设备树的组成
1个dts文件+n个dtsi文件，它们编译而成的dtb文件就是真正的设备树
- soc厂商会把soc公共的特性和多块开发板公用的特性提炼为dtsi，而dts则负责描述某个具体的产品（开发板）的特性。dts直接或间接的包含多个dtsi（类似于c语言的头文件），就体现了一个完整的产品（开发板）所有的特性。以solidrun公司的hummingboard为例，其组成为
imx6dl-hummingboard.dts
|_imx6dl.dtsi
| |_imx6qdl.dtsi
|_imx6qdl-microsom.dtsi
|_imx6qdl-microsom-ar8035.dtsi
- 此外，dts/dtsi兼容c语言的一些语法，能使用宏定义，也能包含.h文件
2.设备树的结构
下面分别是是imx6dl-hummingboard.dts以及imx6dl.dtsi文件，我们以它们为例来分析，不难发现dts文件内容很少，只有一些板级的特征，大部分公共的硬件描述都在dtsi文件中
- imx6dl-hummingboard.dts 文件节选
/dts-v1/;
#include "imx6dl.dtsi"
#include "imx6qdl-microsom.dtsi"
#include "imx6qdl-microsom-ar8035.dtsi"
/ {
model = "SolidRun HummingBoard DL/Solo";
compatible = "solidrun,hummingboard", "fsl,imx6dl";
ir_recv: ir-receiver {
compatible = "gpio-ir-receiver";
gpios = <&gpio1 2 1>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard_gpio1_2>;
};
regulators {
compatible = "simple-bus";
reg_3p3v: 3p3v {
compatible = "regulator-fixed";
regulator-name = "3P3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
}
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_hummingboard_i2c1>;
rtc: pcf8523@68 {
compatible = "nxp,pcf8523";
reg = <0x68>;
};
};
- imx6dl.dtsi文件节选
/ {
aliases {
/*省略无关代码*/
}
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
interrupt-parent = <&intc>;
ranges;
/*省略无关代码*/
timer@00a00600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x00a00600 0x20>;
interrupts = <1 13 0xf01>;
clocks = <&clks IMX6QDL_CLK_TWD>;
};
aips-bus@02000000 { /* AIPS1 */
compatible = "fsl,aips-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x02000000 0x100000>;
ranges;
/*省略无关代码*/
gpio1: gpio@0209c000 {
compatible = "fsl,imx6q-gpio", "fsl,imx35-gpio";
reg = <0x0209c000 0x4000>;
interrupts = <0 66 IRQ_TYPE_LEVEL_HIGH>,
<0 67 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
/*省略无关代码*/
i2c1: i2c@021a0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,imx6q-i2c", "fsl,imx21-i2c";
reg = <0x021a0000 0x4000>;
interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_I2C1>;
status = "disabled";
};
};
/*省略无关代码*/
};
};
基本构造
- {}包围起来的结构称之为节点，dts中最开头的
/ {}，称为根节点。节点的标准结构是xxx@yyy{…}，xxx是节点的名字，yyy则不是必须的，其值为节点的地址（寄存器地址或其他地址），比如i2c1: i2c@021a0000中的就是一个i2c控制器的寄存器基地址，rtc: pcf8523@68中的就是这个rtc设备的i2c地址
属性：地址
- 有关节点的地址，比如
i2c@021a0000，虽然它在名字后面跟了地址，但是正式的设置是在reg属性中设置的比如：reg = <0x021a0000 0x4000>; reg的格式通常为<address length>，0x021a0000是寄存器基地址，0x4000是长度。address 和length的个数是可变的，由父节点的属性#address-cells和#size-cells决定，比如节点i2c@021a0000的父节点是aips-bus@02000000，其#address-cells和#size-cells均为1，所以下面的i2c节点的reg属性就有一个address 和length，而i2c节点本身#address-cells和#size-cells分别为1和0，所以其下的rtc: pcf8523@68的reg属性就只有一个0x68（i2c地址）了
属性：兼容性
- 如果一个节点是设备节点，那么它一定要有compatible（兼容性），因为这将作为驱动和设备（设备节点）的匹配依据，compatible（兼容性）的值可以有不止一个字符串以满足不同的需求，详见下一节。而根节点的compatible也是非常重要的，也就是
"fsl,imx6dl"这个字符串，因为系统启动后，将根据根节点的compatible来判断cpu信息，并由此进行初始化
属性设置的套路
- 一般来说，每一种设备的节点属性设置都会有一些套路，比如可以设置哪些属性？属性值怎么设置？那怎么知道这些套路呢，有两种思路
- 第一种是抄类似的dts，比如我们自己项目的平台是4412，那么就可以抄exynos4412-tiny4412.dts、exynos4412-smdk4412.dts这类相近的dts
- 第二种是查询内核中的文档，比如Documentation/devicetree/bindings/i2c/i2c-imx.txt就描述了imx平台的i2c属性设置方法；Documentation/devicetree/bindings/fb就描述了lcd、lvds这类属性设置方法
节点之间的联系
- 节点与节点之间的关联，通常通过“标号引用”和“包含”来实现
- 所谓标号引用，就是在节点名称前加上标号，这样设备树的其他位置就能够通过&符号来调用/访问该节点，比如上面代码ir_recv节点中的gpio属性，就引用了gpio1标号处的节点
- 包含则是最基本的方式，比如我们要在i2c1接口添加一个i2c外设，那么就必须要在i2c1下面添加一个节点，比如上面代码中的
rtc: pcf8523@68 {}
- 标号引用常常还作为节点的重写方式，比如下面代码是imx6qdl.dtsi中定义的i2c节点，而前面imx6dl-hummingboard.dts中的&i2c1，就是对i2c1标号处节点的一次重写，在其内部添加了一个rtc设备
- 如果一个节点是属性节点（即仅仅是作为属性被其他节点调用），那么它定义在哪里其实无所谓，重要的是调用的位置，比如lcd屏幕的时序，其实我们完全可以把它定义在其他犄角旮旯，然后在lcd节点下用&来调用它，这也是可以的。这有点类似于函数：在哪定义不重要，重要的是在哪调用
3.内核（驱动）与节点的匹配
首先，内核必须要知道dtb文件的地址，这由U-boot来告诉内核，详见U-boot引导内核流程分析 第6节。只要内核知晓了dtb文件的地址，那么驱动就可以通过一些API任意获取设备树的内部信息
- 对于3.x版本之后的内核，platform、i2c、spi等设备不再需要在mach-xxx中注册，驱动程序将直接和设备树里的设备节点进行配对，是通过设备节点中的compatible（兼容性）来与设备节点进行配对的，这里只做简单介绍，具体的应用详见 基于i2c子系统的驱动分析、 基于platform总线的驱动分析
- 这里以pcf8523驱动为例，只要驱动中的of_match_table 中的compatible 值和设备节点中的compatible 相匹配，那么probe函数就会被触发。不仅i2c是这样，platform、spi等都是这个原理
/*定义的of_match_table*/
static const struct of_device_id pcf8523_of_match[] = {
{ .compatible = "nxp,pcf8523" },
{ }
};
/*driver 结构体中的of_match_table*/
static struct i2c_driver pcf8523_driver = {
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(pcf8523_of_match),
},
.probe = pcf8523_probe,
.id_table = pcf8523_id,
};
2683
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
