Category:SPI

Overview

Kernel documentation for the SPI framework is excellent and should be your starting point. You can find it under the Documentation directory of your linux source tree or here Documentation/spi/spi-summary.

Linux SPI drivers are broken into two parts. A controller driver that handles direct communication with the hardware and a protocol driver to handle the details of the data for a particular device. The interface defined in spi.c/spi.h is the bridge between the two.

For the OMAP3's, the controller driver is omap2_mcspi.c. The OMAP3's have 4 SPI busses which the omap2_mcspi driver handles. The kernel config option to include the omap2_mcspi driver is CONFIG_SPI_OMAP24XX.

The OMAP3 SPI controller has the ability to act as either a SPI master or SPI slave, but the current kernel code only supports the SPI master configuration. There are some new checkins to the kernel code indicating that SPI slave functionality might be coming.

Protocol Drivers

A protocol driver is probably what you want to write.

There are a couple of steps you need to follow in writing a SPI protocol driver.

1. You need to tell the SPI subsystem about the slave device(s) on each SPI bus that you want to use. This gets passed along to the controller driver when it's needed. You can do this during kernel init in a board file like board-overo.c or it can be done at run time in module code. A device name (modalias) is specified as a key part of this process.
2. You need to register a SPI protocol driver. This driver should have the same name (modalias) as was specified above. You register a spi_device using the spi_register_driver() call. When this internal mapping connection is made by the SPI subsystem, the result is a probe() call to your protocol driver.

It doesn't matter which order you perform these steps. But after both are completed and your probe() function returns success, your driver will be ready for SPI communication. You are given a spi_device in the probe() function that you need to hang onto.

SPI data communication happens using I/O queues. One or more SPI transfers are bundled up into SPI messages by you in your driver. You then submit your messages to the controller driver's I/O queue with calls to spi_async(). These messages are processed in FIFO order asynchronously by the controller and your driver is notified via completion callbacks as each message finishes. You can then process the raw data in your driver.

There is also a simple synchronous interface exposed by spi.h/spi.c that just halts your driver while the same asynchronous interface to the controller driver is used behind the scenes.

Example Driver

A sample OMAP3 Linux SPI driver can be found here.

The adc.c driver demonstrates how to add SPI devices at runtime instead of at boot time in order to simplify development. It also demonstrates how to handle asynchronous I/O with the SPI controller.

There is no attempt to do anything useful with the data, a couple of ADC slaves, it's just for testing out the SPI framework.

The driver exposes a simple character device interface to interact with userland.

Using Spidev

Check the Gumstix mailing list archives for spidev

In particular, this article on spidev posted on 7/21/09.