8ae12a0d85
This is the core of a small SPI framework, implementing the model of a queue of messages which complete asynchronously (with thin synchronous wrappers on top). - It's still less than 2KB of ".text" (ARM). If there's got to be a mid-layer for something so simple, that's the right size budget. :) - The guts use board-specific SPI device tables to build the driver model tree. (Hardware probing is rarely an option.) - This version of Kconfig includes no drivers. At this writing there are two known master controller drivers (PXA/SSP, OMAP MicroWire) and three protocol drivers (CS8415a, ADS7846, DataFlash) with LKML mentions of other drivers in development. - No userspace API. There are several implementations to compare. Implement them like any other driver, and bind them with sysfs. The changes from last version posted to LKML (on 11-Nov-2005) are minor, and include: - One bugfix (removes a FIXME), with the visible effect of making device names be "spiB.C" where B is the bus number and C is the chipselect. - The "caller provides DMA mappings" mechanism now has kerneldoc, for DMA drivers that want to be fancy. - Hey, the framework init can be subsys_init. Even though board init logic fires earlier, at arch_init ... since the framework init is for driver support, and the board init support uses static init. - Various additional spec/doc clarifications based on discussions with other folk. It adds a brief "thank you" at the end, for folk who've helped nudge this framework into existence. As I've said before, I think that "protocol tweaking" is the main support that this driver framework will need to evolve. From: Mark Underwood <basicmark@yahoo.com> Update the SPI framework to remove a potential priority inversion case by reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
416 lines
16 KiB
Text
416 lines
16 KiB
Text
Overview of Linux kernel SPI support
|
|
====================================
|
|
|
|
22-Nov-2005
|
|
|
|
What is SPI?
|
|
------------
|
|
The "Serial Peripheral Interface" (SPI) is a four-wire point-to-point
|
|
serial link used to connect microcontrollers to sensors and memory.
|
|
|
|
The three signal wires hold a clock (SCLK, often on the order of 10 MHz),
|
|
and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In,
|
|
Slave Out" (MISO) signals. (Other names are also used.) There are four
|
|
clocking modes through which data is exchanged; mode-0 and mode-3 are most
|
|
commonly used.
|
|
|
|
SPI masters may use a "chip select" line to activate a given SPI slave
|
|
device, so those three signal wires may be connected to several chips
|
|
in parallel. All SPI slaves support chipselects. Some devices have
|
|
other signals, often including an interrupt to the master.
|
|
|
|
Unlike serial busses like USB or SMBUS, even low level protocols for
|
|
SPI slave functions are usually not interoperable between vendors
|
|
(except for cases like SPI memory chips).
|
|
|
|
- SPI may be used for request/response style device protocols, as with
|
|
touchscreen sensors and memory chips.
|
|
|
|
- It may also be used to stream data in either direction (half duplex),
|
|
or both of them at the same time (full duplex).
|
|
|
|
- Some devices may use eight bit words. Others may different word
|
|
lengths, such as streams of 12-bit or 20-bit digital samples.
|
|
|
|
In the same way, SPI slaves will only rarely support any kind of automatic
|
|
discovery/enumeration protocol. The tree of slave devices accessible from
|
|
a given SPI master will normally be set up manually, with configuration
|
|
tables.
|
|
|
|
SPI is only one of the names used by such four-wire protocols, and
|
|
most controllers have no problem handling "MicroWire" (think of it as
|
|
half-duplex SPI, for request/response protocols), SSP ("Synchronous
|
|
Serial Protocol"), PSP ("Programmable Serial Protocol"), and other
|
|
related protocols.
|
|
|
|
Microcontrollers often support both master and slave sides of the SPI
|
|
protocol. This document (and Linux) currently only supports the master
|
|
side of SPI interactions.
|
|
|
|
|
|
Who uses it? On what kinds of systems?
|
|
---------------------------------------
|
|
Linux developers using SPI are probably writing device drivers for embedded
|
|
systems boards. SPI is used to control external chips, and it is also a
|
|
protocol supported by every MMC or SD memory card. (The older "DataFlash"
|
|
cards, predating MMC cards but using the same connectors and card shape,
|
|
support only SPI.) Some PC hardware uses SPI flash for BIOS code.
|
|
|
|
SPI slave chips range from digital/analog converters used for analog
|
|
sensors and codecs, to memory, to peripherals like USB controllers
|
|
or Ethernet adapters; and more.
|
|
|
|
Most systems using SPI will integrate a few devices on a mainboard.
|
|
Some provide SPI links on expansion connectors; in cases where no
|
|
dedicated SPI controller exists, GPIO pins can be used to create a
|
|
low speed "bitbanging" adapter. Very few systems will "hotplug" an SPI
|
|
controller; the reasons to use SPI focus on low cost and simple operation,
|
|
and if dynamic reconfiguration is important, USB will often be a more
|
|
appropriate low-pincount peripheral bus.
|
|
|
|
Many microcontrollers that can run Linux integrate one or more I/O
|
|
interfaces with SPI modes. Given SPI support, they could use MMC or SD
|
|
cards without needing a special purpose MMC/SD/SDIO controller.
|
|
|
|
|
|
How do these driver programming interfaces work?
|
|
------------------------------------------------
|
|
The <linux/spi/spi.h> header file includes kerneldoc, as does the
|
|
main source code, and you should certainly read that. This is just
|
|
an overview, so you get the big picture before the details.
|
|
|
|
There are two types of SPI driver, here called:
|
|
|
|
Controller drivers ... these are often built in to System-On-Chip
|
|
processors, and often support both Master and Slave roles.
|
|
These drivers touch hardware registers and may use DMA.
|
|
|
|
Protocol drivers ... these pass messages through the controller
|
|
driver to communicate with a Slave or Master device on the
|
|
other side of an SPI link.
|
|
|
|
So for example one protocol driver might talk to the MTD layer to export
|
|
data to filesystems stored on SPI flash like DataFlash; and others might
|
|
control audio interfaces, present touchscreen sensors as input interfaces,
|
|
or monitor temperature and voltage levels during industrial processing.
|
|
And those might all be sharing the same controller driver.
|
|
|
|
A "struct spi_device" encapsulates the master-side interface between
|
|
those two types of driver. At this writing, Linux has no slave side
|
|
programming interface.
|
|
|
|
There is a minimal core of SPI programming interfaces, focussing on
|
|
using driver model to connect controller and protocol drivers using
|
|
device tables provided by board specific initialization code. SPI
|
|
shows up in sysfs in several locations:
|
|
|
|
/sys/devices/.../CTLR/spiB.C ... spi_device for on bus "B",
|
|
chipselect C, accessed through CTLR.
|
|
|
|
/sys/bus/spi/devices/spiB.C ... symlink to the physical
|
|
spiB-C device
|
|
|
|
/sys/bus/spi/drivers/D ... driver for one or more spi*.* devices
|
|
|
|
/sys/class/spi_master/spiB ... class device for the controller
|
|
managing bus "B". All the spiB.* devices share the same
|
|
physical SPI bus segment, with SCLK, MOSI, and MISO.
|
|
|
|
The basic I/O primitive submits an asynchronous message to an I/O queue
|
|
maintained by the controller driver. A completion callback is issued
|
|
asynchronously when the data transfer(s) in that message completes.
|
|
There are also some simple synchronous wrappers for those calls.
|
|
|
|
|
|
How does board-specific init code declare SPI devices?
|
|
------------------------------------------------------
|
|
Linux needs several kinds of information to properly configure SPI devices.
|
|
That information is normally provided by board-specific code, even for
|
|
chips that do support some of automated discovery/enumeration.
|
|
|
|
DECLARE CONTROLLERS
|
|
|
|
The first kind of information is a list of what SPI controllers exist.
|
|
For System-on-Chip (SOC) based boards, these will usually be platform
|
|
devices, and the controller may need some platform_data in order to
|
|
operate properly. The "struct platform_device" will include resources
|
|
like the physical address of the controller's first register and its IRQ.
|
|
|
|
Platforms will often abstract the "register SPI controller" operation,
|
|
maybe coupling it with code to initialize pin configurations, so that
|
|
the arch/.../mach-*/board-*.c files for several boards can all share the
|
|
same basic controller setup code. This is because most SOCs have several
|
|
SPI-capable controllers, and only the ones actually usable on a given
|
|
board should normally be set up and registered.
|
|
|
|
So for example arch/.../mach-*/board-*.c files might have code like:
|
|
|
|
#include <asm/arch/spi.h> /* for mysoc_spi_data */
|
|
|
|
/* if your mach-* infrastructure doesn't support kernels that can
|
|
* run on multiple boards, pdata wouldn't benefit from "__init".
|
|
*/
|
|
static struct mysoc_spi_data __init pdata = { ... };
|
|
|
|
static __init board_init(void)
|
|
{
|
|
...
|
|
/* this board only uses SPI controller #2 */
|
|
mysoc_register_spi(2, &pdata);
|
|
...
|
|
}
|
|
|
|
And SOC-specific utility code might look something like:
|
|
|
|
#include <asm/arch/spi.h>
|
|
|
|
static struct platform_device spi2 = { ... };
|
|
|
|
void mysoc_register_spi(unsigned n, struct mysoc_spi_data *pdata)
|
|
{
|
|
struct mysoc_spi_data *pdata2;
|
|
|
|
pdata2 = kmalloc(sizeof *pdata2, GFP_KERNEL);
|
|
*pdata2 = pdata;
|
|
...
|
|
if (n == 2) {
|
|
spi2->dev.platform_data = pdata2;
|
|
register_platform_device(&spi2);
|
|
|
|
/* also: set up pin modes so the spi2 signals are
|
|
* visible on the relevant pins ... bootloaders on
|
|
* production boards may already have done this, but
|
|
* developer boards will often need Linux to do it.
|
|
*/
|
|
}
|
|
...
|
|
}
|
|
|
|
Notice how the platform_data for boards may be different, even if the
|
|
same SOC controller is used. For example, on one board SPI might use
|
|
an external clock, where another derives the SPI clock from current
|
|
settings of some master clock.
|
|
|
|
|
|
DECLARE SLAVE DEVICES
|
|
|
|
The second kind of information is a list of what SPI slave devices exist
|
|
on the target board, often with some board-specific data needed for the
|
|
driver to work correctly.
|
|
|
|
Normally your arch/.../mach-*/board-*.c files would provide a small table
|
|
listing the SPI devices on each board. (This would typically be only a
|
|
small handful.) That might look like:
|
|
|
|
static struct ads7846_platform_data ads_info = {
|
|
.vref_delay_usecs = 100,
|
|
.x_plate_ohms = 580,
|
|
.y_plate_ohms = 410,
|
|
};
|
|
|
|
static struct spi_board_info spi_board_info[] __initdata = {
|
|
{
|
|
.modalias = "ads7846",
|
|
.platform_data = &ads_info,
|
|
.mode = SPI_MODE_0,
|
|
.irq = GPIO_IRQ(31),
|
|
.max_speed_hz = 120000 /* max sample rate at 3V */ * 16,
|
|
.bus_num = 1,
|
|
.chip_select = 0,
|
|
},
|
|
};
|
|
|
|
Again, notice how board-specific information is provided; each chip may need
|
|
several types. This example shows generic constraints like the fastest SPI
|
|
clock to allow (a function of board voltage in this case) or how an IRQ pin
|
|
is wired, plus chip-specific constraints like an important delay that's
|
|
changed by the capacitance at one pin.
|
|
|
|
(There's also "controller_data", information that may be useful to the
|
|
controller driver. An example would be peripheral-specific DMA tuning
|
|
data or chipselect callbacks. This is stored in spi_device later.)
|
|
|
|
The board_info should provide enough information to let the system work
|
|
without the chip's driver being loaded. The most troublesome aspect of
|
|
that is likely the SPI_CS_HIGH bit in the spi_device.mode field, since
|
|
sharing a bus with a device that interprets chipselect "backwards" is
|
|
not possible.
|
|
|
|
Then your board initialization code would register that table with the SPI
|
|
infrastructure, so that it's available later when the SPI master controller
|
|
driver is registered:
|
|
|
|
spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));
|
|
|
|
Like with other static board-specific setup, you won't unregister those.
|
|
|
|
|
|
NON-STATIC CONFIGURATIONS
|
|
|
|
Developer boards often play by different rules than product boards, and one
|
|
example is the potential need to hotplug SPI devices and/or controllers.
|
|
|
|
For those cases you might need to use use spi_busnum_to_master() to look
|
|
up the spi bus master, and will likely need spi_new_device() to provide the
|
|
board info based on the board that was hotplugged. Of course, you'd later
|
|
call at least spi_unregister_device() when that board is removed.
|
|
|
|
|
|
How do I write an "SPI Protocol Driver"?
|
|
----------------------------------------
|
|
All SPI drivers are currently kernel drivers. A userspace driver API
|
|
would just be another kernel driver, probably offering some lowlevel
|
|
access through aio_read(), aio_write(), and ioctl() calls and using the
|
|
standard userspace sysfs mechanisms to bind to a given SPI device.
|
|
|
|
SPI protocol drivers are normal device drivers, with no more wrapper
|
|
than needed by platform devices:
|
|
|
|
static struct device_driver CHIP_driver = {
|
|
.name = "CHIP",
|
|
.bus = &spi_bus_type,
|
|
.probe = CHIP_probe,
|
|
.remove = __exit_p(CHIP_remove),
|
|
.suspend = CHIP_suspend,
|
|
.resume = CHIP_resume,
|
|
};
|
|
|
|
The SPI core will autmatically attempt to bind this driver to any SPI
|
|
device whose board_info gave a modalias of "CHIP". Your probe() code
|
|
might look like this unless you're creating a class_device:
|
|
|
|
static int __init CHIP_probe(struct device *dev)
|
|
{
|
|
struct spi_device *spi = to_spi_device(dev);
|
|
struct CHIP *chip;
|
|
struct CHIP_platform_data *pdata = dev->platform_data;
|
|
|
|
/* get memory for driver's per-chip state */
|
|
chip = kzalloc(sizeof *chip, GFP_KERNEL);
|
|
if (!chip)
|
|
return -ENOMEM;
|
|
dev_set_drvdata(dev, chip);
|
|
|
|
... etc
|
|
return 0;
|
|
}
|
|
|
|
As soon as it enters probe(), the driver may issue I/O requests to
|
|
the SPI device using "struct spi_message". When remove() returns,
|
|
the driver guarantees that it won't submit any more such messages.
|
|
|
|
- An spi_message is a sequence of of protocol operations, executed
|
|
as one atomic sequence. SPI driver controls include:
|
|
|
|
+ when bidirectional reads and writes start ... by how its
|
|
sequence of spi_transfer requests is arranged;
|
|
|
|
+ optionally defining short delays after transfers ... using
|
|
the spi_transfer.delay_usecs setting;
|
|
|
|
+ whether the chipselect becomes inactive after a transfer and
|
|
any delay ... by using the spi_transfer.cs_change flag;
|
|
|
|
+ hinting whether the next message is likely to go to this same
|
|
device ... using the spi_transfer.cs_change flag on the last
|
|
transfer in that atomic group, and potentially saving costs
|
|
for chip deselect and select operations.
|
|
|
|
- Follow standard kernel rules, and provide DMA-safe buffers in
|
|
your messages. That way controller drivers using DMA aren't forced
|
|
to make extra copies unless the hardware requires it (e.g. working
|
|
around hardware errata that force the use of bounce buffering).
|
|
|
|
If standard dma_map_single() handling of these buffers is inappropriate,
|
|
you can use spi_message.is_dma_mapped to tell the controller driver
|
|
that you've already provided the relevant DMA addresses.
|
|
|
|
- The basic I/O primitive is spi_async(). Async requests may be
|
|
issued in any context (irq handler, task, etc) and completion
|
|
is reported using a callback provided with the message.
|
|
|
|
- There are also synchronous wrappers like spi_sync(), and wrappers
|
|
like spi_read(), spi_write(), and spi_write_then_read(). These
|
|
may be issued only in contexts that may sleep, and they're all
|
|
clean (and small, and "optional") layers over spi_async().
|
|
|
|
- The spi_write_then_read() call, and convenience wrappers around
|
|
it, should only be used with small amounts of data where the
|
|
cost of an extra copy may be ignored. It's designed to support
|
|
common RPC-style requests, such as writing an eight bit command
|
|
and reading a sixteen bit response -- spi_w8r16() being one its
|
|
wrappers, doing exactly that.
|
|
|
|
Some drivers may need to modify spi_device characteristics like the
|
|
transfer mode, wordsize, or clock rate. This is done with spi_setup(),
|
|
which would normally be called from probe() before the first I/O is
|
|
done to the device.
|
|
|
|
While "spi_device" would be the bottom boundary of the driver, the
|
|
upper boundaries might include sysfs (especially for sensor readings),
|
|
the input layer, ALSA, networking, MTD, the character device framework,
|
|
or other Linux subsystems.
|
|
|
|
|
|
How do I write an "SPI Master Controller Driver"?
|
|
-------------------------------------------------
|
|
An SPI controller will probably be registered on the platform_bus; write
|
|
a driver to bind to the device, whichever bus is involved.
|
|
|
|
The main task of this type of driver is to provide an "spi_master".
|
|
Use spi_alloc_master() to allocate the master, and class_get_devdata()
|
|
to get the driver-private data allocated for that device.
|
|
|
|
struct spi_master *master;
|
|
struct CONTROLLER *c;
|
|
|
|
master = spi_alloc_master(dev, sizeof *c);
|
|
if (!master)
|
|
return -ENODEV;
|
|
|
|
c = class_get_devdata(&master->cdev);
|
|
|
|
The driver will initialize the fields of that spi_master, including the
|
|
bus number (maybe the same as the platform device ID) and three methods
|
|
used to interact with the SPI core and SPI protocol drivers. It will
|
|
also initialize its own internal state.
|
|
|
|
master->setup(struct spi_device *spi)
|
|
This sets up the device clock rate, SPI mode, and word sizes.
|
|
Drivers may change the defaults provided by board_info, and then
|
|
call spi_setup(spi) to invoke this routine. It may sleep.
|
|
|
|
master->transfer(struct spi_device *spi, struct spi_message *message)
|
|
This must not sleep. Its responsibility is arrange that the
|
|
transfer happens and its complete() callback is issued; the two
|
|
will normally happen later, after other transfers complete.
|
|
|
|
master->cleanup(struct spi_device *spi)
|
|
Your controller driver may use spi_device.controller_state to hold
|
|
state it dynamically associates with that device. If you do that,
|
|
be sure to provide the cleanup() method to free that state.
|
|
|
|
The bulk of the driver will be managing the I/O queue fed by transfer().
|
|
|
|
That queue could be purely conceptual. For example, a driver used only
|
|
for low-frequency sensor acess might be fine using synchronous PIO.
|
|
|
|
But the queue will probably be very real, using message->queue, PIO,
|
|
often DMA (especially if the root filesystem is in SPI flash), and
|
|
execution contexts like IRQ handlers, tasklets, or workqueues (such
|
|
as keventd). Your driver can be as fancy, or as simple, as you need.
|
|
|
|
|
|
THANKS TO
|
|
---------
|
|
Contributors to Linux-SPI discussions include (in alphabetical order,
|
|
by last name):
|
|
|
|
David Brownell
|
|
Russell King
|
|
Dmitry Pervushin
|
|
Stephen Street
|
|
Mark Underwood
|
|
Andrew Victor
|
|
Vitaly Wool
|
|
|