Linux设备树详解

桃扇骨 2021-07-26 23:19 386阅读 0赞

ARM Linux社区为什么要引入设备树

Linux之父Linus Torvalds闲来无事，在翻看ARM Linux代码的时候，有一天终于忍不住了。他在2011年3月17日的ARM Linux邮件列表中说道：“This whole ARM thing is a f\*cking pain in the ass”。这句话迫使ARM Linux社区引入了设备树。

Linus Torvalds为什么会发飙呢?而ARM Linux社区的牛人为什么又乖乖地听话了?你得首先理解Linux设备驱动框架中一个非常好的设计：设备信息和驱动分离。

为了什么说明设备信息和驱动分离的概念，先来看一个简单的模拟代码实例：

【例-1】实现一个代码，把要使用的信息简单写死在代码中：

int add() /*模拟驱动代码*/

return 3+5; /*模拟设备信息*/

优点：简单

缺点：一旦加数和被加数发生变化就得改代码

改进设计如下：

【例-2】实现一个代码，把要使用的信息和操作代码分离开来：

struct dev\{

int id;

int x;

int y;

\}; /*模拟设备信息结构*/

strcut drv\{

int id;

int (\*add)(struct dev \*info);

\}; /*模拟驱动结构*/

int add(struct dev \*info) /*模拟驱动代码*/

return info->x + info->y; /*模拟设备信息-通过参数传递进来*/

struct drv drv = \{

.id = 1,

.add = add,

\};

/*模拟设备信息*/

struct dev dev = \{

.id = 1,

.x = 3,

.y = 5,

\};

/*模拟总线初始化匹配设备信息和驱动代码*/

int bus()

if(dev.id == drv.id)\{

return drv.add(&dev);

…

优点：不管加数和被加数怎么变化，不需要修改代码，仅需要修改信息

缺点：结构比较复杂

那这个设备信息和驱动分离的设计跟驱动有什么关系呢?熟悉硬件编程的同学都知道，硬件一般的构成可以使用下图简单表述：

操作外设的驱动代码逻辑，只要硬件是一样的，就不会变化。但是外设挂到不同的主机上，可能会存在I/O地址的变化，如果有中断也是一样的，中断号也可能不同。这些I/O地址和中断号就是设备信息，使用这些信息来操作控制硬件的代码就是驱动。

如果采用【例-1】的设计方式，那么同一个硬件外设接到不同的主机，或是换了地址线/中断线，设备信息就变化了，得去修改驱动。但是采用【例-2】的方式进行设计，问题就迎刃而解：不管同样的外设硬件接到哪里或是那个平台，其驱动代码逻辑并不需要改动，而仅仅需要改变下设备信息，主要的就是I/O地址和中断号。

说了这么半天，跟引入设备树有什么关系呢?华清教学使用的开发板(A8/A9)都使用DM9000网卡芯片。DM9000驱动是开源的，在主线内核源码中就有。我们每次基于A8/A9板子移植的时候，DM9000驱动并没有修改过，仅仅是选配了下，主要的工作是在板级文件中添加了设备信息。DM9000驱动使用的是platform框架，所以添加了一份DM9000网卡芯片的platform\_device信息。问题来了，如果使用C代码的形式来描述设备信息，则在内核源码中，将会有多份DM9000的platform\_device设备信息，造成了内核代码冗余。

解决这个问题的办法就是引入设备树，改造【例-2】来说明设备树的作用。

【例-3】实现一个代码，不仅把要使用的信息和操作代码分离开来，而且信息不是C代码编写的，而是文本配置文件保存的：

struct dev\{

int id;

int x;

int y;

\}; /*模拟设备信息结构*/

strcut drv\{

int id;

int (\*add)(struct dev \*info);

\}; /*模拟驱动结构*/

int add(struct dev \*info) /*模拟驱动代码*/