前言

韦东山嵌入式Linux驱动开发基础知识学习笔记
文章中大多内容来自韦东山老师的文档，还有部分个人根据自己需求补充的内容
视频教程地址：https://www.bilibili.com/video/BV14f4y1Q7ti

1、设备树的作用

  在上一章【嵌入式Linux】嵌入式Linux驱动开发基础知识之总线设备驱动模型中介绍了设备树引入的背景，设备树文件可以被内核自动解析并生成设备需要的资源，比如针对LED设备，这个资源就是操作对应GPIO所需要的寄存器信息

2、设备树的语法

2.1、设备树的逻辑图和dts文件、dtb文件

▲设备树逻辑图

如何向内核描述这棵树？
  我们需要编写设备树文件(dts: device tree source)，它需要编译为dtb(device tree blob)文件，内核使用的是dtb文件。

那么dts文件的语法是怎样的？下面是一个从设备树逻辑图对应dts文件的实例

▲设备树实例

▲dts文件实例

2.1.1、1Devicetree格式

1DTS文件的格式

/dts-v1/;                // 表示版本
[memory reservations]    // 格式为: /memreserve/ <address> <length>;
/ {[property definitions][child nodes]
};

node的格式

[label:] node-name[@unit-address] {[properties definitions][child nodes]
};

label是标号，可以省略。label的作用是为了方便地引用node，比如：

/dts-v1/;
/ {uart0: uart@fe001000 {compatible="ns16550";reg=<0xfe001000 0x100>;};
};

引用：

// 在根节点之外使用label引用node：
&uart0 {status = “disabled”;
};
或在根节点之外使用全路径：
&{/uart@fe001000}  {status = “disabled”;
};

properties的格式

Property格式1:
[label:] property-name = value;

Property格式2(没有值):
[label:] property-name;

Property取值只有3种:
arrays of cells(1个或多个32位数据, 64位数据使用2个32位数据表示),
string(字符串),
bytestring(1个或多个字节)

示例:

a. Arrays of cells : cell就是一个32位的数据，用尖括号包围起来
interrupts = <17 0xc>;

b. 64bit数据使用2个cell来表示，用尖括号包围起来:
clock-frequency = <0x00000001 0x00000000>;

c. A null-terminated string (有结束符的字符串)，用双引号包围起来:
compatible = "simple-bus";

d. A bytestring(字节序列) ，用中括号包围起来:
local-mac-address = [00 00 12 34 56 78];  // 每个byte使用2个16进制数来表示
local-mac-address = [000012345678];       // 每个byte使用2个16进制数来表示

e. 可以是各种值的组合, 用逗号隔开:
compatible = "ns16550", "ns8250";
example = <0xf00f0000 19>, "a strange property format";

2.1.2、 dts文件包含dtsi文件

  设备树文件不需要我们从零写出来，内核支持了某款芯片比如imx6ull，在内核的arch/arm/boot/dts目录下就有了能用的设备树模板，一般命名为xxxx.dtsi。“i”表示“include”，被别的文件引用的。
  我们使用某款芯片制作出了自己的单板，所用资源跟xxxx.dtsi是大部分相同，小部分不同，所以需要引脚xxxx.dtsi并修改。
  dtsi文件跟dts文件的语法是完全一样的。

dts中可以包含.h头文件，也可以包含dtsi文件，在.h头文件中可以定义一些宏。
/dts-v1/;#include <dt-bindings/input/input.h>
#include "stm32mp15xx-100ask.dtsi"/ {……
};

2.1.3、常用的属性

#address-cells、#size-cells
address-cells：address要用多少个32位数来表示；
size-cells：size要用多少个32位数来表示。

比如一段内存，起始地址为0x80000000，大小为0x20000000
/ {#address-cells = <1>;
#size-cells = <1>;
memory {reg = <0x80000000 0x20000000>;};
};

compatible

“compatible”表示“兼容”，对于某个LED，内核中可能有A、B、C三个驱动都支持它，那可以这样写：
led {compatible = “A”, “B”, “C”;
};
内核启动时，就会为这个LED按这样的优先顺序为它找到驱动程序：A、B、C。

  根节点下也有compatible属性，用来选择哪一个“machine desc”：一个内核可以支持machine A，也支持machine B，内核启动后会根据根节点的compatible属性找到对应的machine desc结构体，执行其中的初始化函数。
  compatible的值，建议取这样的形式：“manufacturer,model”，即“厂家名,模块名”。

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

比如根节点中可以这样写：
/ {compatible = "samsung,smdk2440", "samsung,mini2440";model = "jz2440_v3";
};
它表示这个单板，可以兼容内核中的“smdk2440”，也兼容“mini2440”。
从compatible属性中可以知道它兼容哪些板，但是它到底是什么板？用model属性来明确。

