你对Linux总线设备驱动框架是否了解_技术

Linux的设备驱动模型，或者说，Linux的设备驱动框架，都是同一个意思。应该这样理解，（Linux的设备）驱动框架，即某类设备对应的驱动的框架。

这里是“Linux总线设备驱动框架”，应该这样理解，（Linux的总线设备）驱动框架，即总线式设备对应的驱动的框架。

以下内容源于微信公众号：嵌入式企鹅圈。有格式内容上的修改，如有侵权，请告知删除。

1、总线

总线代表着同类设备需要共同遵守的工作时序，不同的总线对于物理电平的要求是不一样的，对于每个比特的电平维持宽度也是不一样，而总线上传递的命令也会有自己的格式约束。

如I2C总线、USB总线、PCI总线等等。

以I2C总线为例，在同一组I2C总线上连接着不同的I2C设备。

2、设备

设备代表真实的、具体的物理器件，在软件上用器件的独特的参数属性来代表该器件。

如I2C总线上连接的I2C从设备都有一个标识自己的设备地址，由这个设备地址来确定主设备发过来的命令是否该由它来响应。

3、驱动

（1）驱动代表着 *** 作设备的方式和流程。对于应用来说，应用程序open打开设备后，接着就read访问这个设备，驱动就是如何实现这个访问的具体的过程。

（2）驱动主要包括两部分

第一是通过对SOC的控制寄存器进行编程，按总线要求输出时序和命令，成功地与外围设备进行交互；

第二是对第一步中得到的数据进行处理，并向应用层提供特定格式的数据。

（3）注意点

不同总线的设备的驱动过程是不一样的，比如，USB鼠标的驱动和I2C EEPROM的读时序肯定是不一样的，访问时序的产生和控制也是驱动的一部分。

同种总线不同设备类型的设备驱动也是不一样的。如I2C电容屏设备，对于读read来说就是在datasheet规定的地址上去读触摸点的X和Y坐标，而I2C EEPROM的读 *** 作是读取存储的内容，两种设备的datasheet是不一样的，驱动自然是不一样的。

同种总线的同类设备的设备驱动也可能是不一样的。例如对于触摸屏，TSC2003只支持单点触控，而FT5X06支持多点触摸。在获取触控坐标时，前者只需要获得一个点的数据就返回，而后者则需要先获得当前有几个点的数据，然后再把所有点的坐标都读出来。

（3）在驱动的 *** 作中，一般都会用到GPIO和中断等硬件资源。

如SDA和SCL会连接到SOC芯片的具体的两个GPIO引脚，而I2C读写时一般都采用中断控制的方式（查询读写是否完成比较低效，浪费CPU）。

如果我们在驱动中直接针对具体的引脚来编程，那这个驱动的平台可移植性就比较差，因为不同的产品设计可能引脚不一样。

为了提高驱动的可移植性，Linux把驱动要用到的GPIO和中断等资源剥离给设备去管理。

即在设备里面包含其自己的设备属性，还包括了其连接到SOC所用到的资源。而驱动重点关注 *** 作的流程和方法。

4、再谈总线

第1点中谈到的总线只是物理意义上的表述，即总线就是在行业中制定出标准，明确规定时序的格式。我们在第3点中谈到，在软件层面上，时序的产生和控制由驱动负责。那我们要思考在软件层面上，总线的职责是什么？

总线在软件层面主要是负责管理设备和驱动。

设备要让系统感知自己的存在，设备需要向总线注册自己；同样地，驱动要让系统感知自己的存在，也需要向总线注册自己。设备和驱动在初始化时必须要明确自己是哪种总线的，I2C设备和驱动不能向USB总线注册吧。

多个设备和多个驱动都注册到同一个总线上，那设备怎么找到最适合自己的驱动呢，或者说驱动怎么找到其所支持的设备呢？

这个也是由总线负责，总线就像是一个红娘，负责在设备和驱动中牵线。

设备会向总线提出自己对驱动的条件（最简单的也是最精确的就是指定对方的名字了），而驱动也会向总线告知自己能够支持的设备的条件（一般是型号ID等，最简单的也可以是设备的名字）。

设备在注册的时候，总线就会遍历注册在它上面的驱动，找到最适合这个设备的驱动，然后填入设备的结构成员中；驱动注册的时候，总线也会遍历注册在其之上的设备，找到其支持的设备（可以是多个，驱动和设备的关系是1:N），并将设备填入驱动的支持列表中。我们称总线这个牵线的行为是match。牵好线之后，设备和驱动之间的交互红娘可不管了。

总线在匹配设备和驱动之后驱动要考虑一个这样的问题，设备对应的软件数据结构代表着静态的信息，真实的物理设备此时是否正常还不一定，因此驱动需要探测这个设备是否正常。我们称这个行为为probe，至于如何探测，那是驱动才知道干的事情，总线只管吩咐得了。所以我们可以猜测在总线的管理代码中会有这样的逻辑：

[cpp] view plain copy

if(match(device, driver) == OK)

driver->probe();

5、再谈驱动

假设设备正常，探测成功，这时就代表应用程序可以通过驱动来访问 *** 作这个设备了。事实上是这样吗？仔细想想还少了什么东西。应用层通过什么来访问 *** 作这个设备？想起来吗？“嵌入式企鹅圈”的第一篇文章《Linux字符设备驱动剖析》中曾清晰地分析了Linux字符设备驱动的开发和访问过程，在开篇即提到应用程序如何访问设备：

[cpp] view plain copy

int fd = open(“设备文件名”);

read(fd, buf, len);

write(fd, buf, len);

这个应用程序涉及的驱动两个问题，一是设备文件名从何而来；二是应用层的API如open、read和write等对应驱动的哪些接口，是如何对应的。这些都是驱动要解决的问题。

总线匹配设备和驱动之后，驱动探测到设备正常，这时驱动已经做好准备让应用层来差遣，但是设备文件名如果没有创建，应用程序也不知从何入手。所以在驱动的probe探测成功之后，立即创建设备文件是最合适的时机。通过sysfs文件系统、uevent事件通知机制、后台应用服务mdev程序，三者的配合，在/dev目录创建对应的设备文件。

驱动要提供应用层API如open、read、write、ioctl等 *** 作的对应接口，而且这些接口要向系统报备（注册）自己，否则系统也不知道怎么调用驱动，因为在上面的描述中从始至终都是设备、驱动和总线三个东西在唱戏，它们跟系统，严格意义是跟Linux的虚拟文件系统和设备文件系统还没建立起关系来。

对于第二个问题，驱动要包括以下步骤：

设备要提供（struct file_operaTIon结构所定义的）接口（即函数的具体实现）。这些接口将会对应到应用层的设备访问 *** 作（即应用层的API）。在这些接口中，其会根据第3点中提到的需求去完成自己的 *** 作任务。

[cpp] view plain copy

struct file_operaTIons

{

int (*open) (struct inode *, struct file *);

int (*ioctl) (struct inode *, struct file *, ...);

ssize_t (*read) (struct file *, char __user *,...);

ssize_t (*write) (struct file *, const char __user *, ...);

…

}

应用层正常的访问流程是：应用层 *** 作->虚拟文件系统 *** 作->具体文件系统 *** 作->具体设备驱动的 *** 作。