Chapter 9: Writing SPI Device Drivers

The Serial Peripheral Interface (SPI) is (at least) a 4-wire bus – Master Input Slave Output (MISO), Master Output Slave Input (MOSI), Serial Clock (SCK), and Chip Select (CS) – which is used to connect serial flash and analog-to-digital/digital-to-analog converters. The master always generates the clock. Its speed can reach up to 80 MHz, though there is no real speed limitation (this is much faster than I2C as well). The same applies to the CS line, which is always managed by the master.

Each of these signal names has a synonym:

• Whenever you see Slave Input Master Output (SIMO), Slave Data Input (SDI), or Data Input (DI), they refer to MOSI.
• Slave Output Master Input (SOMI), Slave Data Output (SDO), and Data Output (DO) refer to MISO.
• Serial Clock (SCK), Clock (CLK), and Serial Clock (SCL) refer to SCK.
• S̅ S̅ is the Slave Select line, also called CS. CSx can be used (where x is an index such as...

Understanding the SPI framework abstractions in the Linux kernel

The Linux kernel SPI framework is made up of a few data structures, the most important of which are the following:

• spi_controller, used to abstract the SPI master device.
• spi_device, used to abstract a slave device sitting on the SPI bus.
• spi_driver, the driver of the slave device.
• spi_transfer, which is the low-level representation of one segment of a protocol. It represents a single operation between the master and slave. It expects Tx and/or Rx buffers as well as the length of the data to be exchanged and an optional CS behavior.
• spi_message, which is an atomic sequence of transfers.

Let's now introduce each of these data structures, one after the other, starting with the most complex, which represents the SPI controller's data structure.

Brief introduction to struct spi_controller

Throughout this chapter, we will reference the controller because it is deeply coupled with...

Dealing with the SPI driver abstraction and architecture

This is where the driver logic takes place. It consists of filling struct spi_driver with a set of driving functions that allow probing and controlling the underlying device.

Probing the device

The SPI device is probed by the spi_driver.probe callback. The probe callback is responsible for making sure the driver recognizes the given device before they can be bound together. This callback has the following prototype:

int probe(struct spi_device *spi)

This method must return 0 on success, or a negative error number otherwise. The only argument is the SPI device to be probed, whose structure has been pre-initialized by the core according to its description in the device tree.

However, most (if not all) of the properties of the SPI device can be overridden, as we have seen while describing its data structure. SPI protocol drivers may need to update the transfer mode if the device doesn't work with its default...

Learning how not to write SPI device drivers

The usual way to deal with SPI devices is to write kernel code to drive this device. Nowadays the spidev interface makes it possible to deal with such devices without even writing a line of kernel code. The use of this interface should be limited, however, to simple use cases such as talking to a slave microcontroller or for prototyping. Using this interface, you will not be able to deal with various interrupts (IRQs) the device may support nor leverage other kernel frameworks.

The spidev interface exposes a character device node in the form /dev/spidevX.Y where X represents the bus our device sits on, and Y represents the CS index (relative to the controller) assigned to the device node in the device tree. For example, /dev/spidev1.0 means device 0 on SPI bus 1. The same applies to the sysfs directory entry, which would be in the form /sys/class/spidev/spidevX.Y.

Prior to the character device appearing in the user space, the device...

Summary

In this chapter, we tackled SPI drivers and can now take the advantage of this serial (and full duplex) bus, which is way faster than I2C. We walked through all the data structures in this framework and discussed transferring over SPI, which is the most important section we covered. That said, the memory we accessed over those buses was off-chip – we may need more abstraction in order to avoid the SPI and I2C APIs.

This is where the next chapter comes in, dealing with the regmap API, which offers a higher and more unified level of abstraction so that SPI (and I2C) commands will become transparent to you.