status

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

▲状态属性的值

reg
  reg的本意是register，用来表示寄存器地址。
  但是在设备树里，它可以用来描述一段空间。反正对于ARM系统，寄存器和内存是统一编址的，即访问寄存器时用某块地址，访问内存时用某块地址，在访问方法上没有区别。
  reg属性的值，是一系列的“address size”，用多少个32位的数来表示address和size，由其父节点的#address-cells、#size-cells决定。

示例：
/dts-v1/;
/ {#address-cells = <1>;#size-cells = <1>; memory {reg = <0x80000000 0x20000000>;};
};

name(过时了，建议不用)
  它的值是字符串，用来表示节点的名字。在跟platform_driver匹配时，优先级最低。
  compatible属性在匹配过程中，优先级最高。
1device_type(过时了，建议不用)
  它的值是字符串，用来表示节点的类型。在跟platform_driver匹配时，优先级为中。
  compatible属性在匹配过程中，优先级最高。

2.1.4、 常用的节点(node)

根节点

dts文件中必须有一个根节点：
/dts-v1/;
/ {model = "SMDK24440";compatible = "samsung,smdk2440";#address-cells = <1>;#size-cells = <1>;
};

根节点中必须有这些属性：
#address-cells // 在它的子节点的reg属性中, 使用多少个u32整数来描述地址(address)
#size-cells         // 在它的子节点的reg属性中, 使用多少个u32整数来描述大小(size)
compatible      // 定义一系列的字符串, 用来指定内核中哪个machine_desc可以支持本设备// 即这个板子兼容哪些平台 // uImage : smdk2410 smdk2440 mini2440     ==> machine_desc         model       // 咱这个板子是什么// 比如有2款板子配置基本一致, 它们的compatible是一样的// 那么就通过model来分辨这2款板子

CPU节点

一般不需要我们设置，在dtsi文件中都定义好了：
cpus {#address-cells = <1>;#size-cells = <0>;cpu0: cpu@0 {.......}
};

memory节点

芯片厂家不可能事先确定你的板子使用多大的内存，所以memory节点需要板厂设置，比如：
memory {reg = <0x80000000 0x20000000>;
};

chosen节点

我们可以通过设备树文件给内核传入一些参数，这要在chosen节点中设置bootargs属性：
chosen {bootargs = "noinitrd root=/dev/mtdblock4 rw init=/linuxrc console=ttySAC0,115200";
};

2.2、编译、更换设备树

  我们一般不会从零写dts文件，而是修改。程序员水平有高有低，改得对不对？需要编译一下。并且内核直接使用dts文件的话，就太低效了，它也需要使用二进制格式的dtb文件。

2.2.1、在内核中直接make

make  dtbs  V=1

2.2.2、手工编译/反编译

除非你对设备树比较了解，否则不建议手工使用dtc工具直接编译。
  内核目录下scripts/dtc/dtc是设备树的编译工具，直接使用它的话，包含其他文件时不能使用“#include”，而必须使用“/incldue”。

编译、反编译的示例命令如下，“-I”指定输入格式，“-O”指定输出格式，“-o”指定输出文件：
./scripts/dtc/dtc -I dts -O dtb -o tmp.dtb arch/arm/boot/dts/xxx.dts  // 编译dts为dtb
./scripts/dtc/dtc -I dtb -O dts -o tmp.dts arch/arm/boot/dts/xxx.dtb  // 反编译dtb为dts

2.2.3、更换设备树文件dtb

设备树文件是：内核源码目录中arch/arm/boot/dts/stm32mp157c-100ask-512d-lcd-v1.dtb
可以通过nfs ssh等方式把新编译出来的方式拷贝到开发板/boot目录下 替换掉原来的。

2.3、查看设备树

▲ls /sys/firmware/

  /sys/firmware/devicetree目录下是以目录结构程现的dtb文件, 根节点对应base目录, 每一个节点对应一个目录, 每一个属性对应一个文件。
  这些属性的值如果是字符串，可以使用cat命令把它打印出来；对于数值，可以用hexdump把它打印出来。

▲ls /sys/firmware/devicetree/base/

  还可以看到/sys/firmware/fdt文件，它就是dtb格式的设备树文件，可以把它复制出来放到ubuntu上，执行下面的命令反编译出来(-I dtb：输入格式是dtb，-O dts：输出格式是dts)：
./scripts/dtc/dtc -I dtb -O dts /从板子上/复制出来的/fdt -o tmp.dts

