DTS文件中的两个设备 - 以Xilinx Zynq-7000为例说明设备树的运用

xillybus_0:xillybus@50000000 {
compatible = "xlnx,xillybus-1.00.a";
reg = < 0x50000000 0x1000 >;
interrupts = < 0 59 1 >;
interrupt-parent = <&gic>;
xlnx,max-burst-len = <0x10>;
xlnx,native-data-width = <0x20>;
xlnx,slv-awidth = <0x20>;
xlnx,slv-dwidth = <0x20>;
xlnx,use-wstrb = <0x1>;
} ;
} ;

这里只列出原始DTS文件中的两个设备。

第一个条目：Zynq处理器的中断控制器。这个条目确保中断控制器被加载。注意它的标签是“gic"。这个标签被每个使用中断的设备引用。

终于可以讲述最有趣的部分了：以上说的这些如何与内核代码配合工作。

关于内核驱动
设备驱动加载和卸载时有四件事情会发生：
. 硬件存在时(比如在设备树中声明)，内核代码加载相应驱动
. 驱动需要了解设备的物理地址
. 驱动需要了解设备触发的中断号，用来注册中断处理函数。
. 一些特殊信息需要被获取

内核中有直接访问设备树的API，但是设备驱动使用专用接口更方便，这些专用接口受PCI/PCIe驱动的API影响。来看下xillybus_0条目，这是一个挂载于AXI总线上的典型逻辑设备。

标签和节点名
首先，标签("xillybus")和条目名()。标签可以省略，条目节点名的格式为()，最后在/sys下产生一个标准的条目(/sys/devices/axi.0/50000000.xillybus/)。，不过内核肯定不是从这里访问设备树的。

驱动自动加载
节点中的第一个赋值语句compatible = “xlnx,xillybus-1.00.a”是最重要的一句：它连接硬件和驱动。当内核在总线上扫描设备时(设备节点在设备树里挂在一个总线节点下)，内核检索"compatible"字段，然后将其字符串与一些已知的字符串比较。这个过程会在启动时自动发生两次：
. 内核启动时，编译进内核的驱动与设备树中某个"compatible"条目匹配
. 之后加载内核模块时，再触发一次匹配操作

内核驱动和"compatible"条目的连接由驱动代码中的一小段完成：
static struct of_device_id xillybus_of_match[] __devinitdata = {
{ .compatible = "xlnx,xillybus-1.00.a", },
{}
};

MODULE_DEVICE_TABLE(of,xillybus_of_match);

这段代码使得驱动与某一个"compatible"条目匹配。注意上面的id表中有一个空结构，用这个空意绪标志id表的结束。

在上段代码之后，一定有类似如下的一段代码：
static struct platform_driver xillybus_platform_driver = {
.probe = xilly_drv_probe,
.remove = xilly_drv_remove,
.driver = {
.name = "xillybus",
.owner = THIS_MODULE,
.of_match_table = xillybus_of_match,
},
};

platform_driver_register(&xillybus_platform_driver)在模块初始化里被调用。这个结构告诉内核，当驱动与某个硬件匹配时，xilly_drv_probe 被调用。

对内核来说，"compatible"字串需要与某个驱动名相同。”xlnx"前缀用于防止名字冲突。

另外，一个设备可以有多个"compatible"。因为一个设备可以有多个模块对应多个驱动。

可能会需要匹配硬件的名字和类型，但这不常用。

写内核模块时需要特别注意，自动加载机制依赖于/lib/modules/{kernel version}/modules.ofmap文件中的"compatible"字串，其他定义文件也在这个目录下。正确的方式是把*.ko文件复制到/lib/modules/{kernelversion}/kernel/drivers/下的相关目录中，然后：
depmod -a

获取资源信息

内核模块驱动加载之后，就开始把硬件资源管理起来，如读写寄存器、接收中断。

来看看设备树里的一条：
xillybus_0: xillybus@50000000 {
compatible = "xlnx,xillybus-1.00.a";
reg = < 0x50000000 0x1000 >;
interrupts = < 0 59 1 >;
interrupt-parent = <&gic>;

xlnx,max-burst-len =<0x10>;
xlnx,native-data-width = <0x20>;
xlnx,slv-awidth = <0x20>;
xlnx,slv-dwidth = <0x20>;
xlnx,use-wstrb = <0x1>;
} ;

驱动一般在探测函数里就取得了硬件内存段的所有权(探测函数就是probe指针指向的函数)。

