内核对设备树的操作

内核对设备树的操作

哪些节点会被转换#

以前的程序platform中的driver去匹配dev中的资源文件

Copy
struct resource { resource_size_t start; resource_size_t end; const char *name; unsigned long flags; unsigned long desc; struct resource *parent, *sibling, *child; }; //类型有这么几种 #define IORESOURCE_TYPE_BITS 0x00001f00 /* Resource type */ #define IORESOURCE_IO 0x00000100 /* PCI/ISA I/O ports */ #define IORESOURCE_MEM 0x00000200 #define IORESOURCE_REG 0x00000300 /* Register offsets */ #define IORESOURCE_IRQ 0x00000400 #define IORESOURCE_DMA 0x00000800 #define IORESOURCE_BUS 0x00001000

那么节点中的各种描述怎么转换为resource结构呢?

  • 带有compatible属性的根下的子节点
  • 其他子节点带有compatible属性值为"simple-bus","simple-mfd","isa","arm,amba-bus "

不会转换的节点

  • 根节点 ,虽然带有compatible属性,但这个是为了最开始的机型匹配

  • 比如在i2c中,at24c02节点不会被转换, 它被如何处理完全由父节点的platform_driver决定, 一般是被创建为一个i2c_client

    Copy
    / { 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>; }; }; };

转换入口#

of_platform_default_populate_init 这个函数是有特殊段属性的一个函数,会在kernel初始化的阶段来调用,具体这个段属性在以前的kernel解析中有类似的分析

Copy
// drivers/of/platform.c) of_platform_default_populate_init arch_initcall_sync(of_platform_default_populate_init); #define arch_initcall_sync(fn) __define_initcall(fn, 3s) #define __define_initcall(fn, id) ___define_initcall(fn, id, .initcall##id) #define ___define_initcall(fn, id, __sec) \ static initcall_t __initcall_##fn##id __used \ __attribute__((__section__(#__sec ".init"))) = fn;

粗略的流程如下

Copy
start_kernel // init/main.c rest_init(); pid = kernel_thread(kernel_init, NULL, CLONE_FS); kernel_init kernel_init_freeable(); do_basic_setup(); do_initcalls(); for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++) do_initcall_level(level); // 比如 do_initcall_level(3) for (fn = initcall_levels[3]; fn < initcall_levels[3+1]; fn++) do_one_initcall(initcall_from_entry(fn)); // 就是调用"arch_initcall_sync(fn)"中定义的fn函数

节点转换流程#

of_platform_default_populate_init#