mi@mi-HP-ProDesk-680-G6-PCI-Microtower-PC:~/100ask/100ask_stm32mp157_pro-sdk/Linux-5.4$ sudo ./scripts/dtc/dtc -I dtb -O dts ~/nfs_rootfs/fdt -o tmp.dts
tmp.dts: Warning (unit_address_vs_reg): /soc/pin-controller@50002000/m_can1-sleep@0: node has a unit name, but no reg property
tmp.dts: Warning (unit_address_vs_reg): /soc/pin-controller@50002000/rtc-out2-rmp-pins@0: node has a unit name, but no reg property
tmp.dts: Warning (unit_address_vs_reg): /soc/pin-controller@50002000/m_can2-100ask-sleep@0: node has a unit name, but no reg property
tmp.dts: Warning (unit_address_vs_reg): /fixedregulator@0: node has a unit name, but no reg property
tmp.dts: Warning (unit_address_vs_reg): /fixedregulator@1: node has a unit name, but no reg property
tmp.dts: Warning (unit_address_vs_reg): /fixedregulator@2: node has a unit name, but no reg property
tmp.dts: Warning (unit_address_vs_reg): /fixedregulator@3: node has a unit name, but no reg property
tmp.dts: Warning (unit_address_format): /reserved-memory/optee@0xde000000: unit name should not have leading "0x"
tmp.dts: Warning (simple_bus_reg): /soc/stmmac-axi-config: missing or empty reg/ranges property
tmp.dts: Warning (simple_bus_reg): /soc/tamp@5c00a000/reboot-mode: missing or empty reg/ranges property
tmp.dts: Warning (unique_unit_address): /soc/spi@4000b000: duplicate unit-address (also used in node /soc/audio-controller@4000b000)
tmp.dts: Warning (unique_unit_address): /soc/spi@4000c000: duplicate unit-address (also used in node /soc/audio-controller@4000c000)
tmp.dts: Warning (unique_unit_address): /soc/spi@44004000: duplicate unit-address (also used in node /soc/audio-controller@44004000)
tmp.dts: Warning (unique_unit_address): /soc/pin-controller@50002000/m_can1-sleep@0: duplicate unit-address (also used in node /soc/pin-controller@50002000/rtc-out2-rmp-pins@0)
tmp.dts: Warning (unique_unit_address): /soc/pin-controller@50002000/m_can1-sleep@0: duplicate unit-address (also used in node /soc/pin-controller@50002000/m_can2-100ask-sleep@0)
tmp.dts: Warning (unique_unit_address): /soc/pin-controller@50002000/rtc-out2-rmp-pins@0: duplicate unit-address (also used in node /soc/pin-controller@50002000/m_can2-100ask-sleep@0)
tmp.dts: Warning (unique_unit_address): /mlahb/m4@10000000/m4_system_resources/spi@4000b000: duplicate unit-address (also used in node /mlahb/m4@10000000/m4_system_resources/audio-controller@4000b000)
tmp.dts: Warning (unique_unit_address): /mlahb/m4@10000000/m4_system_resources/spi@4000c000: duplicate unit-address (also used in node /mlahb/m4@10000000/m4_system_resources/audio-controller@4000c000)
tmp.dts: Warning (unique_unit_address): /mlahb/m4@10000000/m4_system_resources/spi@44004000: duplicate unit-address (also used in node /mlahb/m4@10000000/m4_system_resources/audio-controller@44004000)
tmp.dts: Warning (graph_child_address): /soc/i2c@5c002000/hdmi-transmitter@40/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary

3、内核对设备树的处理

从源代码文件dts文件开始，设备树的处理过程为：

▲设备树的处理过程

① dts在PC机上被编译为dtb文件；
② u-boot把dtb文件传给内核；
③ 内核解析dtb文件，把每一个节点都转换为device_node结构体；
④ 对于某些device_node结构体，会被转换为platform_device结构体。

3.1、dtb中每一个节点都被转换为device_node结构体

struct device_node {const char *name;phandle phandle;const char *full_name;struct fwnode_handle fwnode;struct    property *properties;struct property *deadprops;    /* removed properties */struct  device_node *parent;struct  device_node *child;struct   device_node *sibling;
#if defined(CONFIG_OF_KOBJ)struct   kobject kobj;
#endifunsigned long _flags;void *data;
#if defined(CONFIG_SPARC)unsigned int unique_id;struct of_irq_controller *irq_trans;
#endif
};struct property {char *name;int   length;void *value;struct property *next;unsigned long _flags;unsigned int unique_id;struct bin_attribute attr;
};

根节点被保存在全局变量of_root中，从of_root开始可以访问到任意节点。