来看看一个典型探测函数的框架：
static int __devinit xilly_drv_probe(struct platform_device *op)
{
const struct of_device_id *match;

match =of_match_device(xillybus_of_match, &op->dev);

if (!match)
return -EINVAL;

第一个操作就是检查probe是否作用在相关硬件上。

访问寄存器

下一步，分配一段内存并映射到虚拟内存中。
int rc = 0;
struct resource res;
void *registers;

rc = of_address_to_resource(&op->dev.of_node,0, &res);
if (rc) {
/* Fail */
}

if(!request_mem_region(res.start, resource_size(&res), "xillybus")){
/* Fail */
}

registers =of_iomap(op->dev.of_node, 0);

if (!registers) {
/* Fail */
}

of_address_to_resource() 在设备树中找到第一个"reg"，并将解析到的信息填充在"res"结构体里。这个例子里"reg = <0x50000000 0x1000 >”, 指的是分配一块起始物理地址是0x50000000，长度为0x1000字节的空间。of_address_to_resource()会设置res.start =0x50000000， res.end = 0x50000fff。

调用request_mem_region()是为了注册特殊的内存段。目的是避免两个驱动访问同一段寄存器空间而造成的冲突。resource_size()是个内联函数，返回segment的大小(此处是0x1000)。

of_iomap()函数是of_address_to_resource()和ioremap()的组合，本质上等效于ioremap(re.start, resource_size(&res)).确保物理段已经映射到虚拟内存中，函数返回内存段的虚拟地址空间起始地址。

显然，当模块卸载或某个错误发生时，这些操作都需要有恢复动作。

访问硬件寄存器请使用iowrite32(),ioread32()以及其他的函数和宏，而不要直接使用上面的"register"指针。

中断处理

这部分的驱动很简单，类似如下：
irq = irq_of_parse_and_map(op->dev.of_node, 0);

rc = request_irq(irq,xillybus_isr, 0, "xillybus", op->dev);

irq_of_parse_and_map()在设备树里查找中断的描述项，然后返回中断号，request_irq()将使用这个中断号来注册。第二个参数是0,表示使用设备树中的第一个中断。

设备树里面描述是：
interrupts = < 0 59 1 >;
interrupt-parent = <&gic>;

那么使用了这三个数据中的哪一个呢？

第一个0是一个标志，用于指示中断是否是SPI(共享中断，shared peripheral interrupt)。非0值表示它是SPI。事实上在Zynq硬件上，这些中断都是共享的，这里是为了方便才写0, 软件上认为它不共享。

第二个数据表示中断号。

第三个数字是中断类型，可以有如下值：

0 - 内核不改变它，开机或uboot设置它是什么样就什么样。
1 - 上升沿触发
4 - 电平触发，高电平表示来中断。
不允许有其他值，下降沿触发和低电平中断目前不支持，因为硬件不支持那些模式。如果需要这样的触发方式，就得在硬件上加一个非门。

值得注意的是第三个数字在设备树里通常都是0, 所以Linux内核不去改变中断模式。这通常意味着高电平触发。这也让驱动依赖于bootloader里的设置。

interrupt-parent 这一句，必须指向中断控制器&gic。如果反编译一个DTB文件，这里的&gic会被一个数字代替，通常是0x1。

Application-specific data
之前提过，设备树中是一些特殊信息，这样一个驱动可以管理数片类似的硬件。例如，一个LCD显示驱动，分辨率信息和物理尺寸可能出现在设备树中。串口信息要告诉驱动当前的时钟频率。

最简单的，最常用的形式，这个信息由一条赋值语句组成：
xlnx,slv-awidth = <0x20>;

"xlnx"前缀可以防止命名冲突。名字可以任意取，但最好能望文知意。这里的"xlnx"是使用软件自动生成设备树时加上的前缀。

为了抓取到这一条信息，代码可以这样写：
void *ptr;
ptr = of_get_property(op->dev.of_node, "xlnx,slv-awidth", NULL);

if (!ptr) {
/* Couldn't find the entry */
}

第三个参数NULL，是一个长度指针，可以返回数据的长度。

这条语句的值是一个数字：
int value;
value = be32_to_cpup(ptr);

be32_to_cpup读“ptr”指向的数据，从大端转到处理器的小端，然后就得到想要的数字了。

drivers/of/base.c中有大量读取这些信息的API。

总结
为一个外置写一个设备树entry很简单：
. 为"compatible"赋一个字符串"magicstring"，自动生成工具的生成格式一般是：名字+版本。
. 在数据手册里查看总线上设备的地址分配信息， 写一条 "reg=" 语句。
. "interrupt-parent=<&gic>"
. 中断号 "interrupt="
. 最后加上一些设备的自定义参数