Linux学习_设备树

• 总结三种写驱动的方法
• • 资源和驱动在同一个文件里
  • 资源用 platform_device 指定、驱动在 platform_driver 实现
  • 资源用设备树指定驱动在 platform_driver 实现
• 设备树的语法
• • 实际使用时，include模板+小改
  • 常用属性
  • • #address-cells、#size-cells、reg
    • compatible
    • model
    • status
    • name、device_type
• 内核对设备树的处理
• • dts->dtb
  • dtb->device_node
  • device_node->platform_device
• platform_device 与 platform_driver 配对
• 11.7中有一堆操作设备树的函数，可以当词典用

总结三种写驱动的方法

资源和驱动在同一个文件里

这是最简单无脑，但也是代码复用性最差的方法

资源用 platform_device 指定、驱动在 platform_driver 实现

分别在xxx_dev.c和xxx_drv.c中定义一个platform_device结构体和platform_driver结构体，如下
描述了单板设备资源的dev结构体：

static struct platform_device board_A_led_dev = {
        .name = "100ask_led",
        .num_resources = ARRAY_SIZE(resources),
        .resource = resources,
        .dev = {
                .release = led_dev_release,
         },
};

和描述了芯片驱动的driver结构体

static struct platform_driver chip_demo_gpio_driver = {
    .probe      = chip_demo_gpio_probe,
    .remove     = chip_demo_gpio_remove,
    .driver     = {
        .name   = "100ask_led",
    },
};

资源用设备树指定驱动在 platform_driver 实现

由于把所有的dev.c都堆积在内核中太过于臃肿，推出了设备树来描述单板的设备情况。
dts文件存储在单板的ROM里，使用时通过bootbolader被加载到内核，这样内核就可以通过解析设备树来让驱动去控制实际的硬件了。

设备树的语法

设备树之所以称之为“树”，就是因为其整体类似于树的结构，其构建方式更为简洁，语法非常之简单

/表示设备树的根，子节点也可以在自己的定义中再改属性，没写的默认继承父节点的属性，对应的写法如下：

/dts-v1/;                      表示版本

/{
	model="fsl,mpc8572ds"
	compatible="fsl,mpc8572ds"
	#address-cells=<1>
	#size-cells=<1>
	
	cpus{
		#address-cells=<1>
		#size-cells=<0>
		cpu@0(
			device_type="cpu"
			reg=<0>
			timebase-frequency=<825000000>
			clock-frequency=<825000000>
		};

		cpu@0(
			device_type="cpu"
			reg=<1>
			timebase-frequency=<825000000>
			clock-frequency=<825000000>
		};
	};

	memory@0{                      根节点以外调用时，需要全路径&{/uart@fe001000}来索引
		device_type="memory"
		reg=<0 0x20000000>
	};
	
	uart@fe001000{                 也可以写成uart0: uart@fe001000，这样在根节点以外就可以使用&uart0来索引
		compatible="ns16550"
		reg=<0xfe001000 ox100>
	};
};	

dts的总体代码书写大概如上

实际使用时，include模板+小改

设备树文件大部分都不需要我们自己写，是在内核的arch/arm/boot/dts目录下存着有xxxx.dtsi文件，我们自己写dts时只需要在我们的设备树文件中#include "xxxx.dtsi"，示例：

/dts-v1/;
#include <dt-bindings/input/input.h>
#include "imx6ull.dtsi"
/ {
。。。。。。。

};

然后再做出我们的细微修改就可以了

常用属性

#address-cells、#size-cells、reg

address-cells：address 要用多少个 32 位数来表示，示例如：#address-cells = <1>;
size-cells：size 要用多少个 32 位数来表示，示例如#size-cells = <1>;
例如，一段内存，如何描述他的起始地址和大小呢：如下

/ {
	#address-cells = <1>;
	#size-cells = <1>;
	memory {
		reg = <0x80000000 0x20000000>;
	};
};

由于address-cells与size-cells都为1，所以reg用1个32位数0x80000000来表示地址，用1个32位数0x20000000来表示大小

compatible

compatible中文意思为兼容，表示该设备支持哪些驱动，这个在platform_device和platform_driver的匹配过程中至关重要，内核启动后会根据根节点的 compatible 属性找到对应的 machine desc 结构体，执行其中的初始化函数。书写格式非常简单，如下：

led {
	compatible = "samsung,smdk2440", "samsung,mini2440";
};

compatible 的值，建议取这样的形式：“厂家名，模块名”。

model

model 属性与 compatible 属性有些类似，但是有差别。
compatible 属性是一个字符串列表，表示你的硬件可以兼容 A、B、C 等驱动；
model 用来准确地定义这个硬件是什么，比如：

{
	compatible = "samsung,smdk2440", "samsung,mini2440";
	model = "jz2440_v3";
};

status

dtsi 文件中定义了很多设备，但是在你的板子上某些设备是没有的。这时你可以给这个设备节点添加一个status属性，设置为“disabled”

&uart1 {
	status = "disabled";
};

常用的状态就是okey-表示可以用、disabled-表示不能用，还有不常用的fail、fail-ass，表示出错需要改，知道就行了没屁用。

name、device_type

过时了，建议不用，效果和compile类似，都是匹配用的，不过compile的优先级最高

内核对设备树的处理

1. dts 在 PC 机上被编译为二进制格式的 dtb 文件；
2. u-boot 把 dtb 文件传给内核，内核解析 dtb 文件，把每一个节点都转换为 device_node 结构体；
3. 对于某些 device_node 结构体，会被转换为 platform_device 结构体。

dts->dtb

设置 ARCH、 CROSS_COMPILE、 PATH 这三个环境变量后，进入 ubuntu 上板子内核源码的目录，执行如下命令即可编译 dtb 文件：

make dtbs V=1

dtb->device_node

dtb 中每一个节点都被转换为 device_node 结构体，根节点将被保存在of_root中，从of_root开始可以访问到任意节点。

device_node->platform_device

首先，转化为platform_device的节点有：

1. 根节点下含有 compatile 属性的子节点
2. 若某节点的compile属性是"simplebus"、“simple-mfd”、“isa”、"arm,amba-bus"这四者之一，那么其子节点就可以转为platform_deivce
3. i2c总线和spi总线下的子节点不转为platform_device
4. /i2c 与 /spi 一般表示i2c控制器和spi控制器，其符合上面条件1，会转为platform_deivce

其次，转换方式：

1. device_node 的 reg 和 interrupts 转为 platform_device 的 resource 数组
2. platform_device.dev.of_node 指向 device_node, 可以通过它获得其他属性

platform_device 与 platform_driver 配对

在Linux_驱动编写方案与总线驱动模型中提了一下本函数，无论是bus_type还是本文的设备树，都是利用了platform_deivce函数来比较，其实观察这个函数的判断逻辑就知道了

1. platform_device. driver_override（device指定要这个名字的driver）和 platform_driver.driver.name（driver的名字）
2. platform_device.dev.of_node（指向device_node）和platform_driver.driver.of_match_table（若platform_deivce支持设备树，那么这个…_table就是个数组of_deivce_id[]）比较顺序为compile->type->name，有哪个比哪个，比一个就行，一样就成功不一样就失败

struct of_device_id{
	char name[32];
	char type[32];
	char compatible[128];
	const void *data;
};

3. platform_device. name（device的名字）和 platform_driver.id_table[i].name（idtable里面存放着本driver支持的device名）
4. platform_device.name（device的名字）和 platform_driver.driver.name（driver的名字）

11.7中有一堆操作设备树的函数，可以当词典用