SPI学习(四):SPI软件框架

写在前面：要学习SPI，首先还是要了解SPI的软件架构，我了解到的操作SPI的软件，一种是操作寄存器的方式，一种是使用Linux标准化的方式

内容参考以下博客及内核文档linux-4.14.99\linux-4.14.99\Documentation\spi

https://blog.csdn.net/xiezhi123456/article/details/80115970

一.SPI驱动的软件架构

在内核SPI驱动的软件架构中，进行了合理的分层和抽象，如下图所示:

1、SPI控制器驱动程序

SPI控制器不用关心设备的具体功能，它只负责把上层协议驱动准备好的数据按SPI总线的时序要求发送给SPI设备，同时把从设备收到的数据返回给上层的协议驱动，因此，内核把SPI控制器的驱动程序独立出来。SPI控制器驱动负责控制具体的控制器硬件，诸如DMA和中断操作等，因为多个上层的协议驱动可能会通过控制器请求数据传输操作，所以，SPI控制器驱动同时也要负责对这些请求进行队列管理，保证先进先出原则。

见controller drivers与蓝色框框的说明，内核中有很多原生的controller drivers的代码，在drivers\spi目录下

2、SPI通用接口封装层

为简化SPI驱动程序编写工作，同时也为了降低协议驱动程序和控制器驱动程序的耦合度，Linux内核把控制器驱动和协议驱动的一些通用操作封装成标准的接口，加上一些通用的逻辑处理操作，组成了SPI通用接口封装层。好处是，对于控制器驱动程序，只要实现标准的接口回调API，并把它注册到通用接口层即可，无需直接和协议层驱动程序进行交互。而对于协议层驱动来说，只需通过通用接口层提供的API即可完成设备和驱动的注册，并通过通用接口层的API完成数据的传输，无需关注SPI控制器驱动的实现细节。

见Thers is a minimal core...， 我理解SPI Core的代码主要在spi.c与spidev.c

3、SPI协议驱动程序

控制器驱动程序并不清楚和关注设备的具体功能，SPI设备的具体功能是由SPI协议驱动程序完成的，SPI协议驱动程序了解设备的功能和通信数据的协议格式。向下，协议驱动通过通用接口层和控制器交换数据，向上，协议驱动通常会根据设备的具体功能和内核的其它子系统进行交互，例如，和MTD层交互以便把SPI接口的存储设备实现为某个文件系统，和TTY子系统交互把SPI设备实现为一个TTY设备，和网络子系统交互以便把一个SPI设备实现为一个网络设备，等等。如果是一个专有的SPI设备，也可以按照设备的协议要求，实现自己的专有协议驱动。

协议驱动程序这种玩法我自己理解就是在SPI控制器节点下加从设备节点的方法

4、SPI通用设备驱动程序

有时候，考虑到连接在SPI控制器上的设备的可变性，在内核没有配备相应的协议驱动程序，对于这种情况，内核准备了通用的SPI设备驱动程序，该通用设备驱动程序向用户空间提供了控制SPI控制的控制接口，具体的协议控制和数据传输工作交由用户空间根据具体的设备来完成，在这种方式中，只能采用同步的方式和SPI设备进行通信，通常用于一些数据量较少的简单SPI设备。

二.主机驱动与外设驱动分离的设计思想

Linux中SPI、I2C、USB等子系统都利用典型的把主机驱动和外设驱动分离的想法，主机端只负责产生总线上的传输波形，而外设端通过标准的API让主机端以适当的波形访问自身。

这里涉及4个软件模块：

•   1）主机端的驱动。根据具体的I2C、SPI、USB等控制器的硬件手册，操作具体的I2C、SPI、USB等控制器，产生总线的各种波形。
•   2）连接主机和外设的纽带。外设不直接调用主机端的驱动来产生波形，而是调一个标准的API。由这个标准的API把这个波形的传输请求间接“转发”给了具体的主机端驱动。在这里，最好把关于波形的描述也以某种数据结构标准化。
•   3）外设端的驱动。外设接在I2C、SPI、USB总线上，但外设本身可以是触摸屏、网卡、声卡或任意一种类型的设备。在相关的i2c_driver、spi_driver、usb_driver这种xxx_driver的probe（）函数中去注册它具体的类型。当这些外设要求I2C、SPI、USB等去访问它的时候，它调用“连接主机和外设的纽带”模块的标准API。
•   4）板级逻辑。板级逻辑用来描述主机和外设是如何互联的。假设板子上有多个SPI控制器和多个SPI外设，究竟谁接在谁上面管理互联关系，既不是主机端的责任，也不是外设端的责任，这属于板级逻辑的责任。通常出现在arch/arm/mach-xxx下面或者arch/arm/boot/dts下面。