title: 内核对设备树的操作
date: 2019/4/28 18:02:18
toc: true
内核对设备树的操作
哪些节点会被转换
以前的程序platform
中的driver
去匹配dev
中的资源文件
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
。/ { 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解析中有类似的分析
// 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;
粗略的流程如下
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
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(含有递归)
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
在上面的章节中,我们需要知道对于i2c
的clinet
,并没有生成platform dev
节点,这需要i2c
驱动的具体处理生成clinet
,也就是我们在添加adapt
的时候,需要根据设备树去创建clinet
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
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的流程还没有学习过,先放上老师的框架
/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);
}
匹配流程
我们先看dev
和driver
的注册流程,可以看到最后的匹配函数是driver_match_device
// 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
这个匹配函数也是属于总线匹配的一种,可以看到这个结构,具体为什么是这个结构,需要去看以前的知识点了
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
// 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);
总结一下
- 比较 platform_dev.driver_override 和 platform_driver.drv->name
- 比较 platform_dev.dev.of_node的compatible属性 和 platform_driver.drv->of_match_table
- 比较 platform_dev.name 和 platform_driver.id_table
- 比较 platform_dev.name 和 platform_driver.drv->name
下面老师的这个图很形象具体了
内核操作设备树函数
内核中设备树存在3个形式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的相关函数
example
// 官方设备树规格书里面的设备示例
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
of_platform.h // 把device_node转换为platform_device时用到的函数,
example
/* 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
根文件系统查看设备树
-
dtb文件
hexdump -C /sys/firmware/fdt
-
目录形式展示
/sys/firmware/devicetree/base
-
具体的
dev
文件被创建,如果是通过设备树创建的,则在具体的dev
下有of_node
这个文件夹,这个of_node
是指向2中/sys/firmware/devicetree
中具体的设备目录/sys/devices/platform /sys/devices/platform/<设备名>/of_node > /sys/firmware/devicetree/base