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

    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 EEP     ROM   的读时序肯定是不一样的,访问时序的产生和控制也是驱动的一部分。

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

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

(3)在驱动的操作中,一般都会用到G     PI   O和中断等硬件资源。

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

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

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

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

4、再谈总线

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

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

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

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

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

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

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

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

[cpp] view pl     ai   n copy

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

driver->probe();

5、再谈驱动

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

[cpp] view plain copy

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

read(fd, buf, len);

wri     te   (fd, buf, len);


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

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

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

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

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

[cpp] view plain copy

struct file_opera  TI ons

{

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 *, ...);

}

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

虚拟文件系统VFS系统已经存在;

具体文件系统操作对于字符设备来说非常简单,我们姑且认为是字符设备文件系统devfs;

此时字符设备驱动要做的是,将自己的struct file_opera  TI ons向devfs注册(对于字符设备驱动,使用的是cdev_add函数)。

详细的分析过程可以参考《Linux字符设备驱动剖析》。

所以我们可以想象在驱动driver的结构体中有一个probe接口(即Driver->probe()),驱动要实现这个接口。这个probe接口要完成的工作包括:

探测设备是否正常;

cdev_add(struct file_opera  TI ons),注册操作接口;

device_create(),创建设备文件。

6、继续谈驱动

做好以上准备,剩下的就是等着应用程序来访问操作了。这里阐述一下设备驱动的struct file_opera  TI ons中的接口都要做什么。挑几个主要的来讲讲。

(1)open一般会进行驱动的初始化

可能包括硬件的初始化、软件的初始化。

我们在第3点谈驱动的时候,曾说明为了让驱动更具移植性,会将驱动driver过程中使用到的具体GPIO和IRQ中断等资源列入设备device的属性内容。这时device数据结构中断的GPIO和IRQ的标识都来源于SOC datasheet的物理地址定义。

Linux在运行过程中,会使用SOC的MMU内存管理单元来管理自己的内存,会将内存分为两部分,内核空间(3G-4G)和用户空间(0-3G)。

这两块地址空间都是虚拟线性地址空间,即程序编译链接之后对应的地址空间;

虚拟地址空间需要通过MMU和页表来映射到实际的物理内存空间,才能最终访问到物理内存和物理IO等资源。

而驱动操作硬件都处在内核空间,在open函数中主要包括以下操作:

(通过系统提供的资源获取接口)获取到GPIO和IRQ等资源;

通过ioremap接口将GPIO和IRQ从物理地址空间映射到3G-4G中的虚拟地址空间;

根据具体的控制规格设置GPIO和IRQ相关的寄存器。

以上初始化的动作可能会出现在驱动probe探测的代码中,那open的接口可以什么都不做。

(2)read

驱动的open如果成功,那整个访问流程已经成功一大半了,因为open的流程足够漫长和复杂。

而read只是从(用户空间的fd文件句柄中)找到所属进程的file文件结构,然后即可找出file_operations->read,其即是驱动的read接口。

那就按着外网设备的规格和总线的时候进行操作,达到read设备的目的。Write也一样。

(3)ioctl一般是对设备进行参数设置。



89
9
0
70

相关资讯

  1. 1、欧司朗OstuneLED显色指数超过90,为目前汽车应用领域最高4570
  2. 2、半导体材料的实际运用,新型有机半导体材料的介绍3852
  3. 3、光栅式传感器介绍及工作原理3185
  4. 4、FOTRIC推出可支持全辐射热像视频流的热像仪4098
  5. 5、电阻电位器行业十年回顾与展望4747
  6. 6、华为PoleStar解决方案赢得亚洲移动大奖1736
  7. 7、韩国研发全球首个三进制半导体或影响AI/自动驾驶汽车等应用4687
  8. 8、中科大实现具有亚纳秒信息写入速度的超快原型存储器3828
  9. 9、微软Win1020H2功能更新将发布,修复了多个程序BUG1178
  10. 10、高通并购恩智浦即将迎来大结局?1764
全部评论(0)
我也有话说
0
收藏
点赞
顶部