08.设备树

1.设备树介绍

x3399-linux.dts文件中

Device Tree 是一种描述硬件的数据结构， 由一系列被命名的节点（node） 和属性（property） 组成， 而节点本身可包含子节点。 所谓属性， 其实就是成对出现的 name 和 value。

在 Device Tree 中， 可描述的信息包括： CPU 的数量和类别， 内存基地址和大小， 总线和桥， 外设连接，中断控制器和中断使用情况， GPIO 控制器和 GPIO 使用情况， Clock 控制器和 Clock 使用情况。 而设备树基本上就是画一棵电路板上由 CPU、 总线、 设备组成的树， Bootloader 会将这棵树传递给内核， 然后内核可以识别这棵树， 并根据它展开出 Linux 内核中的 platform_device、 i2c_client、spi_device 等设备， 这些设备用到的内存、 IRQ 等资源， 也被传递给了内核， 内核会将这些资源绑定给展开的相应的设备。

设备树的特性：

1.设备树文件用于描述硬件资源的一种数据结构
2.设备树的组成：节点-->子节点 属性（名字 参数）
3.CPU 的数量和类别， 
4.内存基地址和大小， 
5.总线和桥， 外设连接，
6.中断控制器和中断使用情况， 
7.GPIO 控制器和 GPIO 使用情况， 
8.Clock 控制器和 Clock 使用情况

DTS DTC DTB的关系

文件.dts 是一种 ASCII 文件格式设备树描述， 在 Linux 中， 一个.dts 文件对应一个 ARM 设备， 一般放置在 arch/arm/boot/dts 目录下。

dtb 文件是 dts 文件被编译后生成的二进制文件， 由 Linux 内核解析， 有了设备树文件就可以在不改动Linux 内核的情况下， 对不同的平台实现无差异的支持， 只需更换相应的 dts 文件， 即可满足。

dtc 是将 dts 编译为 dtb 的工具。 在 Linux 内核下可以单独编译设备树文件， 那么如何确定去编译我们自己 的 板 子 对 应 的 dts 文 件 ？ ， 我 们 来 看 一 下RK3399 内 核 源 码 下 的

kernel\arch\arm64\boot\dts\rockchip\Makefile

DTSI文件和DTS文件的区别和联系：

设备节点信息：

设备树从根节点开始， 每个设备都是一个节点。 根节点就相当于树根。 节点和节点之间可以互相嵌套，形成父子关系。 可以理解为树枝可以分成好几个小的树枝。 设备的属性用 key-value 对(键值对)来描述， 每个属性用分号结束。

引用的方式：

变量=<&+节点名字/别名 val>

设备树从根节点开始， 每个设备都是一个节点。 根节点就相当于树根。 节点和节点之间可以互相嵌套，形成父子关系。 可以理解为树枝可以分成好几个小的树枝。 设备的属性用 key-value 对(键值对)来描述， 每个属性用分号结束。

1 1）文本字符串（无结束符） ， 可以用双引号表示：
2 a-string-property = "A string";
3 2) “cell” 是 32 位无符号整数， 用尖括号限定：
4 cell-property = <0xbeef 123 0xabcd1234>；
5 3) 二进制数据用方括号限定：
6 binary-property = [0x01 0x23 0x45 0x67];
7 4) 不同表示形式的数据可以用逗号连在一起：
8 mixed-property = "a string", [0x01 0x23 0x45 0x67], <0x12345678>;
9 5) 逗号也可以用于创建字符串列表：
10 string-list = "red fish", "blue fish";

标签和别名

以上就是我们节点命名方式，大家只需要遵循一个原则，节点的名字必须唯一。

以下手册中包含的又不同外设的地址：

别名的作用：当我们找一个节点的时候， 我们必须书写完整的节点路径， 如果我们的节点名很长， 那么我们在引用的时候就十分不方便， 所以， 设备树允许我们用下面的形式为节点标注引用(起别名)。

对节点添加内容

编译设备树的时候， 相同的节点的不同属性信息都会被合并， 相同节点的相同的属性会被重写， 使用引用可以避免四处找节点。 如 dts 和 dtsi 里面都有根节点， 但最终会合并成一个根节点

标准属性

address-cells 和 size-cells 属性

不同的平台， 不同的总线， 地址位长度可能不同， 有 32 位地址， 有 64 位地址， 为了适应这个，规范规定一个 32 位的长度为一个 cell。

"#address-cells"属性用来表示总线地址需要几个 cell 表示， 该属性本身是 u32 类型的。"#size-cells"属性用来表示子总线地址空间的长度需要几个 cell 表示， 属性本身的类型也是 u32。可以这么理解父节点表示总线， 总线上每个设备的地址长度以及地址范围是总线的一个特性，用"#address-cells","#size-cells"属性表示， 比如总线是 32 位， 那么"#address-cells"设置成 1 就可以了。 这两个属性不可以继承， 就是说在未定义这两个属性的时候， 不会继承更高一级父节点的设置，如果没有设置的话， 内核默认认为"#address-cells"为 2， "#size-cells"为 1。

compatible 属性