3.2、哪些设备树节点会被转换为platform_device

A. 根节点下含有compatile属性的子节点

B. 含有特定compatile属性的节点的子节点
如果一个节点的compatile属性，它的值是这4者之一：“simple-bus”,“simple-mfd”,“isa”,“arm,amba-bus”,
那么它的子结点(需含compatile属性)也可以转换为platform_device。

C. 总线I2C、SPI节点下的子节点：不转换为platform_device
某个总线下到子节点，应该交给对应的总线驱动程序来处理, 它们不应该被转换为platform_device。

实例：

/ {mytest {compatile = "mytest", "simple-bus";mytest@0 {compatile = "mytest_0";};};i2c {compatile = "samsung,i2c";at24c02 {compatile = "at24c02";                      };};spi {compatile = "samsung,spi";              flash@0 {compatible = "winbond,w25q32dw";spi-max-frequency = <25000000>;reg = <0>;};};};/mytest会被转换为platform_device, 因为它兼容"simple-bus";
它的子节点/mytest/mytest@0 也会被转换为platform_device
/i2c节点一般表示i2c控制器, 它会被转换为platform_device, 在内核中有对应的platform_driver;
/i2c/at24c02节点不会被转换为platform_device, 它被如何处理完全由父节点的platform_driver决定, 一般是被创建为一个i2c_client。
类似的也有/spi节点, 它一般也是用来表示SPI控制器, 它会被转换为platform_device, 在内核中有对应的platform_driver;
/spi/flash@0节点不会被转换为platform_device, 它被如何处理完全由父节点的platform_driver决定, 一般是被创建为一个spi_device。

3.3、怎么转换为platform_device

内核处理设备树的函数调用过程，这里不去分析；我们只需要得到如下结论：
A. platform_device中含有resource数组, 它来自device_node的reg, interrupts属性;
B. platform_device.dev.of_node指向device_node, 可以通过它获得其他属性

4、platform_device如何与platform_driver配对

  从设备树转换得来的platform_device会被注册进内核里，以后当我们每注册一个platform_driver时，它们就会两两确定能否配对，如果能配对成功就调用platform_driver的probe函数。
  套路是一样的。
  我们需要将前面讲过的“匹配规则”再完善一下：
  先贴源码：

/*** platform_match - bind platform device to platform driver.* @dev: device.* @drv: driver.** Platform device IDs are assumed to be encoded like this:* "<name><instance>", where <name> is a short description of the type of* device, like "pci" or "floppy", and <instance> is the enumerated* instance of the device, like '0' or '42'.  Driver IDs are simply* "<name>".  So, extract the <name> from the platform_device structure,* and compare it against the name of the driver. Return whether they match* or not.*/
static int platform_match(struct device *dev, struct device_driver *drv)
{struct platform_device *pdev = to_platform_device(dev);struct platform_driver *pdrv = to_platform_driver(drv);1、 /* When driver_override is set, only bind to the matching driver */if (pdev->driver_override)return !strcmp(pdev->driver_override, drv->name);2、   /* Attempt an OF style match first */if (of_driver_match_device(dev, drv))return 1;/* Then try ACPI style match */if (acpi_driver_match_device(dev, drv))return 1;3、    /* Then try to match against the id table */if (pdrv->id_table)return platform_match_id(pdrv->id_table, pdev) != NULL;/* fall-back to driver name match */
4、  return (strcmp(pdev->name, drv->name) == 0);
}

最先比较device和driver的override

比较设备树信息platform_device. dev.of_node和platform_driver.driver.of_match_table

设备树转换来的platform_device含有一个结构体of_node：
platform_device. dev.of_node:

▲platform_device. dev.of_node

如果一个platform_driver支持设备树，它的platform_driver.driver.of_match_table是一个数组，类型如下：
platform_driver.driver.of_match_table:
struct of_device_id {char   name[32];char   type[32];char   compatible[128];const void *data;
};

首先，如果of_match_table中含有compatible值，就跟dev的compatile属性比较，若一致则成功，否则返回失败；
其次，如果of_match_table中含有type值，就跟dev的device_type属性比较，若一致则成功，否则返回失败；
最后，如果of_match_table中含有name值，就跟dev的name属性比较，若一致则成功，否则返回失败。
值的注意的是：
而设备树中建议不再使用devcie_type和name属性，所以基本上只使用设备节点的compatible属性来寻找匹配的platform_driver。

接下来比较：platform_device_id

比较platform_device. name和platform_driver.id_table[i].name，id_table中可能有多项。
platform_driver.id_table是“platform_device_id”指针，表示该drv支持若干个device，它里面列出了各个device的=={.name, .driver_data}==，其中的“name”表示该drv支持的设备的名字，driver_data是些提供给该device的私有数据。

