diff --git a/Software/OperatingSystem/Linux/Development/KernelDriver/Linux_SPI_子系统_x86平台.md b/Software/OperatingSystem/Linux/Development/KernelDriver/Linux_SPI_子系统_x86平台.md index b3488aa..0bd9760 100644 --- a/Software/OperatingSystem/Linux/Development/KernelDriver/Linux_SPI_子系统_x86平台.md +++ b/Software/OperatingSystem/Linux/Development/KernelDriver/Linux_SPI_子系统_x86平台.md @@ -4,19 +4,31 @@ 写文在于交流和传播知识,本人才粗学浅,还请多多指教,板砖轻拍。 -网络上很多 Linux SPI 驱动框架参考资料,但这些资料大部分以讲解源码为主,虽然 Linux 内核源码很清晰美妙,但内核版本众多,细枝末节处差异很大,不利于初学者进行对比学习。另外初学者需要阅读大量的源码才能明晰程序流程,总结出具体的原理,形成总体概念,而无法形成总体概念的情况下,是很难完成具体开发工作的。因此本文主要以文字描述为主,源码为辅,重点在于理清与 SPI 有关的相关概念,理清 SPI 驱动框架的流程。 +网络上很多 Linux SPI 驱动框架参考资料,但这些资料大部分以讲解源码为主,虽然 Linux 内核源码很清晰美妙,但内核版本众多,细枝末节处差异很大,不利于初学者进行对比学习。另外初学者需要阅读大量的源码才能明晰程序流程,这就增加了系统了解 SPI 子系统的难度,很难快速完成具体开发工作的。因此本文主要以文字描述为主,源码为辅,重点在于理清与 SPI 有关的相关概念和 SPI 子系统的初始化的流程。 另外,本文主要描述 x86 体系下的 SPI 框架,也可作为 ARM 体系下 SPI 框架的参考,因为两种框架下的概念和原理都是相通的,只是有些地方的具体实现不同。 -## 对 SPI 子系统的一些理解 +## 总述 -电子系统中有很多外设,有像 GPIO 这样简单的设备,也有像 LCD 控制器这样复杂的。有一类特殊的外设,用于实现总线通信,通常以控制器的角色出现,被称为总线控制器,例如 UART 控制器、以太网控制器,以及本文的主角 SPI 控制器。这些控制器与特定的总线连接,总线上往往可以挂载多个设备。总线有主从通信,也有无主从关系的。 +SPI 是一种总线通讯协议,由总线控制器和从设备构成。Linux SPI 驱动包含两个部分,分别用于驱动 SPI 总线控制器和从设备,内核中的 SPI 子系统为这两种驱动提供了开发框架。 -SPI 总线是这些总线中的一种,属于主从通讯形式,可以挂载多个从设备,每个从设备通过片选(CS)信号来选定。核心 CPU 常常作为主设备来工作,通过以某种形式挂载到核心 CPU 上的 SPI 总线控制器与从设备通信。具体而言,在 x86 平台上,SPI 总线控制器通过 PCI 总线挂接到主 CPU 上;而 ARM 平台上往往是以外设的形式出现,直接挂接在 SOC 或 MCU 片内的系统总线上。 +在系统探测到设备并挂载相关驱动的过程中,涉及到设备发现(探测或枚举)和驱动匹配(Match),对于总线上的设备,需要知道该设备挂载在哪条总线上,因此就需要知道该设备的总线号。在 SPI 子系统中,这些动作由 SPI Board Info(ACPI 或 Device Tree 中与 SPI 从设备有关的部分)、SPI 控制器驱动以及SPI 从设备驱动共同完成,它们各自的分工如下: + +1. SPI Board Info(ACPI 或 Device Tree 中与 SPI 从设备有关的部分):用于声明设备的存在,提供 SPI 从设备所在的总线号、片选号以及用于与 SPI 从设备匹配的 modalias 字段(与 SPI 从设备中的 name 字段匹配)。 +2. SPI 控制器驱动:用于驱动 SPI 总线控制器。 +3. SPI 从设备驱动:用于驱动 SPI 从设备。 + +接下来将从 SPI 硬件系统与软件抽象之间的关系,以及 SPI 驱动的探测过程两个方面展开说明。 + +## SPI 硬件系统与软件抽象之间的关系 + +电子系统中有很多外设,有像 GPIO 这样简单的设备,也有像 LCD 控制器这样复杂的。有一类特殊的外设,用于实现总线通信,通常以控制器的角色出现,被称为总线控制器,例如 UART 控制器、以太网控制器,以及本文的主角 SPI 控制器。 + +SPI 控制器用于实现 SPI 总线通讯,该通讯采用主从通讯形式,一个主设备可以挂载多个 SPI 从设备,每个从设备通过片选(CS)信号来选定。核心 CPU 通过 SPI 控制器与从设备进行交互。SPI 控制器常常以某种形式挂载到核心 CPU 上,具体而言,在 x86 平台上,SPI 总线控制器通过 PCI 总线挂接到主 CPU 上;而 ARM 平台上往往是以片载外设的形式出现,直接挂接在 SOC 或 MCU 片内的系统总线上。 ![图 1 SPI 总线结构](./img/Linux_SPI_子系统_x86平台/001.jpg) -SPI 通讯离不开主控制器和从设备,因此在 Linux 系统中就需要为这两种对象开发驱动程序。其中,SPI 控制器驱动用于驱动主设备中的 SPI 总线控制器;而 SPI 设备驱动用于驱动从设备(因此个人觉得叫 SPI 从设备驱动似乎更贴切些,为便于区分,后卫都将 SPI 设备驱动称作 SPI 从设备驱动),SPI 从设备驱动的工作相当于将 SPI 通信协议与具体的设备控制协议相互转换,所以又称为 SPI 协议驱动。一条 SPI 总线(对应一个 SPI 主控制器)上可以挂接多个 SPI 从设备,与之对应的是:一个 SPI 控制器驱动也可以挂接多个 SPI 从设备驱动。下图,详细描述了 Linux 系统中 SPI 驱动框架,以及各部分之间的相互关系。 +SPI 通讯离不开 SPI 总线控制器和从设备,因此在 Linux 系统中就需要为这两种对象开发驱动程序。用于驱动 SPI 总线控制器的驱动称为 SPI 控制器驱动,而用于驱动 SPI 从设备的驱动称为 SPI 设备驱动(个人觉得叫 SPI 从设备驱动似乎更贴切些,为便于区分,后文都将 SPI 设备驱动称作 SPI 从设备驱动)。从另一个角度来说,SPI 从设备驱动的工作相当于将 SPI 通信协议与具体的设备控制协议相互转换,所以 SPI 从设备驱动又称为 SPI 协议驱动。从名称上可以看出,SPI 控制器驱动属于总线控制器驱动,然而 SPI 从设备是多种多样的,可能是 char 设备(如 spidev),也可能是 block 设备(如 SPI Flash),因此 SPI 从设备驱动也是有多种类型的。一条 SPI 总线(对应一个 SPI 总线控制器)上可以挂接多个 SPI 从设备,与之对应的是:一个 SPI 控制器驱动也可以挂接多个 SPI 从设备驱动。下图,详细描述了 Linux 系统中 SPI 驱动框架,以及各部分之间的相互关系。 ![图 2 Linux SPI 子系统框架](./img/Linux_SPI_子系统_x86平台/002.jpg) @@ -24,19 +36,43 @@ SPI 通讯离不开主控制器和从设备,因此在 Linux 系统中就需要 2. SPI 协议驱动(SPI 从设备驱动): 相当于 slave,用于驱动 SPI 总线上所挂接的设备,在 /dev 目录下创建设备节点,提供 open、read、write、ioctl 等 file operation 接口,驱动类型由设备本身所属设备驱动类型描述(char/block/...)。 -在 x86 平台下,SPI 总线控制器可以作为标准 PCI 设备接入,由 PCI 枚举来触发 SPI 控制器驱动的 Probe 过程;SPI 从设备驱动的 Probe 过程则是通过 Kernel 匹配 spi_driver 的 name 字段来完成的,后文讲具体描述这个过程。 +有一些 SPI 从设备并不是由内核来为其提供驱动的,而是交给用户态去处理,此时需要在内核为这些从设备导出用户态操作的接口,Linux 内核为此提供了统一的内核程序——spidev,来完成此项工作。被 spidev 导出的接口以 spidev<总线号>.<子设备号/片选序号> 的文件形式出现在 /dev 系统目录下,如:spidev1.2 便是第二个 SPI 总线上的第三个从设备。之后就可以在用户态通过 open、read、write、ioctl、close 等标准接口操作 SPI 从设备了。spidev 相当于一种特殊的 SPI 从设备驱动,即在 SPI 子系统框架下实现的字符设备,该设备用于进行直接的 SPI 通讯。 -有一些 SPI 从设备并不是由内核来为其提供驱动的,而是交给用户态去处理,此时需要在内核为这些从设备导出用户态操作的接口,Linux 内核为此提供了统一的内核程序——spidev,来完成此项工作。被 spidev 导出的接口以 spidev<总线号>.<子设备号/片选序号> 的文件形式出现在 /dev 系统目录下,如:spidev1.2 便是第二个 SPI 总线上的第三个从设备。spidev 相当于一种特殊的 SPI 从设备驱动,即在 SPI 子系统框架下实现的字符设备。 +了解 Linux SPI 子系统中两个主要角色(SPI 控制器驱动和 SPI 从设备驱动)后,就需要知道他们是如何被初始化的,以及如何与具体设备匹配上的。 -## 先说说 Probe +## SPI 驱动的探测过程 -不同平台、不同类型设备的 Probe 方法不同。对于 ARM 平台目前使用 Device Tree;而 x86 平台有 ACPI 表。对于 PCI 设备,则通过总线号(Bus)、设备号(Device)和功能号(Function)来枚举设备(简称 BDF)。设备发现和枚举过程由系统内核框架实现,一般不需要设备驱动开发人员关心,只需要写好 Device Tree,提供好 ACPI 表即可,而这两个表一般会有 Demo 可以参考。 +有些总线设备是可以自动枚举到的,如 PCI 总线可以通过 BDF(总线号 Bus、设备号 Device 和功能号 Function) 来枚举设备并通过 Device ID 和 Vendor ID 来匹配驱动程序。然而有很多总线不能自动枚举设备并匹配驱动程序。因此内核提供了几种配置表用于声明某些设备的存在,对于 ARM 平台目前使用 Device Tree,而 x86 平台有 ACPI 表,或者以平台设备的形式注册 Board Info。Linux 内核会扫描这些表或已注册的 Board Info,并根据其中的信息触发对应驱动程序的 Probe 流程。这个过程由系统内核框架实现的,不需要设备驱动开发人员关心,只需要写好 Device Tree,提供好 ACPI 表 或注册好 Board Info 即可,而这一般会有 Demo 可以参考。 -有些设备无法像 PCI 设备那样被自动探测到,那就需要将这些设备写入 Device Tree 或 ACPI 表,也可以作为 Platform 设备出现,通过 board info 来注册。注意,无论是 Device Tree、ACPI 还是 board info,他们只描述了设备的存在,用于触发对应设备驱动的 Probe 过程。 +在 x86 平台下,SPI 总线控制器作为 PCI 设备接入,由 PCI 枚举来探测到设备,并通匹配 Device ID 和 Vendor ID 来匹配 SPI 控制器驱动,触发其 Probe 程序;然而 SPI 从设备是无法自动探测到的,需要在 ACPI 表中声明这些从设备,或在平台设备中注册相关的 SPI Board Info,以便内核能够匹配到正确的 SPI 设备驱动并触发其 Probe 程序。// 驱动的 Probe 过程则是通过 Kernel 匹配 spi_driver 的 name 字段来完成的,后文讲具体描述这个过程。 -## 板级支持文件 +以平台设备为例,看下 SPI 从设备的探测流程。 -通常来说 SPI 从设备是无法被自动探测到的,此时可以作为 Platform 设备存在,在 arch->x86->platform 下(x86 平台)为其创建板级文件,注册 spi_board_info。 +*注:x86 系统的平台设备声明在 arch->x86->platform 下。* + +### SPI Board Info + +一旦注册了 SPI Board Info,系统便会在 Probe 对应的总线时去匹配对应的驱动程序。先看下 spi_board_info 的具体结构,注意每个成员后面的注释: + +```cpp +struct spi_board_info { + char modalias[SPI_NAME_SIZE]; // 用于与 SPI 从设备驱动匹配,触发其 Probe 过程. + const void *platform_data; + const struct property_entry *properties; + void *controller_data; + int irq; + u32 max_speed_hz; + u16 bus_num; // 用于与 SPI 控制器中的 bus num 匹配,对应 spidev<总线号>.<子设备号/片选序号> 中的 总线号. + u16 chip_select; // 指定片选序号,将作为 spidev<总线号>.<子设备号/片选序号> 中的 子设备号/片选序号. + u16 mode; // SPI 有四种模式,见下图,具体参考 SPI 协议相关资料. +}; +``` + +![图 3 SPI 四种模式](./img/Linux_SPI_子系统_x86平台/003.jpg) + +在 Probe 和 Match 过程中需要关注其中的两个成员:modalias 和 bus_num。bus_num 是给总线控制器用的,而 modalias 用于匹配对应的 SPI 从设备驱动。 + +### Probe 过程 系统启动时,先执行 arch_initcall 中的定义的板级初始化程序,由该程序完成 spi_board_info 的注册,并由此形成一张 SPI 从设备列表。在 x86 平台下,当系统进行 PCI 设备枚举时,将发现 SPI 总线控制器,并调用与之对应的 SPI 总线控制器驱动中的 Probe 程序,该 Probe 程序会调用 regist 函数来注册 SPI master/controller,在这个注册函数中会比较当前 SPI 控制器的总线号,如果与 SPI 从设备列表中的总线号对应,则将该从设备挂接到这个控制器上。在 4.19.23 版本内核中,以 pxa2xx 为例,可用以下函数调用关系来描述: @@ -64,7 +100,7 @@ pxa2xx_spi_probe() | } ``` -spi_board_info 只是描述了有哪些板级 SPI 从设备存在,并没有真正的驱动这些设备。从设备的驱动是由 SPI 驱动来完成的。以 spidev 为例,看下它的框架就知道了: +一旦 SPI 从设备挂载到了对应的总线上,系统就会查找有无匹配的 SPI 从设备驱动,并触发其 Probe 过程。判断 SPI 从设备驱动是否与声明的平台设备相匹配是通过匹配 spi_driver 结构体中的 name 字段与 spi_board_info 结构体中的 modalias 字段是否一致来完成的。以 spidev 为例,将看到 spi_driver 的基本结构,另外我们再看下 SPI 从设备驱动的主要工作: ```cpp /** @@ -140,27 +176,9 @@ static void __exit spidev_exit(void) module_exit(spidev_exit); ``` -代码首先注册了 File Operation 方法,在 init 中注册字符设备和 SPI 驱动,当触发 Probe 程序后,创建设备,并在 /dev 目录下形成设备节点。 +对于 SPI 从设备而言,一方面要通过系统调用接口接受来自用户态的操作,另一方面则通过与之对应的 SPI 控制器驱动访问 SPI 总线并驱动具体设备。因此,代码首先注册了 File Operation 方法,另一方面则在 init 中注册字符设备和 SPI 驱动,当触发 Probe 程序后,创建设备,并在 /dev 目录下形成设备节点。 -通过 spi_driver 结构体可以看出,当 spidev 设备注册后,会通过三种方式匹配从而触发自身的 Probe 过程。这三种方式分别是 Device Tree、ACPI 表和 Name。对于 Platform 设备而言,当其 spi_board_info 中的 modalias 属性与 spi_driver 中的 name 属性一致时,就会触发。 - -下面具体看下 spi_board_info 的结构,注意每个成员后面的注释: - -```cpp -struct spi_board_info { - char modalias[SPI_NAME_SIZE]; // 用于与 SPI 从设备驱动匹配,触发其 Probe 过程. - const void *platform_data; - const struct property_entry *properties; - void *controller_data; - int irq; - u32 max_speed_hz; - u16 bus_num; // 用于与 SPI 控制器中的 bus num 匹配,对应 spidev<总线号>.<子设备号/片选序号> 中的 总线号. - u16 chip_select; // 指定片选序号,将作为 spidev<总线号>.<子设备号/片选序号> 中的 子设备号/片选序号. - u16 mode; // SPI 有四种模式,见下图,具体参考 SPI 协议相关资料. -}; -``` - -![图 3 SPI 四种模式](./img/Linux_SPI_子系统_x86平台/003.jpg) +通过 spi_driver 结构体可以看出,当 spidev 不但可以驱动平台设备,还可以驱动以 Device Tree 或 ACPI 表声明的 SPI 从设备,当然,这些都是通过匹配 Name 字段来完成的。 ## SPI 核心层