Chapter 25. Serial Peripheral Interface (SPI)

Table of Contents

struct spi_device — Master side proxy for an SPI slave device
struct spi_driver — Host side “protocol” driver
spi_unregister_driver — reverse effect of spi_register_driver
struct spi_master — interface to SPI master controller
struct spi_transfer — a read/write buffer pair
struct spi_message — one multi-segment SPI transaction
spi_setup — setup SPI mode and clock rate
spi_async — asynchronous SPI transfer
spi_write — SPI synchronous write
spi_read — SPI synchronous read
spi_w8r8 — SPI synchronous 8 bit write followed by 8 bit read
spi_w8r16 — SPI synchronous 8 bit write followed by 16 bit read
struct spi_board_info — board-specific template for a SPI device
spi_register_board_info — register SPI devices for a given board
spi_register_driver — register a SPI driver
spi_new_device — instantiate one new SPI device
spi_alloc_master — allocate SPI master controller
spi_register_master — register SPI master controller
spi_unregister_master — unregister SPI master controller
spi_busnum_to_master — look up master associated with bus_num
spi_sync — blocking/synchronous SPI data transfers
spi_write_then_read — SPI synchronous write followed by read

SPI is the "Serial Peripheral Interface", widely used with embedded systems because it is a simple and efficient interface: basically a multiplexed shift register. Its three signal wires hold a clock (SCK, often in the range of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and a "Master In, Slave Out" (MISO) data line. SPI is a full duplex protocol; for each bit shifted out the MOSI line (one per clock) another is shifted in on the MISO line. Those bits are assembled into words of various sizes on the way to and from system memory. An additional chipselect line is usually active-low (nCS); four signals are normally used for each peripheral, plus sometimes an interrupt.

The SPI bus facilities listed here provide a generalized interface to declare SPI busses and devices, manage them according to the standard Linux driver model, and perform input/output operations. At this time, only "master" side interfaces are supported, where Linux talks to SPI peripherals and does not implement such a peripheral itself. (Interfaces to support implementing SPI slaves would necessarily look different.)

The programming interface is structured around two kinds of driver, and two kinds of device. A "Controller Driver" abstracts the controller hardware, which may be as simple as a set of GPIO pins or as complex as a pair of FIFOs connected to dual DMA engines on the other side of the SPI shift register (maximizing throughput). Such drivers bridge between whatever bus they sit on (often the platform bus) and SPI, and expose the SPI side of their device as a struct spi_master. SPI devices are children of that master, represented as a struct spi_device and manufactured from struct spi_board_info descriptors which are usually provided by board-specific initialization code. A struct spi_driver is called a "Protocol Driver", and is bound to a spi_device using normal driver model calls.

The I/O model is a set of queued messages. Protocol drivers submit one or more struct spi_message objects, which are processed and completed asynchronously. (There are synchronous wrappers, however.) Messages are built from one or more struct spi_transfer objects, each of which wraps a full duplex SPI transfer. A variety of protocol tweaking options are needed, because different chips adopt very different policies for how they use the bits transferred with SPI.