最后比较：platform_device.name和platform_driver.driver.name

platform_driver.id_table可能为空，
这时可以根据platform_driver.driver.name来寻找同名的platform_device。

一个图概括所有的配对过程

▲device和driver配对过程

5、没有转换为platform_device的节点，如何使用

任意驱动程序里，都可以直接访问设备树。
你可以使用下一节中介绍的函数找到节点，读出里面的值。

6、内核里操作设备树的常用函数

内核源码中include/linux/目录下有很多of开头的头文件，of表示“open firmware”即开放固件。

6.1、内核中设备树相关的头文件介绍

设备树的处理过程是：dtb -> device_node -> platform_device。

6.1.1、处理DTB

of_fdt.h           // dtb文件的相关操作函数, 我们一般用不到,
// 因为dtb文件在内核中已经被转换为device_node树(它更易于使用)

6.1.2、处理device_node

of.h               // 提供设备树的一般处理函数,
// 比如 of_property_read_u32(读取某个属性的u32值),
// of_get_child_count(获取某个device_node的子节点数)
of_address.h      // 地址相关的函数, // 比如 of_get_address(获得reg属性中的addr, size值)// of_match_device (从matches数组中取出与当前设备最匹配的一项)
of_dma.h           // 设备树中DMA相关属性的函数
of_gpio.h          // GPIO相关的函数
of_graph.h         // GPU相关驱动中用到的函数, 从设备树中获得GPU信息
of_iommu.h         // 很少用到
of_irq.h           // 中断相关的函数
of_mdio.h          // MDIO (Ethernet PHY) API
of_net.h           // OF helpers for network devices.
of_pci.h           // PCI相关函数
of_pdt.h           // 很少用到
of_reserved_mem.h  // reserved_mem的相关函数

6.1.3、处理 platform_device

of_platform.h      // 把device_node转换为platform_device时用到的函数, // 比如of_device_alloc(根据device_node分配设置platform_device), // of_find_device_by_node (根据device_node查找到platform_device),//   of_platform_bus_probe (处理device_node及它的子节点)
of_device.h        // 设备相关的函数, 比如 of_match_device

6.2、platform_device相关的函数

  of_platform.h中声明了很多函数，但是作为驱动开发者，我们只使用其中的1、2个。其他的都是给内核自己使用的，内核使用它们来处理设备树，转换得到platform_device。

of_find_device_by_node

extern struct platform_device *of_find_device_by_node(struct device_node *np);

设备树中的每一个节点，在内核里都有一个device_node；你可以使用device_node去找到对应的platform_device。

platform_get_resource

  这个函数跟设备树没什么关系，但是设备树中的节点被转换为platform_device后，设备树中的reg属性、interrupts属性也会被转换为“resource”。
  这时，你可以使用这个函数取出这些资源。

/*** platform_get_resource - get a resource for a device* @dev: platform device* @type: resource type   // 取哪类资源？IORESOURCE_MEM、IORESOURCE_REG
*                                               // IORESOURCE_IRQ等* @num: resource index  // 这类资源中的哪一个？*/
struct resource *platform_get_resource(struct platform_device *dev,unsigned int type, unsigned int num);

对于设备树节点中的reg属性，它对应IORESOURCE_MEM类型的资源；
对于设备树节点中的interrupts属性，它对应IORESOURCE_IRQ类型的资源。

6.3、有些节点不会生成platform_device，怎么访问它们

内核会把dtb文件解析出一系列的device_node结构体，我们可以直接访问这些device_node。
内核源码incldue/linux/of.h中声明了device_node和属性property的操作函数，device_node和property的结构体定义如下：

▲device_node和property的结构体

找到device_node

a. of_find_node_by_path
根据路径找到节点，比如“/”就对应根节点，“/memory”对应memory节点。
函数原型：
static inline struct device_node *of_find_node_by_path(const char *path);

b. of_find_node_by_name（不建议使用）
根据名字找到节点，节点如果定义了name属性，那我们可以根据名字找到它。
函数原型：
extern struct device_node *of_find_node_by_name(struct device_node *from, const char *name);

参数from表示从哪一个节点开始寻找，传入NULL表示从根节点开始寻找。
但是在设备树的官方规范中不建议使用“name”属性，所以这函数也不建议使用。
c. of_find_node_by_type（不建议使用）
根据类型找到节点，节点如果定义了device_type属性，那我们可以根据类型找到它。
函数原型：
extern struct device_node *of_find_node_by_type(struct device_node *from, const char *type);