设备树中的每个表示一个设备的节点都需要一个 compatible 属性， compatible 属性是操作系统用来决定设备和驱动绑定的关键因素。 compatible 属性也叫做兼容性属性， 属性的值是一个字符串列表，用于表示是何种设备， 可以在代码中进行匹配。

status属性

代码编写部分：

添加设备树节点

of_find_node_by_name()
位置：kernel\drivers\of\base.c
of_find_node_by_name 是 Linux 内核中用于在设备树中查找节点的函数。它接收两个参数，一个是起始节点 from，
另一个是要查找的节点名称 name。
函数的目的是在设备树中从起始节点开始递归查找具有指定名称的节点，并返回找到的节点的指针。

of_get_named_gpio()
位置：kernel\include\linux\of_gpio.h
此函数获取 GPIO 编号，因为 Linux 内核中关于 GPIO 的 API 函数都要使用 GPIO 编号，此函数会将设备树中类似 <&gpio5 7 GPIO_ACTIVE_LOW> 的属性信息转换为对应的 GPIO 编号，此函数在驱动中使用很频繁

probe函数的作用：

主要是用于匹配驱动代码和设备树节点，只有获取了设备节点中IO口编号，才可以进行后续的操作，比如应用层控制beep的工作状态

ioctl的对应关系：

首先是，需要设备树文件和probe函数进行设备和驱动的匹配，后续才可以进行ioctl函数的操作。

/*
 * GPIO Buzzer driver example
 *
 * Melvyn on Aug 28,2023
 * 
 * Usage: insmod buzzer-drv.ko
 *
 */
#include <linux/gpio.h>
#include <linux/io.h>
#include <linux/platform_device.h>
#include <linux/miscdevice.h>
#include <linux/of.h>
 #include <linux/of_gpio.h>
/*
 *
 */
#define     BUZZER_ON       _IO('B',0)
#define     BUZZER_OFF      _IO('B',1)

int buz_gpio;
struct device_node *buz_node;

/*
 *
 */
static long qf3399_buzzer_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
    switch(cmd){
    case BUZZER_ON:
        gpio_set_value(buz_gpio,1);
        break;
    case BUZZER_OFF:
        gpio_set_value(buz_gpio,0);
        break;
    }

    return 0;
}

static int qf3399_buzzer_release(struct inode *inode, struct file *file) 
{
    gpio_set_value(buz_gpio,0);
    return 0;
}

static const struct file_operations qf3399_buzzer_fops = {
    .owner = THIS_MODULE,
    .unlocked_ioctl = qf3399_buzzer_ioctl,//io控制
    .release = qf3399_buzzer_release,//驱动关闭函数
};

static struct miscdevice qf3399_buzzer_misc = {
    .minor = MISC_DYNAMIC_MINOR,//杂项设备设备号
    .fops = &qf3399_buzzer_fops,
    .name   = "usr-buzzer",  //设备节点名字  
};

static int qf3399_buzzer_probe(struct platform_device *pdev)
{
    int ret;
    buz_node = pdev->dev.of_node;

    //
    buz_node = of_find_node_by_name(NULL,"usr_buzzer");
    if(buz_node == NULL) {
        printk(KERN_ALERT "failed to find node by name\n");
        return -ENODEV;
    }

    buz_gpio = of_get_named_gpio(buz_node,"gpio", 0);
    if (!gpio_is_valid(buz_gpio)) {
        printk(KERN_ALERT "failed to get gpio:%d\n",buz_gpio);
        return -ENODEV;
    }

    //
    ret = gpio_request(buz_gpio,"buzzer-gpio");
    if(ret < 0){
        printk(KERN_ALERT "failed to request gpio:%d\n",buz_gpio);
        goto err_probe;
    }

    //
    ret = gpio_direction_output(buz_gpio,0);
    if(ret < 0){
        printk(KERN_ALERT "failed to output 0:%d\n",buz_gpio);
        goto err_probe;
    }

    //
    ret =  misc_register(&qf3399_buzzer_misc);//注册为杂项设备
    if(ret < 0){
        printk(KERN_ALERT "failed to create misc device\n");
        goto err_probe;
    }

    //
    printk( KERN_ALERT "buzzer dirve install success\n");
    return 0;
    //
err_probe:
    gpio_free(buz_gpio);
    return ret;
}

static int qf3399_buzzer_remove(struct platform_device *pdev)
{

    gpio_free(buz_gpio);

    misc_deregister(&qf3399_buzzer_misc);

    printk(KERN_ALERT "buzzer dirve remove success\n");
    return 0;
}

static const struct of_device_id of_qf_buzzer_match[] = {
    {.compatible = "usr-buzzer",},
    {},
}; 

//平台总线
static struct platform_driver qf3399_buzzer_driver = {
    .driver  = {
        .name ="usr-buzzer",
        .owner = THIS_MODULE,
        .of_match_table = of_qf_buzzer_match,
    },

    .probe  = qf3399_buzzer_probe,
    .remove  = qf3399_buzzer_remove,
};

module_platform_driver(qf3399_buzzer_driver);

//
MODULE_DESCRIPTION("buzzer driver example for RK3399");
MODULE_LICENSE("GPL");
MODULE_VERSION("V1.0");

查看设备树是否加载成功：