Linux驱动开发-03-驱动程序的设计思想

1. 说明

简单介绍一下linux驱动设计的思想发展

2. 从一个设备说起

在夸夸其谈之前，先看下I2C设备的结构。图摘自韦东山大大的《嵌入式linux应用开发完全手册》

80C51里有一个I2C控制器，其实也就是一组寄存器，用来控制I2C的数据线和信号线上的信号（高低电平）。
I2C设备就是挂载I2C总线的设备，或者说负载，比如RAM PCF8570,比如EEPROM AT24C02等

这里可以看到I2C控制器和CPU直接相连，可以认为是CPU的设备，EEPROM是I2C的设备，完整的I2C程序就要包括驱动I2C控制器（用来产生信号）的驱动程序，和I2C设备（如EEPROM）的驱动程序。

3. 驱动的设计思想

3.1 设备模型之前

下面来说驱动程序的设计思想，先从最简单的情况说起。一些简单的驱动程序，比如globalmem（宋宝华《Linux 设备驱动开发详解》中的示例设备），不像前面说的I2C结构那么复杂，只用按部就班实现就行了。设备信息（全局内存的地址）在驱动中直接编码，驱动也只适配这一个设备，但是一旦回过头想，隐隐觉得这样写是不好的：设备信息硬编码，驱动程序不能通用，要是一个驱动能给多个globalmem使用就好了。

3.2 设备模型提出

内核在2.6提出了设备模型（设备-总线-驱动）来实现设备驱动分层，同时形成设备链表、驱动链表。这显然是使用了分层和面向对象思想。设备是一个对象，驱动是一个对象，认为设备是挂载总线上的，总线也是一个对象。

因为不是所有的设备都挂载总线上的，比如I2C的控制器、USB控制器等，它是直接集成在SOC中和CPU直接相连的。为了统一设备模型，就提出了一个虚拟总线-平台总线（platform），相应的I2C控制器就成为platform_device。

这样globalmem设备就成为platform_device,globalmem驱动就成为platform_driver，两者的匹配通过总线的platform_match函数来匹配——当然需要驱动和设备的有一致的信息（比如name）。

为了解决像I2C这样相对复杂的设备驱动问题，又产生了一个I2C核心层（I2C子系统，还有其他子系统：USB子系统、网络子系统、MMC子系统等），核心层提供了I2C控制器的驱动、I2C设备驱动的注册销毁、I2C的通信方法（算法）等功能。I2C的控制器驱动也就是I2C总线驱动，使用I2C核心层提供的接口来控制I2C控制器实现特殊的时序、协议、仲裁等。I2C设备的驱动是面向I2C设备的，根据I2C设备的不同使用I2C总线驱动中提供的方法来进行I2C设备的初始化读写等操作。

3.3 设备树

为了解决设备信息硬编码的问题，Linux内核3.7提出了设备树的概念，把设备的硬件信息如硬件地址、中断地址、名字等写在设备树里。这样驱动移植时只用修改设备树的对应的配置文件即可。这就解决了最开始提出的设备信息硬编码的问题。个人觉得Linux采用设备树的机制有点晚，早就该用了，毕竟把硬件信息写在代码里早就为人不齿了。。

4. 一些好文

实战经验吐血推荐：怎样在Linux环境下轻松实现基于I2C总线的EEPROM驱动程序

Linux I2C驱动

Linux I2C驱动完全分析（一）