参数from表示从哪一个节点开始寻找，传入NULL表示从根节点开始寻找。
但是在设备树的官方规范中不建议使用“device_type”属性，所以这函数也不建议使用。
d. of_find_compatible_node
根据compatible找到节点，节点如果定义了compatible属性，那我们可以根据compatible属性找到它。
函数原型：
extern struct device_node *of_find_compatible_node(struct device_node *from, const char *type, const char *compat);
参数from表示从哪一个节点开始寻找，传入NULL表示从根节点开始寻找。
参数compat是一个字符串，用来指定compatible属性的值；
参数type是一个字符串，用来指定device_type属性的值，可以传入NULL。
e. of_find_node_by_phandle
根据phandle找到节点。
dts文件被编译为dtb文件时，每一个节点都有一个数字ID，这些数字ID彼此不同。可以使用数字ID来找到device_node。这些数字ID就是phandle。
函数原型：
extern struct device_node *of_find_node_by_phandle(phandle handle);
参数from表示从哪一个节点开始寻找，传入NULL表示从根节点开始寻找。

f. of_get_parent
找到device_node的父节点。
函数原型：
extern struct device_node *of_get_parent(const struct device_node *node);

参数from表示从哪一个节点开始寻找，传入NULL表示从根节点开始寻找。

g. of_get_next_parent
这个函数名比较奇怪，怎么可能有“next parent”？
它实际上也是找到device_node的父节点，跟of_get_parent的返回结果是一样的。
差别在于它多调用下列函数，把node节点的引用计数减少了1。这意味着调用of_get_next_parent之后，你不再需要调用of_node_put释放node节点。
of_node_put(node);
函数原型：
extern struct device_node *of_get_next_parent(struct device_node *node);

参数from表示从哪一个节点开始寻找，传入NULL表示从根节点开始寻找。

h. of_get_next_child
取出下一个子节点。
函数原型：
extern struct device_node *of_get_next_child(const struct device_node *node, struct device_node *prev);

参数node表示父节点；
prev表示上一个子节点，设为NULL时表示想找到第1个子节点。

不断调用of_get_next_child时，不断更新prev参数，就可以得到所有的子节点。
i. of_get_next_available_child
取出下一个“可用”的子节点，有些节点的status是“disabled”，那就会跳过这些节点。
函数原型：
struct device_node *of_get_next_available_child(const struct device_node *node, struct device_node *prev);

参数node表示父节点；
prev表示上一个子节点，设为NULL时表示想找到第1个子节点。
j. of_get_child_by_name
根据名字取出子节点。
函数原型：
extern struct device_node *of_get_child_by_name(const struct device_node *node, const char *name);

参数node表示父节点；
name表示子节点的名字。

找到property

内核源码incldue/linux/of.h中声明了device_node的操作函数，当然也包括属性的操作函数。
a. of_find_property
找到节点中的属性。
函数原型：
extern struct property *of_find_property(const struct device_node *np,
const char *name,
int *lenp);

参数np表示节点，我们要在这个节点中找到名为name的属性。
lenp用来保存这个属性的长度，即它的值的长度。

在设备树中，节点大概是这样：

xxx_node {xxx_pp_name = “hello”;
};

上述节点中，“xxx_pp_name”就是属性的名字，值的长度是6。

获取property的值

struct property {char    *name;int   length;void *value;struct property *next;
#if defined(CONFIG_OF_DYNAMIC) || defined(CONFIG_SPARC)unsigned long _flags;
#endif
#if defined(CONFIG_OF_PROMTREE)unsigned int unique_id;
#endif
#if defined(CONFIG_OF_KOBJ)struct bin_attribute attr;
#endif
};

a. of_get_property
根据名字找到节点的属性，并且返回它的值。
函数原型：

/** Find a property with a given name for a given node* and return the value.*/
const void *of_get_property(const struct device_node *np, const char *name,int *lenp)

参数np表示节点，我们要在这个节点中找到名为name的属性，然后返回它的值。
lenp用来保存这个属性的长度，即它的值的长度。

b. of_property_count_elems_of_size
根据名字找到节点的属性，确定它的值有多少个元素(elem)。
函数原型：

* of_property_count_elems_of_size - Count the number of elements in a property** @np:       device node from which the property value is to be read.* @propname:   name of the property to be searched.* @elem_size:  size of the individual element** Search for a property in a device node and count the number of elements of* size elem_size in it. Returns number of elements on sucess, -EINVAL if the* property does not exist or its length does not match a multiple of elem_size* and -ENODATA if the property does not have a value.*/
int of_property_count_elems_of_size(const struct device_node *np,const char *propname, int elem_size)

