Linux学习_设备树
总结三种写驱动的方法
资源和驱动在同一个文件里
这是最简单无脑，但也是代码复用性最差的方法
资源用 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的优先级最高
内核对设备树的处理
- dts 在 PC 机上被编译为二进制格式的 dtb 文件；
- u-boot 把 dtb 文件传给内核，内核解析 dtb 文件，把每一个节点都转换为 device_node 结构体；
- 对于某些 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的节点有：
- 根节点下含有 compatile 属性的子节点
- 若某节点的compile属性是"simplebus"、“simple-mfd”、“isa”、"arm,amba-bus"这四者之一，那么其子节点就可以转为platform_deivce
- i2c总线和spi总线下的子节点不转为platform_device
- /i2c 与 /spi 一般表示i2c控制器和spi控制器，其符合上面条件1，会转为platform_deivce
其次，转换方式：
-
device_node的 reg 和 interrupts 转为platform_device的 resource 数组 -
platform_device.dev.of_node指向device_node, 可以通过它获得其他属性
platform_device 与 platform_driver 配对
在Linux_驱动编写方案与总线驱动模型中提了一下本函数，无论是bus_type还是本文的设备树，都是利用了platform_deivce函数来比较，其实观察这个函数的判断逻辑就知道了
-
platform_device. driver_override（device指定要这个名字的driver）和platform_driver.driver.name（driver的名字） -
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;
};
-
platform_device. name（device的名字）和platform_driver.id_table[i].name（idtable里面存放着本driver支持的device名） - platform_device.name（device的名字）和 platform_driver.driver.name（driver的名字）