Linux驱动分离与分层的简介

一.  简介

我们在前面几章编写的设备驱动都非常的简单，都是对 IO 进行最简单的读写操作。

像 I2C 、SPI 、 LCD 等这些复杂外设的驱动就不能这么去写了， Linux 系统要考虑到驱动的可重用性，因 此，提出了驱动的分离与分层这样的软件思路，在这个思路下诞生了我们将来最常打交道的 platform 设备驱动，也叫做平台设备驱动。

接下来我们就来学习一下 Linux 下的驱动分离与分层， 以及 platform 框架下的设备驱动该如何编写。

二.  Linux驱动分离与分层的简介

对于 Linux 这样一个成熟、庞大、复杂的操作系统，代码的重用性非常重要，否则的话，就会在 Linux 内核中存在大量无意义的重复代码。 尤其是驱动程序，因为驱动程序占用了 Linux 内核代码量的大头，如果不对驱动程序加以管理，任由重复的代码肆意增加，那么用不了多久 Linux 内核的文件数量就庞大到无法接受的地步。

假如，现在有三个平台 A 、 B 和 C ，这三个平台 ( 这里的平台说的是 SOC，即芯片) 上都有 MPU6050 这 个 I2C 接口的六轴传感器，按照我们写裸机 I2C 驱动的时候的思路，每个平台都有一个 MPU6050 的驱动，因此，编写出来的最简单的驱动框架如下图 所示：

从上图 可以看出，每种平台下都有一个主机驱动和设备驱动，主机驱动肯定是必须 要的，毕竟不同的平台其 I2C 控制器不同。但是右侧的设备驱动就没必要每个平台都写一个， 因为不管对于那个 SOC 来说， MPU6050 都是一样，通过 I2C 接口读写数据就行了，只需要一 个 MPU6050 的驱动程序即可。 显然在 Linux 驱 动程序中这种写法是不推荐的。

最好的做法就是每个平台的 I2C 控制器都提供一个统一的接口 ( 也叫做主机驱动 ) ，每个设备也只提供一个驱动程序 ( 设备驱动 ) ，每个设备通过统一的 I2C 接口驱动来访问，这样就可以大大简化驱动文件，例如，上图 中三种平台下的 MPU6050 驱动 框架就可以简化下图 所示：

1. 驱动的分隔

实际的 I2C 驱动设备肯定有很多种，不止 MPU6050 这一个，那么实际的驱动架构如下图 所示：

这个就是驱动的分隔，也就是将主机驱动和设备驱动分隔开来，比如 I2C 、 SPI 等等都会采用驱动分隔的方式来简化驱动的开发。

在实际的驱动开发中，一般 I2C 主机控制器驱动已经由半导体厂家编写好了，而设备驱动一般也由设备器件的厂家编写好了，我们只需要提供设备信 息即可，例如， I2C 设备的话，提供设备连接到了哪个 I2C 接口上， I2C 的速度是多少等等。

相当于将设备信息从设备驱动中剥离开来，驱动使用标准方法去获取到设备信息 ( 比如，从设备树中获 取到设备信息 ) ，然后根据获取到的设备信息来初始化设备。

这样就相当于驱动只负责驱动，设备只负责设备，想办法将两者进行匹配即可。

这个就是 Linux 中的总线(bus)、驱动(driver)和设备(device) 模型，也就是常说的驱动分离。

总线就是驱动和设备信息的月老，负责给两者牵线 搭桥，如下图 所示：

当我们向系统注册一个驱动的时候，总线就会在右侧的设备中查找，看看有没有与之匹配的设备，如果有的话就将两者联系起来。同样的，当向系统中注册一个设备的时候，总线就会在左侧的驱动中查找看有没有与之匹配的设备，有的话也联系起来。

Linux 内核中大量的驱动程序都采用总线、驱动和设备模式。

2.   驱动的分层

大家应该听说过网络的 7 层模型，不同的层负责不同的内容。

同样的， Linux 下的驱动往往也是分层的，分层的目 的也是为了在不同的层处理不同的内容。

以其他书籍或者资料常常使用到的 input( 输入子系统， 后面会有专门的章节详细的讲解 ) 为例，简单介绍一下驱动的分层。

input 子系统负责管理所有 跟输入有关的驱动，包括键盘、鼠标、触摸等。

最底层的就是设备原始驱动，负责获取输入设 备的原始值，获取到的输入事件上报给 input 核心层。

input 核心层会处理各种 IO 模型，并且提 供 file_operations 操作集合。

我们在编写输入设备驱动的时候只需要处理好输入事件的上报即 可，至于如何处理这些上报的输入事件那是上层去考虑的，我们不用管。

可以看出借助分层模 型可以极大的简化我们的驱动编写，对于驱动编写来说非常的友好。