头像在线制作网站wordpress+帖子置顶

1.编写设备树

cd arch/riscv/boot/dts/

再cd到厂商，例如下述内容。

2.编译设备树（dts->dtb）通过dtc命令来转换

3.解析设备树

例如上述内容，都是对设备树的解析。

这里重点说一下内核对设备树的处理吧，因为这个内容是设备树的重点了。

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

dts 在 PC 机上被编译为 dtb 文件；

u-boot 把 dtb 文件传给内核；

内核解析 dtb 文件，把每一个节点都转换为 device_node 结构体；

对于某些 device_node 结构体，会被转换为 platform_device 结构体。

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

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

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

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

含有特定 compatile 属性的节点的 子节点

如果一个节点的 compatile 属性，它的值是这 4 者之一： "simple

bus","simple-mfd","isa","arm,amba-bus", 那 么 它 的 子结点 ( 需 含

compatile 属性 ) 也可以转换为 platform_device 。

        总线 I2C 、 SPI 节点下的子节点： 不转换 为 platform_device。

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

比如以下的节点中：

/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 。

怎么转换为 platform_device

内核处理设备树的函数调用过程，这里不去分析；我们只需要得到如下结论：

platform_device 中含有 resource 数组 , 它来自 device_node 的 reg, interrupts 属性 ;

platform_device.dev.of_node 指向 device_node, 可以通过它获得其他属性;

platform_device 如何与 platform_driver 配对

最先比较：是否强制选择某个 driver

然后比较：设备树信息

接下来比较： platform_device_id

platform_device.name 和 platform_driver.driver.name

platform_driver.id_table 可能为空，

这 时 可 以 根 据 platform_driver.driver.name 来 寻 找 同 名 的

platform_device 。

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

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

firmware ”即开放固件。

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

处理 DTB

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

处理 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 的相关函数

处理 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

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 类型的资

源。

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

内核会把 dtb 文件解析出一系列的 device_node 结构体，我们可以直接访

问这些 device_node 。

内核源码 incldue/linux/of.h 中声明了 device_node 和属性 property 的操作函数

of_find_node_by_path of_find_node_by_name 等等都可以。