Linux Kernel SPI subsystem architecture Analysis

Linux Kernel SPI subsystem architecture analysis (clear)

There are two types of equipment on the SPI bus: one is the main control end, which is usually used as a sub-module of the SoC system. For example, many embedded mpus usually contain SPI modules. One is the controlled end, such as flash and sensors of some SPI interfaces. The main controller is the controller of the SPI bus and actively initiates sessions on the SPI bus by using the SPI protocol. The controlled end passively accepts the commands of the SPI master end and responds to these commands.

Linux currently only supports the SPI master, but does not support the SPI controlled device.

In Linux, SPI is implemented by the SPI subsystem. This subsystem Directly Interacts with the SPI master device hardware to read data on the SPI bus. It interacts with the FS subsystem, MTD subsystem, and character device subsystem to provide an access interface for the user space.

The SPI subsystem contains two types of device drivers. The controller driver is used to drive the SPI main control device, interact with the SPI bus, and read and write communication data. Another type is called protocol driver, which is used to parse the data read by the controller driver to form meaningful protocol data. For example, the at25 chip is connected through the SPI bus and the SPI controller of the lpc3250 to form an SPI bus communication system. The role of the Protocol Driver is to find the corresponding SPI command based on the user space or upper-level subsystem requests (such as reading and writing data from the specified flash Address, and generates an SPI session frame (Instruction + address + data. Controller
The driver sends the data of the session frame to the SPI bus through the SPI controller hardware.

It can be seen that the SPI subsystem has two types of devices: controller driver and spi_master. The other is driven by the protocol driver, which is called spi_device (I think this method is not accurate. This device is only a protocol parsing device, not a real SPI device ).

The kernel divides the SPI subsystem so that the SPI master controller has a single function and is only responsible for interacting with the SPI bus and reading and writing data. However, the specific meaning of the data varies greatly depending on the devices on the SPI bus.

On the one hand, the kernel divides the SPI communication system into the above two parts, and on the other hand, creates an SPI core system to connect the two parts.

According to the above analysis, we know that the SPI communication data stream is roughly:
1. User request => protocol driver analyzes the request and generates an SPI communication frame => controller driver sends the communication frame to the SPI bus;
2. SPI device return data => controller driver reads back from SPI bus => protocol parses communication data and reports it;

In the interaction between protocol and controller, SPI frame is a key data structure. Protocol generates this frame by analyzing the upper-layer request and parses this frame to obtain the response of the SPI device. The Controller interacts with the SPI bus to send and receive such frames. In the Linux kernel, this frame is implemented through a structure called spi_message.

When there is a data request, the Protocol Resolution request generates this frame and sends it to the SPI core subsystem. The SPI core subsystem finds the corresponding controller device based on the protocol device information and sends the frame to the Controller. The Controller receives the frame and sends it to the SPI bus. The return process is similar.

For details about how the SPI controller and Protocol devices and the SPI core subsystem work with each other, see the next Linux kernel SPI subsystem implementation analysis.