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

前言

韦东山嵌入式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/ 
 ;
/ {
    [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 
#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;
#endif
	unsigned 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:
 * "", where  is a short description of the type of
 * device, like "pci" or "floppy", and  is the enumerated
 * instance of the device, like '0' or '42'.  Driver IDs are simply
 * "".  So, extract the  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. 实在没办法时, 只能去研究驱动源码