参数np表示节点，我们要在这个节点中找到名为propname的属性，然后返回下列结果：
return prop->length / elem_size;

在设备树中，节点大概是这样：
xxx_node {xxx_pp_name = <0x50000000 1024>  <0x60000000  2048>;
};

调用of_property_count_elems_of_size(np, “xxx_pp_name”, 8)时，返回值是2；
调用of_property_count_elems_of_size(np, “xxx_pp_name”, 4)时，返回值是4。

c. 读整数u32/u64
函数原型为：

static inline int of_property_read_u32(const struct device_node *np,const char *propname,u32 *out_value);extern int of_property_read_u64(const struct device_node *np,const char *propname, u64 *out_value);

在设备树中，节点大概是这样：

xxx_node {name1 = <0x50000000>;name2 = <0x50000000  0x60000000>;
};

调用of_property_read_u32 (np, “name1”, &val)时，val将得到值0x50000000；
调用of_property_read_u64 (np, “name2”, &val)时，val将得到值0x0x6000000050000000。

d. 读某个整数u32/u64
函数原型为：

extern int of_property_read_u32_index(const struct device_node *np,const char *propname,u32 index, u32 *out_value);

在设备树中，节点大概是这样：

xxx_node {name2 = <0x50000000  0x60000000>;
};

调用of_property_read_u32 (np, “name2”, 1, &val)时，val将得到值0x0x60000000。

e. 读数组
函数原型为：

int of_property_read_variable_u8_array(const struct device_node *np,const char *propname, u8 *out_values,size_t sz_min, size_t sz_max);int of_property_read_variable_u16_array(const struct device_node *np,const char *propname, u16 *out_values,size_t sz_min, size_t sz_max);int of_property_read_variable_u32_array(const struct device_node *np,const char *propname, u32 *out_values,size_t sz_min, size_t sz_max);int of_property_read_variable_u64_array(const struct device_node *np,const char *propname, u64 *out_values,size_t sz_min, size_t sz_max);

在设备树中，节点大概是这样：

xxx_node {name2 = <0x50000012  0x60000034>;
};

上述例子中属性name2的值，长度为8。
调用of_property_read_variable_u8_array (np, “name2”, out_values, 1, 10)时，out_values中将会保存这8个字节： 0x12,0x00,0x00,0x50,0x34,0x00,0x00,0x60。
调用of_property_read_variable_u16_array (np, “name2”, out_values, 1, 10)时，out_values中将会保存这4个16位数值： 0x0012, 0x5000,0x0034,0x6000。

总之，这些函数要么能取到全部的数值，要么一个数值都取不到；
如果值的长度在sz_min和sz_max之间，就返回全部的数值；否则一个数值都不返回。
f. 读字符串
函数原型为：

int of_property_read_string(const struct device_node *np, const char *propname,const char **out_string);

返回节点np的属性(名为propname)的值，(*out_string)指向这个值，把它当作字符串。

7、怎么修改设备树文件

一个写得好的驱动程序, 它会尽量确定所用资源。
只把不能确定的资源留给设备树, 让设备树来指定。

根据原理图确定"驱动程序无法确定的硬件资源", 再在设备树文件中填写对应内容。
那么, 所填写内容的格式是什么?

1. 使用芯片厂家提供的工具
   有些芯片，厂家提供了对应的设备树生成工具，可以选择某个引脚用于某些功能，就可以自动生成设备树节点。
   你再把这些节点复制到内核的设备树文件里即可。

2. 看绑定文档
   内核文档 Documentation/devicetree/bindings/
   做得好的厂家也会提供设备树的说明文档

3. 参考同类型单板的设备树文件

4. 网上搜索

5. 实在没办法时, 只能去研究驱动源码

【嵌入式Linux】嵌入式Linux驱动开发基础知识之设备树模型相关推荐

1. 【嵌入式Linux】嵌入式Linux驱动开发基础知识之Pinctrl子系统和GPIO子系统的使用

   文章目录 前言 1.Pinctrl子系统 1.1.为什么有Pinctrl子系统 1.2.重要的概念 1.3.代码中怎么引用pinctrl 2.GPIO子系统 2.1.为什么有GPIO子系统 2.2.在 ...

2. 【嵌入式Linux】嵌入式Linux驱动开发基础知识之按键驱动框架

   文章目录 前言 1.APP怎么读取按键值 1.1.查询方式 1.2.休眠-唤醒方式 1.3.poll方式 1.3.异步通知方式 1.5. 驱动程序提供能力,不提供策略 2.按键驱动程序框架--查询方式 ...

