spi-mem: 为SPI存储器生态带来一些一致性
在本文中,我们将介绍关于spi-mem Linux内核框架的工作,该框架将允许在SPI NOR设备和常规SPI设备以及SPI NAND设备上复用SPI控制器驱动程序。
从SPI到双线、四线、八线SPI
在过去,SPI是一个简单的协议,总线上的所有设备只共享3根信号线:
- MISO: Master In Slave Out,主设备输入从设备输出线
- MOSI: Master Out Slave In,主设备输出从设备输入线
- SCLK: Serial Clock,时钟线
另外每个设备有一个独立信号线,用于选择我们想要通信的设备:
- SS: Slave Select,从设备选择线 (有时也称为片选线CS,Chip Select)
但随后SPI存储出现了。它从较小且相对较慢的SPI NORs开始,如dataflash、EEPROMs和SRAMs,然后逐渐发展到较大的SPI NORs和SPI NANDs。像往常一样,当涉及到处理存储时,我们希望得到最佳性能表现。SPI总线的限制很快成为瓶颈,因此供应商决定添加更多的I/O线路,并使 MISO/MOSI 线可以双向通信。现在我们看到SPI控制器支持最多8路I/O。这就是业内所说的DualSPI QuadSPI和OctoSPI。
为了在主从设备的数据传输中用上所有的I/O线,必须有某种主从设备之间的协议,这样双方才能知道,何时可以在I/O线上收发数据,应该使用多少根I/O线等。这些由一组从设备预定义的操作规定了如何进行,主设备必须遵循这组操作的规定,进入特定的发送或接收状态。SPI存储器操作通常包括:
- 1字节的操作码,表示将要进行从操作 (未来将很快会将出现2字节的操作码,请做好准备)
- 0-N 字节的地址,其含义取决于操作码(可以是绝对内存地址,或其他含义)
- 0-N 字节的哑字节,使得从设备有足够的时间来进入操作码请求的特定状态,同样,哑字节的数量时取决于操作码的
- 0-N 字节的输入或输出数据,方向是取决于操作码
请注意,虽然这个协议倾向于被用于存储设备,但并没有什么能限制它只能用于存储设备,如果一些FPGA使用相同的协议来操作非存储设备,我也不会感到惊讶。
Linux SPI 生态
Linux支持双线SPI和四线SPI模式已经有一段时间了(v3.12), SPI设备驱动程序可以为每个SPI传输指定I/O通道的数量。使用这种方式,对SPI存储的操作可以被分为多次SPI传输,每次SPI传输使用预定义数量的I/O通道进行传输。
这种方式可以正常工作,直到一些IP供应商决定让它们的SPI控制器更加智能,嵌入某种高级接口,可以在单个的步骤中执行SPI存储器的操作,而不是使用分开的多次传输操作。(事实上,大多数SPI控制器甚至比这更加智能,可以允许你直接将SPI存储映射到CPU的地址空间,但让我们先把这种情况留待以后处理吧)。在这种情况下,我们需要赋予SPI控制器更多的控制权,这样它就可以决定具体该做什么,而不必从一组分散的SPI传输命令中,重建SPI存储器操作。
当时的决定是,将这些控制器专门用于一个任务,控制SPI NORs(当时这是唯一会用到双线和四线模式的情况),SPI NOR框架就是为此而创建的。
由于这个决定,我们现在在Linux中有一个SPI NOR框架用于连接SPI NOR控制器驱动和SPI NOR的逻辑代码(spi-nor 子系统),同时我们有常规的SPI控制器驱动,可以进行基础的SPI传输(spi 子系统)。然而,从硬件的角度看,能为SPI NOR提供特殊特性的SPI控制器,一般也拥有进行基本传输的能力,即可用于控制常规的SPI设备。不幸的是,基于当前的spi-nor 子系统和spi 子系统是分裂开来的情况,如果一个SPI控制器被spi-nor子系统的驱动支持了,它将无法被用于与spi子系统中的常规设备进行通信。
作为一个针对这个问题的部分的解决方案,->spi_flash_read()操作被添加到结构体 spi_controller中,这允许spi子系统中的常规spi控制器驱动提供一个较优的方式,来从SPI NOR存储中读取数据,这种方式被通用SPI NOR驱动m25p80所使用。然而,这个解决方案是部分的,因为它只优化了读取,并且仅限于SPI NORs。
在当前的架构中,我们有
- SPI NOR框架,它包含与SPI NOR存储器通讯的协议。这个框架依赖于结构体spi_nor中列出的接口,这些接口的实现是:
- 专用的SPI NOR控制器,支持专用于SPI NORs的高级SPI控制器
- m25p80驱动,提供同样的接口,但基于常规SPI控制器驱动,可能具有->spi_flash_read()的优化
是什么促使我们提出SPI存储器接口?
我们之前已经看到,基于SPI NOR框架,SPI NOR存储器已经得到了适当的支持。但NORs 并非SPI总线上唯一的存储设备,SPI NANDs 正在变得越来越流行。
Peter Pan提出了一个遵循SPI NOR模型的,用于支持SPI NAND设备的框架: SPI控制器必须实现SPI NAND控制器接口才能控制SPI NAND。但是当我们更深入地参与到这个开发中时,我们很快意识到沿着这条路走会有多么麻烦,因为这意味着,如果SPI控制器想要同时控制两种设备,就必须同时实现SPI NOR和SPI NAND接口。当SPI NVRAM或任何其他类型的存储制造商决定采用SPI总线时,将会发生什么?再添加一个SPI控制器必须实现的接口?这听起来不是个好主意。
因此我们决定用另外的方式解决这个问题,尝试找出SPI NANDs和SPI NORs的共同点。SPI NORs和SPI NANDs 指令集不同,行为和约束也不同(主要是由于NOR和NAND本身的不同),但当与设备交互时,都遵循同样的SPI存储器操作语义,这也是高级控制器都在尝试优化的部分。
SPI 存储器层只是提供一种方式给SPI控制器驱动,用于传递高级SPI存储器操作,而不是让它们处理SPI传输细节并自行尝试优化它们。这同样简化了SPI存储器驱动,因为它们只需要按照SPI存储器规范发送SPI存储器操作指令,不需要关心复杂的、不断发展的、依赖具体存储器的接口。
有了这个新的架构,SPI NOR和SPI NAND都可以基于相同的SPI控制器驱动进行支持了。m25p80驱动将被修改成,使用spi-mem接口,取代具有局限性的->spi_flash_read()接口。目前,我们仍然有专用的SPI NOR控制器驱动,但最终目标是移除它们,并将它们移植为 drivers/spi 下的普通SPI控制器驱动。非常欢迎这方面的帮助和贡献。
SPI存储器API是什么样子的?
SPI存储器的API 由 include/linux/spi/spi-mem.h 描述。
希望使用SPI存储器API的SPI设备驱动程序,应该将自己声明为spi_mem_drivers,并实现->probe()和->remove()函数。
它们将被传入一个spi_mem对象,它只是一个围绕spi_device对象的简单包装,我们引入一个不同的对象的原因是,我们希望能够拓展spi_mem对象,并在需要时附加更多的信息(例如存储器类型,存储器组织方式和其他的高级SPI控制器可能需要的信息)。
当驱动想要执行SPI存储器操作时,它将填充spi_mem_op结构并调用spi_mem_exec_op()。另外,可以使用spi_mem_supports_op(),测试一个SPI控制器是否支持特定的存储器操作,使用spi_mem_adjust_op_size(),获取控制器支持的最大传输大小,并尝试拆分数据传输以避免超出限制。
现在让我们看下控制器端。一个希望优化SPI存储器操作的SPI控制器,可以实现spi_mem_ops接口,该接口包含三个直接对应用户API的方法:
- ->exec_op():执行存储器操作,如果不支持则返回-ENOTSUPP。
- ->supports_op(): 检查这个存储器操作是否支持。
- ->adjust_op_size(): 调整存储器操作的数据传输大小,以符合对齐要求和最大FIFO大小的约束。
注意,当spi_mem_ops 没有实现时,core层将通过创建由多个SPI传输组成的SPI消息,来添加对该特性的通用支持,就像以前通用SPI NOR控制器驱动程序(名为m25p80)所做的那样。
如你所见,这些API非常直截了当,所以希望有更多的SPI存储器驱动能够转换为使用它,而不是手动创建包含多个SPI传输的SPI消息。
当前状态
一部分已经被贡献出去并合并,计划成为Linux 4.18的一部分:
- spi-mem层本身在commit c36ff266dc82f4ae797a6f3513c6ffa344f7f1c7。
- 两个之前使用->spi_flash_read接口实现的SPI控制器驱动,现在改为基于spi-mem实现
bcm-qspi 和 ti-qspi. - ->spi_flash_read 接口由以下commit移除:c1f5ba70decfc2f35edcc10505e3e78fb528d212.
- m25p80驱动,由以下commit修改为使用spi-mem: 4120f8d158ef904fb305b27e4a4524649faf3096.
下一步是什么?
先进的SPI控制器不仅能够优化SPI存储器操作的执行,它们可以进一步将所有存储器访问的复杂性隐藏起来,提供一个直接映射的IOMEM区域,对此区域的访问会自动在总线上触发SPI存储器操作,为你完成数据的收发,这样的行为就像一个连接在并行的内存总线上的内存。可以想象,这将允许更高的吞吐量和更少的用于SPI存储器操作管理的CPU时间,但这同时也是一个难以通过常规的方式进行支持的功能。我们已经在linux-mtd邮件列表上发布了一个支持这种直接映射功能的建议。
如前所述,另一个具有挑战性的主题是,将所有的SPI NOR控制器驱动转换为基于SPI mem模型,以便所有的QSPI控制器都真正表现为SPI控制器而非SPI NOR控制器。这可能需要一些时间,因为目前在driver/mtd/spi-nor 下有10个驱动,我们只知道其中2个被转换为了SPI mem方法(fsl-quadspi和atmel-quadspi)。
本文地址 https://www.cnblogs.com/zqb-all/p/10810054.html
译自 https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/
原作者 Boris Brezillon