From 8ae12a0d85987dc138f8c944cb78a92bf466cea0 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:19 -0800 Subject: [PATCH] spi: simple SPI framework 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 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 Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- include/linux/spi/spi.h | 542 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 542 insertions(+) create mode 100644 include/linux/spi/spi.h (limited to 'include') diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h new file mode 100644 index 0000000..51a6769 --- /dev/null +++ b/include/linux/spi/spi.h @@ -0,0 +1,542 @@ +/* + * Copyright (C) 2005 David Brownell + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#ifndef __LINUX_SPI_H +#define __LINUX_SPI_H + +/* + * INTERFACES between SPI master drivers and infrastructure + * (There's no SPI slave support for Linux yet...) + * + * A "struct device_driver" for an spi_device uses "spi_bus_type" and + * needs no special API wrappers (much like platform_bus). These drivers + * are bound to devices based on their names (much like platform_bus), + * and are available in dev->driver. + */ +extern struct bus_type spi_bus_type; + +/** + * struct spi_device - Master side proxy for an SPI slave device + * @dev: Driver model representation of the device. + * @master: SPI controller used with the device. + * @max_speed_hz: Maximum clock rate to be used with this chip + * (on this board); may be changed by the device's driver. + * @chip-select: Chipselect, distinguishing chips handled by "master". + * @mode: The spi mode defines how data is clocked out and in. + * This may be changed by the device's driver. + * @bits_per_word: Data transfers involve one or more words; word sizes + * like eight or 12 bits are common. In-memory wordsizes are + * powers of two bytes (e.g. 20 bit samples use 32 bits). + * This may be changed by the device's driver. + * @irq: Negative, or the number passed to request_irq() to receive + * interrupts from this device. + * @controller_state: Controller's runtime state + * @controller_data: Static board-specific definitions for controller, such + * as FIFO initialization parameters; from board_info.controller_data + * + * An spi_device is used to interchange data between an SPI slave + * (usually a discrete chip) and CPU memory. + * + * In "dev", the platform_data is used to hold information about this + * device that's meaningful to the device's protocol driver, but not + * to its controller. One example might be an identifier for a chip + * variant with slightly different functionality. + */ +struct spi_device { + struct device dev; + struct spi_master *master; + u32 max_speed_hz; + u8 chip_select; + u8 mode; +#define SPI_CPHA 0x01 /* clock phase */ +#define SPI_CPOL 0x02 /* clock polarity */ +#define SPI_MODE_0 (0|0) +#define SPI_MODE_1 (0|SPI_CPHA) +#define SPI_MODE_2 (SPI_CPOL|0) +#define SPI_MODE_3 (SPI_CPOL|SPI_CPHA) +#define SPI_CS_HIGH 0x04 /* chipselect active high? */ + u8 bits_per_word; + int irq; + void *controller_state; + const void *controller_data; + const char *modalias; + + // likely need more hooks for more protocol options affecting how + // the controller talks to its chips, like: + // - bit order (default is wordwise msb-first) + // - memory packing (12 bit samples into low bits, others zeroed) + // - priority + // - chipselect delays + // - ... +}; + +static inline struct spi_device *to_spi_device(struct device *dev) +{ + return container_of(dev, struct spi_device, dev); +} + +/* most drivers won't need to care about device refcounting */ +static inline struct spi_device *spi_dev_get(struct spi_device *spi) +{ + return (spi && get_device(&spi->dev)) ? spi : NULL; +} + +static inline void spi_dev_put(struct spi_device *spi) +{ + if (spi) + put_device(&spi->dev); +} + +/* ctldata is for the bus_master driver's runtime state */ +static inline void *spi_get_ctldata(struct spi_device *spi) +{ + return spi->controller_state; +} + +static inline void spi_set_ctldata(struct spi_device *spi, void *state) +{ + spi->controller_state = state; +} + + +struct spi_message; + + +/** + * struct spi_master - interface to SPI master controller + * @cdev: class interface to this driver + * @bus_num: board-specific (and often SOC-specific) identifier for a + * given SPI controller. + * @num_chipselects: chipselects are used to distinguish individual + * SPI slaves, and are numbered from zero to num_chipselects. + * each slave has a chipselect signal, but it's common that not + * every chipselect is connected to a slave. + * @setup: updates the device mode and clocking records used by a + * device's SPI controller; protocol code may call this. + * @transfer: adds a message to the controller's transfer queue. + * @cleanup: frees controller-specific state + * + * Each SPI master controller can communicate with one or more spi_device + * children. These make a small bus, sharing MOSI, MISO and SCK signals + * but not chip select signals. Each device may be configured to use a + * different clock rate, since those shared signals are ignored unless + * the chip is selected. + * + * The driver for an SPI controller manages access to those devices through + * a queue of spi_message transactions, copyin data between CPU memory and + * an SPI slave device). For each such message it queues, it calls the + * message's completion function when the transaction completes. + */ +struct spi_master { + struct class_device cdev; + + /* other than zero (== assign one dynamically), bus_num is fully + * board-specific. usually that simplifies to being SOC-specific. + * example: one SOC has three SPI controllers, numbered 1..3, + * and one board's schematics might show it using SPI-2. software + * would normally use bus_num=2 for that controller. + */ + u16 bus_num; + + /* chipselects will be integral to many controllers; some others + * might use board-specific GPIOs. + */ + u16 num_chipselect; + + /* setup mode and clock, etc (spi driver may call many times) */ + int (*setup)(struct spi_device *spi); + + /* bidirectional bulk transfers + * + * + The transfer() method may not sleep; its main role is + * just to add the message to the queue. + * + For now there's no remove-from-queue operation, or + * any other request management + * + To a given spi_device, message queueing is pure fifo + * + * + The master's main job is to process its message queue, + * selecting a chip then transferring data + * + If there are multiple spi_device children, the i/o queue + * arbitration algorithm is unspecified (round robin, fifo, + * priority, reservations, preemption, etc) + * + * + Chipselect stays active during the entire message + * (unless modified by spi_transfer.cs_change != 0). + * + The message transfers use clock and SPI mode parameters + * previously established by setup() for this device + */ + int (*transfer)(struct spi_device *spi, + struct spi_message *mesg); + + /* called on release() to free memory provided by spi_master */ + void (*cleanup)(const struct spi_device *spi); +}; + +/* the spi driver core manages memory for the spi_master classdev */ +extern struct spi_master * +spi_alloc_master(struct device *host, unsigned size); + +extern int spi_register_master(struct spi_master *master); +extern void spi_unregister_master(struct spi_master *master); + +extern struct spi_master *spi_busnum_to_master(u16 busnum); + +/*---------------------------------------------------------------------------*/ + +/* + * I/O INTERFACE between SPI controller and protocol drivers + * + * Protocol drivers use a queue of spi_messages, each transferring data + * between the controller and memory buffers. + * + * The spi_messages themselves consist of a series of read+write transfer + * segments. Those segments always read the same number of bits as they + * write; but one or the other is easily ignored by passing a null buffer + * pointer. (This is unlike most types of I/O API, because SPI hardware + * is full duplex.) + * + * NOTE: Allocation of spi_transfer and spi_message memory is entirely + * up to the protocol driver, which guarantees the integrity of both (as + * well as the data buffers) for as long as the message is queued. + */ + +/** + * struct spi_transfer - a read/write buffer pair + * @tx_buf: data to be written (dma-safe address), or NULL + * @rx_buf: data to be read (dma-safe address), or NULL + * @tx_dma: DMA address of buffer, if spi_message.is_dma_mapped + * @rx_dma: DMA address of buffer, if spi_message.is_dma_mapped + * @len: size of rx and tx buffers (in bytes) + * @cs_change: affects chipselect after this transfer completes + * @delay_usecs: microseconds to delay after this transfer before + * (optionally) changing the chipselect status, then starting + * the next transfer or completing this spi_message. + * + * SPI transfers always write the same number of bytes as they read. + * Protocol drivers should always provide rx_buf and/or tx_buf. + * In some cases, they may also want to provide DMA addresses for + * the data being transferred; that may reduce overhead, when the + * underlying driver uses dma. + * + * All SPI transfers start with the relevant chipselect active. Drivers + * can change behavior of the chipselect after the transfer finishes + * (including any mandatory delay). The normal behavior is to leave it + * selected, except for the last transfer in a message. Setting cs_change + * allows two additional behavior options: + * + * (i) If the transfer isn't the last one in the message, this flag is + * used to make the chipselect briefly go inactive in the middle of the + * message. Toggling chipselect in this way may be needed to terminate + * a chip command, letting a single spi_message perform all of group of + * chip transactions together. + * + * (ii) When the transfer is the last one in the message, the chip may + * stay selected until the next transfer. This is purely a performance + * hint; the controller driver may need to select a different device + * for the next message. + */ +struct spi_transfer { + /* it's ok if tx_buf == rx_buf (right?) + * for MicroWire, one buffer must be null + * buffers must work with dma_*map_single() calls + */ + const void *tx_buf; + void *rx_buf; + unsigned len; + + dma_addr_t tx_dma; + dma_addr_t rx_dma; + + unsigned cs_change:1; + u16 delay_usecs; +}; + +/** + * struct spi_message - one multi-segment SPI transaction + * @transfers: the segements of the transaction + * @n_transfer: how many segments + * @spi: SPI device to which the transaction is queued + * @is_dma_mapped: if true, the caller provided both dma and cpu virtual + * addresses for each transfer buffer + * @complete: called to report transaction completions + * @context: the argument to complete() when it's called + * @actual_length: how many bytes were transferd + * @status: zero for success, else negative errno + * @queue: for use by whichever driver currently owns the message + * @state: for use by whichever driver currently owns the message + */ +struct spi_message { + struct spi_transfer *transfers; + unsigned n_transfer; + + struct spi_device *spi; + + unsigned is_dma_mapped:1; + + /* REVISIT: we might want a flag affecting the behavior of the + * last transfer ... allowing things like "read 16 bit length L" + * immediately followed by "read L bytes". Basically imposing + * a specific message scheduling algorithm. + * + * Some controller drivers (message-at-a-time queue processing) + * could provide that as their default scheduling algorithm. But + * others (with multi-message pipelines) would need a flag to + * tell them about such special cases. + */ + + /* completion is reported through a callback */ + void FASTCALL((*complete)(void *context)); + void *context; + unsigned actual_length; + int status; + + /* for optional use by whatever driver currently owns the + * spi_message ... between calls to spi_async and then later + * complete(), that's the spi_master controller driver. + */ + struct list_head queue; + void *state; +}; + +/** + * spi_setup -- setup SPI mode and clock rate + * @spi: the device whose settings are being modified + * + * SPI protocol drivers may need to update the transfer mode if the + * device doesn't work with the mode 0 default. They may likewise need + * to update clock rates or word sizes from initial values. This function + * changes those settings, and must be called from a context that can sleep. + */ +static inline int +spi_setup(struct spi_device *spi) +{ + return spi->master->setup(spi); +} + + +/** + * spi_async -- asynchronous SPI transfer + * @spi: device with which data will be exchanged + * @message: describes the data transfers, including completion callback + * + * This call may be used in_irq and other contexts which can't sleep, + * as well as from task contexts which can sleep. + * + * The completion callback is invoked in a context which can't sleep. + * Before that invocation, the value of message->status is undefined. + * When the callback is issued, message->status holds either zero (to + * indicate complete success) or a negative error code. + * + * Note that although all messages to a spi_device are handled in + * FIFO order, messages may go to different devices in other orders. + * Some device might be higher priority, or have various "hard" access + * time requirements, for example. + */ +static inline int +spi_async(struct spi_device *spi, struct spi_message *message) +{ + message->spi = spi; + return spi->master->transfer(spi, message); +} + +/*---------------------------------------------------------------------------*/ + +/* All these synchronous SPI transfer routines are utilities layered + * over the core async transfer primitive. Here, "synchronous" means + * they will sleep uninterruptibly until the async transfer completes. + */ + +extern int spi_sync(struct spi_device *spi, struct spi_message *message); + +/** + * spi_write - SPI synchronous write + * @spi: device to which data will be written + * @buf: data buffer + * @len: data buffer size + * + * This writes the buffer and returns zero or a negative error code. + * Callable only from contexts that can sleep. + */ +static inline int +spi_write(struct spi_device *spi, const u8 *buf, size_t len) +{ + struct spi_transfer t = { + .tx_buf = buf, + .rx_buf = NULL, + .len = len, + .cs_change = 0, + }; + struct spi_message m = { + .transfers = &t, + .n_transfer = 1, + }; + + return spi_sync(spi, &m); +} + +/** + * spi_read - SPI synchronous read + * @spi: device from which data will be read + * @buf: data buffer + * @len: data buffer size + * + * This writes the buffer and returns zero or a negative error code. + * Callable only from contexts that can sleep. + */ +static inline int +spi_read(struct spi_device *spi, u8 *buf, size_t len) +{ + struct spi_transfer t = { + .tx_buf = NULL, + .rx_buf = buf, + .len = len, + .cs_change = 0, + }; + struct spi_message m = { + .transfers = &t, + .n_transfer = 1, + }; + + return spi_sync(spi, &m); +} + +extern int spi_write_then_read(struct spi_device *spi, + const u8 *txbuf, unsigned n_tx, + u8 *rxbuf, unsigned n_rx); + +/** + * spi_w8r8 - SPI synchronous 8 bit write followed by 8 bit read + * @spi: device with which data will be exchanged + * @cmd: command to be written before data is read back + * + * This returns the (unsigned) eight bit number returned by the + * device, or else a negative error code. Callable only from + * contexts that can sleep. + */ +static inline ssize_t spi_w8r8(struct spi_device *spi, u8 cmd) +{ + ssize_t status; + u8 result; + + status = spi_write_then_read(spi, &cmd, 1, &result, 1); + + /* return negative errno or unsigned value */ + return (status < 0) ? status : result; +} + +/** + * spi_w8r16 - SPI synchronous 8 bit write followed by 16 bit read + * @spi: device with which data will be exchanged + * @cmd: command to be written before data is read back + * + * This returns the (unsigned) sixteen bit number returned by the + * device, or else a negative error code. Callable only from + * contexts that can sleep. + * + * The number is returned in wire-order, which is at least sometimes + * big-endian. + */ +static inline ssize_t spi_w8r16(struct spi_device *spi, u8 cmd) +{ + ssize_t status; + u16 result; + + status = spi_write_then_read(spi, &cmd, 1, (u8 *) &result, 2); + + /* return negative errno or unsigned value */ + return (status < 0) ? status : result; +} + +/*---------------------------------------------------------------------------*/ + +/* + * INTERFACE between board init code and SPI infrastructure. + * + * No SPI driver ever sees these SPI device table segments, but + * it's how the SPI core (or adapters that get hotplugged) grows + * the driver model tree. + * + * As a rule, SPI devices can't be probed. Instead, board init code + * provides a table listing the devices which are present, with enough + * information to bind and set up the device's driver. There's basic + * support for nonstatic configurations too; enough to handle adding + * parport adapters, or microcontrollers acting as USB-to-SPI bridges. + */ + +/* board-specific information about each SPI device */ +struct spi_board_info { + /* the device name and module name are coupled, like platform_bus; + * "modalias" is normally the driver name. + * + * platform_data goes to spi_device.dev.platform_data, + * controller_data goes to spi_device.platform_data, + * irq is copied too + */ + char modalias[KOBJ_NAME_LEN]; + const void *platform_data; + const void *controller_data; + int irq; + + /* slower signaling on noisy or low voltage boards */ + u32 max_speed_hz; + + + /* bus_num is board specific and matches the bus_num of some + * spi_master that will probably be registered later. + * + * chip_select reflects how this chip is wired to that master; + * it's less than num_chipselect. + */ + u16 bus_num; + u16 chip_select; + + /* ... may need additional spi_device chip config data here. + * avoid stuff protocol drivers can set; but include stuff + * needed to behave without being bound to a driver: + * - chipselect polarity + * - quirks like clock rate mattering when not selected + */ +}; + +#ifdef CONFIG_SPI +extern int +spi_register_board_info(struct spi_board_info const *info, unsigned n); +#else +/* board init code may ignore whether SPI is configured or not */ +static inline int +spi_register_board_info(struct spi_board_info const *info, unsigned n) + { return 0; } +#endif + + +/* If you're hotplugging an adapter with devices (parport, usb, etc) + * use spi_new_device() to describe each device. You can also call + * spi_unregister_device() to get start making that device vanish, + * but normally that would be handled by spi_unregister_master(). + */ +extern struct spi_device * +spi_new_device(struct spi_master *, struct spi_board_info *); + +static inline void +spi_unregister_device(struct spi_device *spi) +{ + if (spi) + device_unregister(&spi->dev); +} + +#endif /* __LINUX_SPI_H */ -- cgit v1.1 From ffa458c1bd9b6f653008d450f337602f3d52a646 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:21 -0800 Subject: [PATCH] spi: ads7846 driver This is a driver for the ADS7846 touchscreen sensor, derived from the corgi_ts and omap_ts drivers. Key differences from those two: - Uses the new SPI framework (minimalist version) - abstracts board-specific touchscreen info - Sysfs attributes for the temperature and voltage sensors - Uses fewer ARM-specific IRQ primitives The temperature and voltage sensors show up in sysfs like this: $ pwd /sys/devices/platform/omap-uwire/spi2.0 $ ls bus@ input:event0@ power/ temp1 vbatt driver@ modalias temp0 vaux $ cat modalias ads7846 $ cat temp0 991 $ cat temp1 1177 $ So far only basic testing has been done. There's a fair amount of hardware that uses this sensor, and which also runs Linux, which should eventually be able to use this driver. One portability note may be of special interest. It turns out that not all SPI controllers are happy issuing requests that do things like "write 8 bit command, read 12 bit response". Most of them seem happy to handle various word sizes, so the issue isn't "12 bit response" but rather "different rx and tx write sizes", despite that being a common MicroWire convention. So this version of the driver no longer reads 12 bit native-endian words; it reads 16-bit big-endian responses, then byteswaps them and shifts the results to discard the noise. Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- include/linux/spi/ads7846.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 include/linux/spi/ads7846.h (limited to 'include') diff --git a/include/linux/spi/ads7846.h b/include/linux/spi/ads7846.h new file mode 100644 index 0000000..84a2701 --- /dev/null +++ b/include/linux/spi/ads7846.h @@ -0,0 +1,18 @@ +/* linux/spi/ads7846.h */ + +/* Touchscreen characteristics vary between boards and models. The + * platform_data for the device's "struct device" holts this information. + * + * It's OK if the min/max values are zero. + */ +struct ads7846_platform_data { + u16 model; /* 7843, 7845, 7846. */ + u16 vref_delay_usecs; /* 0 for external vref; etc */ + u16 x_plate_ohms; + u16 y_plate_ohms; + + u16 x_min, x_max; + u16 y_min, y_max; + u16 pressure_min, pressure_max; +}; + -- cgit v1.1 From 1d6432fe10c3e724e307dd7137cd293a0edcae80 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:22 -0800 Subject: [PATCH] spi: mtd dataflash driver This is a conversion of the AT91rm9200 DataFlash MTD driver to use the lightweight SPI framework, and no longer be AT91-specific. It compiles down to less than 3KBytes on ARM. The driver allows board-specific init code to provide platform_data with the relevant MTD partitioning information, and hotplugs. This version has been lightly tested. Its parent at91_dataflash driver has been pretty well banged on, although kernel.org JFFS2 dataflash support was acting broken the last time I tried it. Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- include/linux/spi/flash.h | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 include/linux/spi/flash.h (limited to 'include') diff --git a/include/linux/spi/flash.h b/include/linux/spi/flash.h new file mode 100644 index 0000000..2ce6558 --- /dev/null +++ b/include/linux/spi/flash.h @@ -0,0 +1,27 @@ +#ifndef LINUX_SPI_FLASH_H +#define LINUX_SPI_FLASH_H + +struct mtd_partition; + +/** + * struct flash_platform_data: board-specific flash data + * @name: optional flash device name (eg, as used with mtdparts=) + * @parts: optional array of mtd_partitions for static partitioning + * @nr_parts: number of mtd_partitions for static partitoning + * + * Board init code (in arch/.../mach-xxx/board-yyy.c files) can + * provide information about SPI flash parts (such as DataFlash) to + * help set up the device and its appropriate default partitioning. + * + * Note that for DataFlash, sizes for pages, blocks, and sectors are + * rarely powers of two; and partitions should be sector-aligned. + */ +struct flash_platform_data { + char *name; + struct mtd_partition *parts; + unsigned int nr_parts; + + /* we'll likely add more ... use JEDEC IDs, etc */ +}; + +#endif -- cgit v1.1 From b885244eb2628e0b8206e7edaaa6a314da78e9a4 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:23 -0800 Subject: [PATCH] spi: add spi_driver to SPI framework This is a refresh of the "Simple SPI Framework" found in 2.6.15-rc3-mm1 which makes the following changes: * There's now a "struct spi_driver". This increase the footprint of the core a bit, since it now includes code to do what the driver core was previously handling directly. Documentation and comments were updated to match. * spi_alloc_master() now does class_device_initialize(), so it can at least be refcounted before spi_register_master(). To match, spi_register_master() switched over to class_device_add(). * States explicitly that after transfer errors, spi_devices will be deselected. We want fault recovery procedures to work the same for all controller drivers. * Minor tweaks: controller_data no longer points to readonly data; prevent some potential cast-from-null bugs with container_of calls; clarifies some existing kerneldoc, And a few small cleanups. Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- include/linux/spi/spi.h | 75 ++++++++++++++++++++++++++++++++++--------------- 1 file changed, 52 insertions(+), 23 deletions(-) (limited to 'include') diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 51a6769..c851b3d 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -20,13 +20,8 @@ #define __LINUX_SPI_H /* - * INTERFACES between SPI master drivers and infrastructure + * INTERFACES between SPI master-side drivers and SPI infrastructure. * (There's no SPI slave support for Linux yet...) - * - * A "struct device_driver" for an spi_device uses "spi_bus_type" and - * needs no special API wrappers (much like platform_bus). These drivers - * are bound to devices based on their names (much like platform_bus), - * and are available in dev->driver. */ extern struct bus_type spi_bus_type; @@ -46,8 +41,8 @@ extern struct bus_type spi_bus_type; * @irq: Negative, or the number passed to request_irq() to receive * interrupts from this device. * @controller_state: Controller's runtime state - * @controller_data: Static board-specific definitions for controller, such - * as FIFO initialization parameters; from board_info.controller_data + * @controller_data: Board-specific definitions for controller, such as + * FIFO initialization parameters; from board_info.controller_data * * An spi_device is used to interchange data between an SPI slave * (usually a discrete chip) and CPU memory. @@ -63,31 +58,32 @@ struct spi_device { u32 max_speed_hz; u8 chip_select; u8 mode; -#define SPI_CPHA 0x01 /* clock phase */ -#define SPI_CPOL 0x02 /* clock polarity */ +#define SPI_CPHA 0x01 /* clock phase */ +#define SPI_CPOL 0x02 /* clock polarity */ #define SPI_MODE_0 (0|0) -#define SPI_MODE_1 (0|SPI_CPHA) +#define SPI_MODE_1 (0|SPI_CPHA) /* (original MicroWire) */ #define SPI_MODE_2 (SPI_CPOL|0) #define SPI_MODE_3 (SPI_CPOL|SPI_CPHA) -#define SPI_CS_HIGH 0x04 /* chipselect active high? */ +#define SPI_CS_HIGH 0x04 /* chipselect active high? */ u8 bits_per_word; int irq; void *controller_state; - const void *controller_data; + void *controller_data; const char *modalias; // likely need more hooks for more protocol options affecting how - // the controller talks to its chips, like: + // the controller talks to each chip, like: // - bit order (default is wordwise msb-first) // - memory packing (12 bit samples into low bits, others zeroed) // - priority + // - drop chipselect after each word // - chipselect delays // - ... }; static inline struct spi_device *to_spi_device(struct device *dev) { - return container_of(dev, struct spi_device, dev); + return dev ? container_of(dev, struct spi_device, dev) : NULL; } /* most drivers won't need to care about device refcounting */ @@ -117,12 +113,38 @@ static inline void spi_set_ctldata(struct spi_device *spi, void *state) struct spi_message; + +struct spi_driver { + int (*probe)(struct spi_device *spi); + int (*remove)(struct spi_device *spi); + void (*shutdown)(struct spi_device *spi); + int (*suspend)(struct spi_device *spi, pm_message_t mesg); + int (*resume)(struct spi_device *spi); + struct device_driver driver; +}; + +static inline struct spi_driver *to_spi_driver(struct device_driver *drv) +{ + return drv ? container_of(drv, struct spi_driver, driver) : NULL; +} + +extern int spi_register_driver(struct spi_driver *sdrv); + +static inline void spi_unregister_driver(struct spi_driver *sdrv) +{ + if (!sdrv) + return; + driver_unregister(&sdrv->driver); +} + + + /** * struct spi_master - interface to SPI master controller * @cdev: class interface to this driver * @bus_num: board-specific (and often SOC-specific) identifier for a * given SPI controller. - * @num_chipselects: chipselects are used to distinguish individual + * @num_chipselect: chipselects are used to distinguish individual * SPI slaves, and are numbered from zero to num_chipselects. * each slave has a chipselect signal, but it's common that not * every chipselect is connected to a slave. @@ -275,7 +297,8 @@ struct spi_transfer { * addresses for each transfer buffer * @complete: called to report transaction completions * @context: the argument to complete() when it's called - * @actual_length: how many bytes were transferd + * @actual_length: the total number of bytes that were transferred in all + * successful segments * @status: zero for success, else negative errno * @queue: for use by whichever driver currently owns the message * @state: for use by whichever driver currently owns the message @@ -295,7 +318,7 @@ struct spi_message { * * Some controller drivers (message-at-a-time queue processing) * could provide that as their default scheduling algorithm. But - * others (with multi-message pipelines) would need a flag to + * others (with multi-message pipelines) could need a flag to * tell them about such special cases. */ @@ -346,6 +369,13 @@ spi_setup(struct spi_device *spi) * FIFO order, messages may go to different devices in other orders. * Some device might be higher priority, or have various "hard" access * time requirements, for example. + * + * On detection of any fault during the transfer, processing of + * the entire message is aborted, and the device is deselected. + * Until returning from the associated message completion callback, + * no other spi_message queued to that device will be processed. + * (This rule applies equally to all the synchronous transfer calls, + * which are wrappers around this core asynchronous primitive.) */ static inline int spi_async(struct spi_device *spi, struct spi_message *message) @@ -484,12 +514,12 @@ struct spi_board_info { * "modalias" is normally the driver name. * * platform_data goes to spi_device.dev.platform_data, - * controller_data goes to spi_device.platform_data, + * controller_data goes to spi_device.controller_data, * irq is copied too */ char modalias[KOBJ_NAME_LEN]; const void *platform_data; - const void *controller_data; + void *controller_data; int irq; /* slower signaling on noisy or low voltage boards */ @@ -525,9 +555,8 @@ spi_register_board_info(struct spi_board_info const *info, unsigned n) /* If you're hotplugging an adapter with devices (parport, usb, etc) - * use spi_new_device() to describe each device. You can also call - * spi_unregister_device() to get start making that device vanish, - * but normally that would be handled by spi_unregister_master(). + * use spi_new_device() to describe each device. You would then call + * spi_unregister_device() to start making that device vanish. */ extern struct spi_device * spi_new_device(struct spi_master *, struct spi_board_info *); -- cgit v1.1 From 0c868461fcb8413cb9f691d68e5b99b0fd3c0737 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:25 -0800 Subject: [PATCH] SPI core tweaks, bugfix This includes various updates to the SPI core: - Fixes a driver model refcount bug in spi_unregister_master() paths. - The spi_master structures now have wrappers which help keep drivers from needing class-level get/put for device data or for refcounts. - Check for a few setup errors that would cause oopsing later. - Docs say more about memory management. Highlights the use of DMA-safe i/o buffers, and zero-initializing spi_message and such metadata. - Provide a simple alloc/free for spi_message and its spi_transfer; this is only one of the possible memory management policies. Nothing to break code that already works. Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- include/linux/spi/spi.h | 75 +++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 69 insertions(+), 6 deletions(-) (limited to 'include') diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index c851b3d..6a41e26 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -60,8 +60,8 @@ struct spi_device { u8 mode; #define SPI_CPHA 0x01 /* clock phase */ #define SPI_CPOL 0x02 /* clock polarity */ -#define SPI_MODE_0 (0|0) -#define SPI_MODE_1 (0|SPI_CPHA) /* (original MicroWire) */ +#define SPI_MODE_0 (0|0) /* (original MicroWire) */ +#define SPI_MODE_1 (0|SPI_CPHA) #define SPI_MODE_2 (SPI_CPOL|0) #define SPI_MODE_3 (SPI_CPOL|SPI_CPHA) #define SPI_CS_HIGH 0x04 /* chipselect active high? */ @@ -209,6 +209,30 @@ struct spi_master { void (*cleanup)(const struct spi_device *spi); }; +static inline void *spi_master_get_devdata(struct spi_master *master) +{ + return class_get_devdata(&master->cdev); +} + +static inline void spi_master_set_devdata(struct spi_master *master, void *data) +{ + class_set_devdata(&master->cdev, data); +} + +static inline struct spi_master *spi_master_get(struct spi_master *master) +{ + if (!master || !class_device_get(&master->cdev)) + return NULL; + return master; +} + +static inline void spi_master_put(struct spi_master *master) +{ + if (master) + class_device_put(&master->cdev); +} + + /* the spi driver core manages memory for the spi_master classdev */ extern struct spi_master * spi_alloc_master(struct device *host, unsigned size); @@ -271,11 +295,17 @@ extern struct spi_master *spi_busnum_to_master(u16 busnum); * stay selected until the next transfer. This is purely a performance * hint; the controller driver may need to select a different device * for the next message. + * + * The code that submits an spi_message (and its spi_transfers) + * to the lower layers is responsible for managing its memory. + * Zero-initialize every field you don't set up explicitly, to + * insulate against future API updates. */ struct spi_transfer { /* it's ok if tx_buf == rx_buf (right?) * for MicroWire, one buffer must be null - * buffers must work with dma_*map_single() calls + * buffers must work with dma_*map_single() calls, unless + * spi_message.is_dma_mapped reports a pre-existing mapping */ const void *tx_buf; void *rx_buf; @@ -302,6 +332,11 @@ struct spi_transfer { * @status: zero for success, else negative errno * @queue: for use by whichever driver currently owns the message * @state: for use by whichever driver currently owns the message + * + * The code that submits an spi_message (and its spi_transfers) + * to the lower layers is responsible for managing its memory. + * Zero-initialize every field you don't set up explicitly, to + * insulate against future API updates. */ struct spi_message { struct spi_transfer *transfers; @@ -336,6 +371,29 @@ struct spi_message { void *state; }; +/* It's fine to embed message and transaction structures in other data + * structures so long as you don't free them while they're in use. + */ + +static inline struct spi_message *spi_message_alloc(unsigned ntrans, gfp_t flags) +{ + struct spi_message *m; + + m = kzalloc(sizeof(struct spi_message) + + ntrans * sizeof(struct spi_transfer), + flags); + if (m) { + m->transfers = (void *)(m + 1); + m->n_transfer = ntrans; + } + return m; +} + +static inline void spi_message_free(struct spi_message *m) +{ + kfree(m); +} + /** * spi_setup -- setup SPI mode and clock rate * @spi: the device whose settings are being modified @@ -363,7 +421,10 @@ spi_setup(struct spi_device *spi) * The completion callback is invoked in a context which can't sleep. * Before that invocation, the value of message->status is undefined. * When the callback is issued, message->status holds either zero (to - * indicate complete success) or a negative error code. + * indicate complete success) or a negative error code. After that + * callback returns, the driver which issued the transfer request may + * deallocate the associated memory; it's no longer in use by any SPI + * core or controller driver code. * * Note that although all messages to a spi_device are handled in * FIFO order, messages may go to different devices in other orders. @@ -445,6 +506,7 @@ spi_read(struct spi_device *spi, u8 *buf, size_t len) return spi_sync(spi, &m); } +/* this copies txbuf and rxbuf data; for small transfers only! */ extern int spi_write_then_read(struct spi_device *spi, const u8 *txbuf, unsigned n_tx, u8 *rxbuf, unsigned n_rx); @@ -555,8 +617,9 @@ spi_register_board_info(struct spi_board_info const *info, unsigned n) /* If you're hotplugging an adapter with devices (parport, usb, etc) - * use spi_new_device() to describe each device. You would then call - * spi_unregister_device() to start making that device vanish. + * use spi_new_device() to describe each device. You can also call + * spi_unregister_device() to start making that device vanish, but + * normally that would be handled by spi_unregister_master(). */ extern struct spi_device * spi_new_device(struct spi_master *, struct spi_board_info *); -- cgit v1.1 From 2e5a7bd978bf4118a0c8edf2e6ff81d0a72fee47 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:25 -0800 Subject: [PATCH] spi: ads7836 uses spi_driver This updates the ads7864 driver to use the new "spi_driver" struct, and includes some minor unrelated cleanup. Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- include/linux/spi/ads7846.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include') diff --git a/include/linux/spi/ads7846.h b/include/linux/spi/ads7846.h index 84a2701..72261e0 100644 --- a/include/linux/spi/ads7846.h +++ b/include/linux/spi/ads7846.h @@ -1,7 +1,7 @@ /* linux/spi/ads7846.h */ /* Touchscreen characteristics vary between boards and models. The - * platform_data for the device's "struct device" holts this information. + * platform_data for the device's "struct device" holds this information. * * It's OK if the min/max values are zero. */ -- cgit v1.1 From 9904f22a7202c6b54e96b0cc9870817013c350a1 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Sun, 8 Jan 2006 13:34:26 -0800 Subject: [PATCH] spi: add spi_bitbang driver This adds a bitbanging spi master, hooking up to board/adapter-specific glue code which knows how to set and read the signals (gpios etc). This code kicks in after the glue code creates a platform_device with the right platform_data. That data includes I/O loops, which will usually come from expanding an inline function (provided in the header). One goal is that the I/O loops should be easily optimized down to a few GPIO register accesses, in common cases, for speed and minimized overhead. This understands all the currently defined protocol tweaking options in the SPI framework, and might eventually serve as as reference implementation. - different word sizes (1..32 bits) - differing clock rates - SPI modes differing by CPOL (affecting chip select and I/O loops) - SPI modes differing by CPHA (affecting I/O loops) - delays (usecs) after transfers - temporarily deselecting chips in mid-transfer A lot of hardware could work with this framework, though common types of controller can't reach peak performance without switching to a driver structure that supports pipelining of transfers (e.g. DMA queues) and maybe controllers (e.g. IRQ driven). Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- include/linux/spi/spi_bitbang.h | 128 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 include/linux/spi/spi_bitbang.h (limited to 'include') diff --git a/include/linux/spi/spi_bitbang.h b/include/linux/spi/spi_bitbang.h new file mode 100644 index 0000000..8dfe61a --- /dev/null +++ b/include/linux/spi/spi_bitbang.h @@ -0,0 +1,128 @@ +#ifndef __SPI_BITBANG_H +#define __SPI_BITBANG_H + +/* + * Mix this utility code with some glue code to get one of several types of + * simple SPI master driver. Two do polled word-at-a-time I/O: + * + * - GPIO/parport bitbangers. Provide chipselect() and txrx_word[](), + * expanding the per-word routines from the inline templates below. + * + * - Drivers for controllers resembling bare shift registers. Provide + * chipselect() and txrx_word[](), with custom setup()/cleanup() methods + * that use your controller's clock and chipselect registers. + * + * Some hardware works well with requests at spi_transfer scope: + * + * - Drivers leveraging smarter hardware, with fifos or DMA; or for half + * duplex (MicroWire) controllers. Provide chipslect() and txrx_bufs(), + * and custom setup()/cleanup() methods. + */ +struct spi_bitbang { + struct workqueue_struct *workqueue; + struct work_struct work; + + spinlock_t lock; + struct list_head queue; + u8 busy; + u8 shutdown; + u8 use_dma; + + struct spi_master *master; + + void (*chipselect)(struct spi_device *spi, int is_on); + + int (*txrx_bufs)(struct spi_device *spi, struct spi_transfer *t); + u32 (*txrx_word[4])(struct spi_device *spi, + unsigned nsecs, + u32 word, u8 bits); +}; + +/* you can call these default bitbang->master methods from your custom + * methods, if you like. + */ +extern int spi_bitbang_setup(struct spi_device *spi); +extern void spi_bitbang_cleanup(const struct spi_device *spi); +extern int spi_bitbang_transfer(struct spi_device *spi, struct spi_message *m); + +/* start or stop queue processing */ +extern int spi_bitbang_start(struct spi_bitbang *spi); +extern int spi_bitbang_stop(struct spi_bitbang *spi); + +#endif /* __SPI_BITBANG_H */ + +/*-------------------------------------------------------------------------*/ + +#ifdef EXPAND_BITBANG_TXRX + +/* + * The code that knows what GPIO pins do what should have declared four + * functions, ideally as inlines, before #defining EXPAND_BITBANG_TXRX + * and including this header: + * + * void setsck(struct spi_device *, int is_on); + * void setmosi(struct spi_device *, int is_on); + * int getmiso(struct spi_device *); + * void spidelay(unsigned); + * + * A non-inlined routine would call bitbang_txrx_*() routines. The + * main loop could easily compile down to a handful of instructions, + * especially if the delay is a NOP (to run at peak speed). + * + * Since this is software, the timings may not be exactly what your board's + * chips need ... there may be several reasons you'd need to tweak timings + * in these routines, not just make to make it faster or slower to match a + * particular CPU clock rate. + */ + +static inline u32 +bitbang_txrx_be_cpha0(struct spi_device *spi, + unsigned nsecs, unsigned cpol, + u32 word, u8 bits) +{ + /* if (cpol == 0) this is SPI_MODE_0; else this is SPI_MODE_2 */ + + /* clock starts at inactive polarity */ + for (word <<= (32 - bits); likely(bits); bits--) { + + /* setup MSB (to slave) on trailing edge */ + setmosi(spi, word & (1 << 31)); + spidelay(nsecs); /* T(setup) */ + + setsck(spi, !cpol); + spidelay(nsecs); + + /* sample MSB (from slave) on leading edge */ + word <<= 1; + word |= getmiso(spi); + setsck(spi, cpol); + } + return word; +} + +static inline u32 +bitbang_txrx_be_cpha1(struct spi_device *spi, + unsigned nsecs, unsigned cpol, + u32 word, u8 bits) +{ + /* if (cpol == 0) this is SPI_MODE_1; else this is SPI_MODE_3 */ + + /* clock starts at inactive polarity */ + for (word <<= (32 - bits); likely(bits); bits--) { + + /* setup MSB (to slave) on leading edge */ + setsck(spi, !cpol); + setmosi(spi, word & (1 << 31)); + spidelay(nsecs); /* T(setup) */ + + setsck(spi, cpol); + spidelay(nsecs); + + /* sample MSB (from slave) on trailing edge */ + word <<= 1; + word |= getmiso(spi); + } + return word; +} + +#endif /* EXPAND_BITBANG_TXRX */ -- cgit v1.1 From 2f9f762879015d738a5ec2ac8a16be94b3a4a06d Mon Sep 17 00:00:00 2001 From: Mike Lavender Date: Sun, 8 Jan 2006 13:34:27 -0800 Subject: [PATCH] spi: M25 series SPI flash This was originally a driver for the ST M25P80 SPI flash. It's been updated slightly to handle other M25P series chips. For many of these chips, the specific type could be probed, but for now this just requires static setup with flash_platform_data that lists the chip type (size, format) and any default partitioning to use. Signed-off-by: David Brownell Cc: Mike Lavender Cc: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- include/linux/spi/flash.h | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'include') diff --git a/include/linux/spi/flash.h b/include/linux/spi/flash.h index 2ce6558..3f22932 100644 --- a/include/linux/spi/flash.h +++ b/include/linux/spi/flash.h @@ -8,6 +8,8 @@ struct mtd_partition; * @name: optional flash device name (eg, as used with mtdparts=) * @parts: optional array of mtd_partitions for static partitioning * @nr_parts: number of mtd_partitions for static partitoning + * @type: optional flash device type (e.g. m25p80 vs m25p64), for use + * with chips that can't be queried for JEDEC or other IDs * * Board init code (in arch/.../mach-xxx/board-yyy.c files) can * provide information about SPI flash parts (such as DataFlash) to @@ -21,6 +23,8 @@ struct flash_platform_data { struct mtd_partition *parts; unsigned int nr_parts; + char *type; + /* we'll likely add more ... use JEDEC IDs, etc */ }; -- cgit v1.1 From 8275c642ccdce09a2146d0a9eb022e3698ee927e Mon Sep 17 00:00:00 2001 From: Vitaly Wool Date: Sun, 8 Jan 2006 13:34:28 -0800 Subject: [PATCH] spi: use linked lists rather than an array This makes the SPI core and its users access transfers in the SPI message structure as linked list not as an array, as discussed on LKML. From: David Brownell Updates including doc, bugfixes to the list code, add spi_message_add_tail(). Plus, initialize things _before_ grabbing the locks in some cases (in case it grows more expensive). This also merges some bitbang updates of mine that didn't yet make it into the mm tree. Signed-off-by: Vitaly Wool Signed-off-by: Dmitry Pervushin Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- include/linux/spi/spi.h | 92 ++++++++++++++++++++++++++++------------- include/linux/spi/spi_bitbang.h | 7 ++++ 2 files changed, 70 insertions(+), 29 deletions(-) (limited to 'include') diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 6a41e26..939afd3 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -263,15 +263,16 @@ extern struct spi_master *spi_busnum_to_master(u16 busnum); /** * struct spi_transfer - a read/write buffer pair - * @tx_buf: data to be written (dma-safe address), or NULL - * @rx_buf: data to be read (dma-safe address), or NULL - * @tx_dma: DMA address of buffer, if spi_message.is_dma_mapped - * @rx_dma: DMA address of buffer, if spi_message.is_dma_mapped + * @tx_buf: data to be written (dma-safe memory), or NULL + * @rx_buf: data to be read (dma-safe memory), or NULL + * @tx_dma: DMA address of tx_buf, if spi_message.is_dma_mapped + * @rx_dma: DMA address of rx_buf, if spi_message.is_dma_mapped * @len: size of rx and tx buffers (in bytes) * @cs_change: affects chipselect after this transfer completes * @delay_usecs: microseconds to delay after this transfer before * (optionally) changing the chipselect status, then starting * the next transfer or completing this spi_message. + * @transfer_list: transfers are sequenced through spi_message.transfers * * SPI transfers always write the same number of bytes as they read. * Protocol drivers should always provide rx_buf and/or tx_buf. @@ -279,11 +280,16 @@ extern struct spi_master *spi_busnum_to_master(u16 busnum); * the data being transferred; that may reduce overhead, when the * underlying driver uses dma. * - * All SPI transfers start with the relevant chipselect active. Drivers - * can change behavior of the chipselect after the transfer finishes - * (including any mandatory delay). The normal behavior is to leave it - * selected, except for the last transfer in a message. Setting cs_change - * allows two additional behavior options: + * If the transmit buffer is null, undefined data will be shifted out + * while filling rx_buf. If the receive buffer is null, the data + * shifted in will be discarded. Only "len" bytes shift out (or in). + * It's an error to try to shift out a partial word. (For example, by + * shifting out three bytes with word size of sixteen or twenty bits; + * the former uses two bytes per word, the latter uses four bytes.) + * + * All SPI transfers start with the relevant chipselect active. Normally + * it stays selected until after the last transfer in a message. Drivers + * can affect the chipselect signal using cs_change: * * (i) If the transfer isn't the last one in the message, this flag is * used to make the chipselect briefly go inactive in the middle of the @@ -299,7 +305,8 @@ extern struct spi_master *spi_busnum_to_master(u16 busnum); * The code that submits an spi_message (and its spi_transfers) * to the lower layers is responsible for managing its memory. * Zero-initialize every field you don't set up explicitly, to - * insulate against future API updates. + * insulate against future API updates. After you submit a message + * and its transfers, ignore them until its completion callback. */ struct spi_transfer { /* it's ok if tx_buf == rx_buf (right?) @@ -316,12 +323,13 @@ struct spi_transfer { unsigned cs_change:1; u16 delay_usecs; + + struct list_head transfer_list; }; /** * struct spi_message - one multi-segment SPI transaction - * @transfers: the segements of the transaction - * @n_transfer: how many segments + * @transfers: list of transfer segments in this transaction * @spi: SPI device to which the transaction is queued * @is_dma_mapped: if true, the caller provided both dma and cpu virtual * addresses for each transfer buffer @@ -333,14 +341,22 @@ struct spi_transfer { * @queue: for use by whichever driver currently owns the message * @state: for use by whichever driver currently owns the message * + * An spi_message is used to execute an atomic sequence of data transfers, + * each represented by a struct spi_transfer. The sequence is "atomic" + * in the sense that no other spi_message may use that SPI bus until that + * sequence completes. On some systems, many such sequences can execute as + * as single programmed DMA transfer. On all systems, these messages are + * queued, and might complete after transactions to other devices. Messages + * sent to a given spi_device are alway executed in FIFO order. + * * The code that submits an spi_message (and its spi_transfers) * to the lower layers is responsible for managing its memory. * Zero-initialize every field you don't set up explicitly, to - * insulate against future API updates. + * insulate against future API updates. After you submit a message + * and its transfers, ignore them until its completion callback. */ struct spi_message { - struct spi_transfer *transfers; - unsigned n_transfer; + struct list_head transfers; struct spi_device *spi; @@ -371,6 +387,24 @@ struct spi_message { void *state; }; +static inline void spi_message_init(struct spi_message *m) +{ + memset(m, 0, sizeof *m); + INIT_LIST_HEAD(&m->transfers); +} + +static inline void +spi_message_add_tail(struct spi_transfer *t, struct spi_message *m) +{ + list_add_tail(&t->transfer_list, &m->transfers); +} + +static inline void +spi_transfer_del(struct spi_transfer *t) +{ + list_del(&t->transfer_list); +} + /* It's fine to embed message and transaction structures in other data * structures so long as you don't free them while they're in use. */ @@ -383,8 +417,12 @@ static inline struct spi_message *spi_message_alloc(unsigned ntrans, gfp_t flags + ntrans * sizeof(struct spi_transfer), flags); if (m) { - m->transfers = (void *)(m + 1); - m->n_transfer = ntrans; + int i; + struct spi_transfer *t = (struct spi_transfer *)(m + 1); + + INIT_LIST_HEAD(&m->transfers); + for (i = 0; i < ntrans; i++, t++) + spi_message_add_tail(t, m); } return m; } @@ -402,6 +440,8 @@ static inline void spi_message_free(struct spi_message *m) * device doesn't work with the mode 0 default. They may likewise need * to update clock rates or word sizes from initial values. This function * changes those settings, and must be called from a context that can sleep. + * The changes take effect the next time the device is selected and data + * is transferred to or from it. */ static inline int spi_setup(struct spi_device *spi) @@ -468,15 +508,12 @@ spi_write(struct spi_device *spi, const u8 *buf, size_t len) { struct spi_transfer t = { .tx_buf = buf, - .rx_buf = NULL, .len = len, - .cs_change = 0, - }; - struct spi_message m = { - .transfers = &t, - .n_transfer = 1, }; + struct spi_message m; + spi_message_init(&m); + spi_message_add_tail(&t, &m); return spi_sync(spi, &m); } @@ -493,16 +530,13 @@ static inline int spi_read(struct spi_device *spi, u8 *buf, size_t len) { struct spi_transfer t = { - .tx_buf = NULL, .rx_buf = buf, .len = len, - .cs_change = 0, - }; - struct spi_message m = { - .transfers = &t, - .n_transfer = 1, }; + struct spi_message m; + spi_message_init(&m); + spi_message_add_tail(&t, &m); return spi_sync(spi, &m); } diff --git a/include/linux/spi/spi_bitbang.h b/include/linux/spi/spi_bitbang.h index 8dfe61a..c961fe9 100644 --- a/include/linux/spi/spi_bitbang.h +++ b/include/linux/spi/spi_bitbang.h @@ -31,8 +31,15 @@ struct spi_bitbang { struct spi_master *master; void (*chipselect)(struct spi_device *spi, int is_on); +#define BITBANG_CS_ACTIVE 1 /* normally nCS, active low */ +#define BITBANG_CS_INACTIVE 0 + /* txrx_bufs() may handle dma mapping for transfers that don't + * already have one (transfer.{tx,rx}_dma is zero), or use PIO + */ int (*txrx_bufs)(struct spi_device *spi, struct spi_transfer *t); + + /* txrx_word[SPI_MODE_*]() just looks like a shift register */ u32 (*txrx_word[4])(struct spi_device *spi, unsigned nsecs, u32 word, u8 bits); -- cgit v1.1 From 5d870c8e216f121307445c71caa72e7e10a20061 Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Wed, 11 Jan 2006 11:23:49 -0800 Subject: [PATCH] spi: remove fastcall crap gcc4 generates warnings when a non-FASTCALL function pointer is assigned to a FASTCALL one. Perhaps it has taste. Cc: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- include/linux/spi/spi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include') diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 939afd3..b05f146 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -374,7 +374,7 @@ struct spi_message { */ /* completion is reported through a callback */ - void FASTCALL((*complete)(void *context)); + void (*complete)(void *context); void *context; unsigned actual_length; int status; -- cgit v1.1