3. 【嵌入式Linux】嵌入式Linux驱动开发基础知识之LED模板驱动程序的改造：设备树

   文章目录 前言 1.驱动的三种编写方法 2.怎么使用设备树写驱动程序 2.1.设备树节点要与platform_driver能匹配 2.2.修改platform_driver的源码 3.实验和调试技巧 ...

4. 【嵌入式Linux】嵌入式Linux驱动开发基础知识之总线设备驱动模型

   文章目录 前言 1.驱动编写的三种方法 1.1.传统写法 1.2.总线驱动模型 1.3.设备树驱动模型 2.Linux实现分离:Bus/Dev/Drv模型 2.1.Bus/Dev/Drv模型 2.2. ...

5. 【嵌入式Linux】嵌入式Linux驱动开发基础知识之驱动设计的思想：面向对象/分层/分离

   文章目录 前言 1.分离设计 驱动程序分析---程序分层 通用驱动程序---面向对象 个性化驱动程序---分离 APP 程序分析 前言 韦东山嵌入式Linux驱动开发基础知识学习笔记 文章中大多内容来 ...

6. 【嵌入式Linux】嵌入式Linux驱动开发基础知识之LED驱动框架--面向对象、分层设计思想

   文章目录 前言 1.LED驱动程序框架 1.1.对于LED驱动,我们想要什么样的接口? 1.2.LED驱动要怎么写,才能支持多个板子?分层写 1.3.程序分析 驱动程序 应用程序 Makefile 1 ...

7. 【嵌入式Linux】嵌入式Linux驱动开发基础知识之第一个驱动

   文章目录 前言 1.Hello驱动 1.1.APP打开的文件在内核中如何表示? 1.2.打开字符设备节点时,内核中也有对应的struct file 1.3.如何编写驱动程序? 1.4.驱动程序代码 1 ...

8. linux课程_【课程完结】嵌入式Linux应用/驱动开发基础知识两大篇章已全部录制完毕 共72集...

   完结撒花 <第四篇嵌入式Linux应用开发基础知识> <第五篇嵌入式Linux驱动开发基础知识> 两大篇章已全部录制完毕 共计 72 集 01 嵌入式Linux应用开发基础知识 ...

9. 驱动开发基础知识必修-（一）嵌入式开发板的启动过程

   驱动开发必修-嵌入式开发板的启动过程 简介 从打印日志入手 熟悉启动过程 1.执行u-boot程序 2.加载linux内核 3.挂载rootfs 4.加载完后 进入终端(命令输入行) UBOOT 1. ...

最新文章

1. “死”在拥挤赛道上的快递员工
2. java编程语言大全_JAVA编程语言的基础知识（一）
3. 【C++ grammar】重载、内联、变量作用域、带默认参数的函数
4. CodeForce 180 C ——Letter
5. 计算机音乐刚好遇见你乐谱,刚好遇见你钢琴谱-李玉刚｜因为我刚好遇见你
6. linux内核编译ccflag,Linux内核模块编译失败
7. iText导出pdf，poi导出excel并下载到客户端
8. yii2的分页和ajax分页
9. Linux：JDK配置
10. linux打开mid格式音乐,mid文件扩展名，mid文件怎么打开？
11. 爬取奇迹秀工具箱里面的文本和软件网盘链接
12. win7计算机里找不到硬盘,win7系统重装时提示＂找不到硬盘驱动器＂的解决方法...
13. 全国计算机高新技术作用,全国计算机高新技术考试证书作用是什么？
14. 作为一名程序员，我都收集了哪些好玩的神器工具？
15. 利用Modem实现远程双机互联
16. Xunity.autotranslator机翻unity引擎的游戏
17. C语言入门（一代小白被迫被拔苗助长）
18. 叫你如何查看QQ空间秘密发布者的发布时间
19. SQL中的外键约束及多表查询
20. 安兔兔V9版正式公测 热门旗舰机跑分变化很大

热门文章

1. cad画圆如何确定圆心_原来在CAD中画个圆也有这么多学问！你知道这些画圆的技巧吗？...
2. jlist动态添加元素后刷新_小米电视5再曝光：MEMC动态画质补偿技术
3. activex control test container 服务器正在运行中_Desktop Central服务器RCE漏洞在野攻击分析...
4. 实现微信小程序和支付宝小程序二维码合并
5. java swing 选项卡_java – 如何通过单击按钮在jTabbedPane中切换选项卡？
6. java 身份证地址提取籍贯_从身份证号码中提取信息，这些方法请收好
7. 多线程怎么保证数据安全_Python threading实现多线程 提高篇 线程同步，以及各种锁...
8. 基于RStudio 实现数据可视化之二
9. [NOI2002]荒岛野人 数论
10. 自动化测试---页面截图