One of the Linux SPI Bus and device driver architectures: System Overview "Go"

Transferred from: http://blog.csdn.net/droidphone/article/details/23367051/

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Directory (?) [-]

1. Hardware structure
1. Working time series
2. Software architecture
1. SPI Controller Driver
2. SPI Universal Interface Package layer
3. SPI Protocol Driver
4. SPI Universal Device Driver

SPI is "Serial peripheral Interface" abbreviation, is a four-wire synchronous serial communication interface, used to connect microcontrollers, sensors, storage devices, SPI device sub-primary device and two from the device, for communication and control of the four lines are:

• CS Chip Selection Signal
• SCK Clock Signal
• Miso the data input from the main device, the data output pin from the device
• MOSI the data output from the main device, the data input pin from the device

Because in most cases the CPU or SOC side usually works in the main device mode, the current Linux kernel version only implements the main mode driver framework.

/*****************************************************************************************************/
Statement: The content of this blog by Http://blog.csdn.net/droidphone Original, reproduced please indicate the source, thank you!
/*****************************************************************************************************/

Hardware structure Typically, the device responsible for making the clock signal is what we call the main device, and the other is the hardware connection example of the SPI system as the slave device: Figure 1.1 SPI hardware structure diagram as shown in the main device corresponding to the SOC core SPI Controller in the chip, typically, there may be multiple SPI controllers in one SOC, as shown in the example above, with 3 SPI controllers in the SOC chip. Each controller can be connected to multiple SPI slave devices, each from the device has its own independent CS pin. Each of the other 3 signal pins is shared from the device: SCK, miso, MOSI. At any time, only one CS pin is active, and the device connected to the active CS pin can now communicate with the main device (SPI Controller), the other slave devices are waiting, and their 3 pins must be in a high-impedance state. Working time series Depending on the phase relationship between the clock signal and the data signal, the SPI has 4 operating sequence modes: We use Cpol to denote the state of the initial level of the clock signal, Cpol 0 indicates that the initial state of the clock signal is low, and 1 indicates that the initial level of the clock signal is high. In addition, we use Cpha to indicate that the clock along the sampled data, Cpha to 0 means that the first clock changes along the sampled data, while the Cpha of 1 indicates that the second clock changes along the edge to sample data. The kernel uses a combination of Cpol and cpha to represent the working mode that the current SPI requires:

• Cpol=0,cpha=1 Mode 0
• Cpol=0,cpha=1 Mode 1
• Cpol=1,cpha=0 Mode 2
• Cpol=1,cpha=1 Mode 3

Software architecture In the kernel's SPI-driven software architecture, a reasonable layering and abstraction is made, as shown in: Figure 2.1 SPI-driven software architecture SPI Controller Driver The SPI Controller does not care about the specific functions of the device, it is only responsible for the upper layer protocol drive prepared data according to the SPI bus timing requirements sent to the SPI device, while the data received from the device to the upper layer of the Protocol driver, therefore, the kernel to the SPI controller driver Independent. The SPI Controller driver is responsible for controlling the specific controller hardware, such as DMA and interrupt operations, as multiple upper-layer protocol drivers may request data transfer operations through the controller, so the SPI controller driver is also responsible for queue management of these requests, guaranteeing the principle of FIFO. SPI Universal Interface Package layer

To simplify the programming of the SPI driver and to reduce the coupling between the protocol driver and the controller driver, the kernel encapsulates some common operations of the Controller driver and protocol driver into a standard interface, plus some common logic processing operations, which make up the SPI Common interface encapsulation layer. The advantage of this is that for the controller driver, simply implement the standard interface callback API and register it with the common interface layer without having to interact directly with the protocol layer driver. For the protocol layer driver, the device and driver registration can be done through the API provided by the Universal interface layer, and the data can be transferred through the API of the common interface layer, without paying attention to the implementation details of the SPI controller driver.

SPI Protocol Driver As we mentioned above, the controller driver is not clear and attention to the specific functions of the device, the specific function of the SPI device is done by the SPI protocol driver, the SPI protocol driver understands the device's function and the protocol format of the communication data. Downward, the protocol driver exchanges data through the Universal interface layer and controller, and the protocol driver typically interacts with the device's specific functions and other subsystems of the kernel, for example, interacting with the MTD layer to implement the SPI interface's storage device as a file system. Interacting with the TTY subsystem, the SPI device is implemented as a TTY device, interacting with the network subsystem to implement an SPI device as a network device, and so on. Of course, if it is a proprietary SPI device, we can also implement their own proprietary protocol drivers according to the protocol requirements of the device. SPI Universal Device Driver Sometimes, given the variability of the devices connected to the SPI controller, the kernel is not equipped with the appropriate protocol driver, in this case, the kernel prepares a generic SPI device driver for us, which provides the user space with a control interface to control the SPI control. The specific protocol control and data transfer work is left to the user space according to the specific equipment, in this way, can only be synchronized with the SPI device communication, so it is usually used for some simple SPI devices with less data volume.

One of the Linux SPI Bus and device driver architectures: System Overview "Go"