Copy
of_platform_default_populate_init of_platform_default_populate(NULL, NULL, NULL); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL) for_each_child_of_node(root, child) { rc = of_platform_bus_create(child, matches, lookup, parent, true); // 调用过程看下面 dev = of_device_alloc(np, bus_id, parent); // 根据device_node节点的属性设置platform_device的resource if (rc) { of_node_put(child); break; } }

of_platform_bus_create(含有递归)#

Copy
of_platform_default_populate>of_platform_populate(...of_default_bus_match_table..) //of_default_bus_match_table 表示哪些子节点要被转换 for_each_child_of_node { ------- of_platform_bus_create(...) | { | of_platform_device_create_pdata(...) | { | of_device_alloc(...) | { | // 分配一个 platform_device ,里面会包含了资源文件的描述 | dev = platform_device_alloc("", PLATFORM_DEVID_NONE); | // 计算内存(包括IORESOURCE_MEM IORESOURCE_IO ) 中断 资源 | of_address_to_resource(..) | __of_address_to_resource() | of_irq_count(..) | kcalloc(...sizeof(resource)...) | // 设置具体的资源描述 | dev->num_resources = num_reg + num_irq; | dev->resource = res; | dev->dev.parent = parent ? : &platform_bus; | // 设置总线名字 | dev_set_name | of_device_make_bus_id | | } | dev->dev.bus = &platform_bus_type; | // 添加到dev 链表 | of_device_add(...) | device_add(...) | | | } | | for_each_child_of_node(bus, child) | { |-递归子节点---of_platform_bus_create(...)//这里就是递归了 } } of_node_put(...) }

I2C_clinet#

在上面的章节中,我们需要知道对于i2cclinet,并没有生成platform dev节点,这需要i2c驱动的具体处理生成clinet,也就是我们在添加adapt的时候,需要根据设备树去创建clinet

Copy
i2c_add_numbered_adapter // drivers/i2c/i2c-core-base.c __i2c_add_numbered_adapter i2c_register_adapter of_i2c_register_devices(adap); // drivers/i2c/i2c-core-of.c for_each_available_child_of_node(bus, node) { client = of_i2c_register_device(adap, node); client = i2c_new_device(adap, &info); // 设备树中的i2c子节点被转换为i2c_clien

of_i2c_register_devices

Copy
of_i2c_register_devices { // 寻找到节点名字为 i2c-bus of_get_child_by_name(adap->dev.of_node, "i2c-bus"); of_i2c_register_device(...) { of_i2c_get_board_info(...) { of_modalias_node(...) { // 判断 compatible 属性 of_get_property(node, "compatible", &cplen); } of_property_read_u32(node, "reg", &addr); of_property_read_bool(node, "host-notify") of_get_property(node, "wakeup-source", NULL) } i2c_new_device(..) } }

SPI#

SPI的流程还没有学习过,先放上老师的框架

Copy
/spi节点一般表示spi控制器, 它会被转换为platform_device, 在内核中有对应的platform_driver; platform_driver的probe函数中会调用spi_register_master, 即spi_register_controller: spi_register_controller // drivers/spi/spi.c of_register_spi_devices // drivers/spi/spi.c for_each_available_child_of_node(ctlr->dev.of_node, nc) { spi = of_register_spi_device(ctlr, nc); // 设备树中的spi子节点被转换为spi_device spi = spi_alloc_device(ctlr); rc = of_spi_parse_dt(ctlr, spi, nc); rc = spi_add_device(spi); }

匹配流程#

我们先看devdriver的注册流程,可以看到最后的匹配函数是driver_match_device

Copy
// drivers/base/platform.c a. 注册 platform_driver 的过程: platform_driver_register __platform_driver_register drv->driver.probe = platform_drv_probe; driver_register bus_add_driver klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers); // 把 platform_driver 放入 platform_bus_type 的driver链表中 driver_attach bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); // 对于plarform_bus_type下的每一个设备, 调用__driver_attach __driver_attach ret = driver_match_device(drv, dev); // 判断dev和drv是否匹配成功 return drv->bus->match ? drv->bus->match(dev, drv) : 1; // 调用 platform_bus_type.match driver_probe_device(drv, dev); really_probe drv->probe // platform_drv_probe platform_drv_probe struct platform_driver *drv = to_platform_driver(_dev->driver); drv->probe b. 注册 platform_device 的过程: platform_device_register platform_device_add device_add bus_add_device klist_add_tail(&dev->p->knode_bus, &bus->p->klist_devices); // 把 platform_device 放入 platform_bus_type的device链表中 bus_probe_device(dev); device_initial_probe __device_attach ret = bus_for_each_drv(dev->bus, NULL, &data, __device_attach_driver); // // 对于plarform_bus_type下的每一个driver, 调用 __device_attach_driver __device_attach_driver ret = driver_match_device(drv, dev); return drv->bus->match ? drv->bus->match(dev, drv) : 1; // 调用platform_bus_type.match driver_probe_device

driver_match_device#

这个匹配函数也是属于总线匹配的一种,可以看到这个结构,具体为什么是这个结构,需要去看以前的知识点了

Copy
struct bus_type platform_bus_type = { .name = "platform", .dev_groups = platform_dev_groups, .match = platform_match, .uevent = platform_uevent, .dma_configure = platform_dma_configure, .pm = &platform_dev_pm_ops, };

所以最终就是platform_match

platform_match#

Copy
// 1. 匹配 pdev->driver_override 和 drv->name /* When driver_override is set, only bind to the matching driver */ if (pdev->driver_override) return !strcmp(pdev->driver_override, drv->name); // 2. 匹配 dev->of_node->properties中的compatible属性 drv->of_match_table /* Attempt an OF style match first */ if (of_driver_match_device(dev, drv)) of_match_device(drv->of_match_table, dev) of_match_node(matches, dev->of_node) __of_match_node(matches, node) for (; matches->name[0] || matches->type[0] || matches->compatible[0]; matches++) __of_device_is_compatible //寻找匹配的 __of_find_property(device, "compatible", NULL) if (score > best_score) { //寻找到最匹配的 best_match = matches; best_score = score; } // 这个比较复杂,在arm基本不用 /* Then try ACPI style match */ if (acpi_driver_match_device(dev, drv)) return 1; // 4. 匹配 pdrv->id_table 和 pdev-name if (pdrv->id_table) return platform_match_id(pdrv->id_table, pdev) != NULL; // 5. 匹配 pdev->name 和 drv->name return (strcmp(pdev->name, drv->name) == 0);

总结一下

  1. 比较 platform_dev.driver_override 和 platform_driver.drv->name
  2. 比较 platform_dev.dev.of_node的compatible属性 和 platform_driver.drv->of_match_table
  3. 比较 platform_dev.name 和 platform_driver.id_table
  4. 比较 platform_dev.name 和 platform_driver.drv->name

下面老师的这个图很形象具体了

mark

内核操作设备树函数#

内核中设备树存在3个形式dtb -> device_node -> platform_device

处理DTB#

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

处理device_node#

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

example

Copy
// 官方设备树规格书里面的设备示例 soc { #address-cells = <1>; #size-cells = <1>; serial { compatible = "ns16550"; reg = <0x4600 0x100>; clock-frequency = <0>; interrupts = <0xA 0x8>; interrupt-parent = <&ipic>; }; }; //解析方法 int of_irq_parse_one(struct device_node *device, int index, struct of_phandle_args *out_irq); //或者使用 int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq);

处理 platform_device#

Copy
of_platform.h // 把device_node转换为platform_device时用到的函数,

example

Copy
/* Platform drivers register/unregister */ extern struct platform_device *of_device_alloc(struct device_node *np, const char *bus_id, struct device *parent); //这个函数转换节点为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

根文件系统查看设备树#

  1. dtb文件

    Copy
    hexdump -C /sys/firmware/fdt
  2. 目录形式展示

    Copy
    /sys/firmware/devicetree/base
  3. 具体的dev文件被创建,如果是通过设备树创建的,则在具体的dev下有of_node这个文件夹,这个of_node是指向2中/sys/firmware/devicetree中具体的设备目录

    Copy
    /sys/devices/platform /sys/devices/platform/<设备名>/of_node > /sys/firmware/devicetree/base

参考链接#

http://wiki.100ask.org

posted @   zongzi10010  阅读(1418)  评论(0编辑  收藏  举报
编辑推荐:
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
阅读排行:
· 分享一个免费、快速、无限量使用的满血 DeepSeek R1 模型,支持深度思考和联网搜索!
· 基于 Docker 搭建 FRP 内网穿透开源项目(很简单哒)
· ollama系列1:轻松3步本地部署deepseek,普通电脑可用
· 按钮权限的设计及实现
· 【杂谈】分布式事务——高大上的无用知识?
点击右上角即可分享
微信分享提示
CONTENTS