STRUCT SPI_DEVICE(9) Serial Peripheral Interface (S STRUCT SPI_DEVICE(9)NAME
struct_spi_device - Master side proxy for an SPI slave device
SYNOPSIS
struct spi_device {
struct device dev;
struct spi_master * master;
u32 max_speed_hz;
u8 chip_select;
u8 mode;
#define SPI_CPHA 0x01
#define SPI_CPOL 0x02
#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
#define SPI_LSB_FIRST 0x08
#define SPI_3WIRE 0x10
#define SPI_LOOP 0x20
#define SPI_NO_CS 0x40
#define SPI_READY 0x80
u8 bits_per_word;
int irq;
void * controller_state;
void * controller_data;
char modalias[SPI_NAME_SIZE];
int cs_gpio;
};
MEMBERS
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. The spi_transfer.speed_hz can
override this for each transfer.
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. The "active low" default for
chipselect mode can be overridden (by specifying SPI_CS_HIGH) as can the "MSB first" default for each word in a transfer (by specifying
SPI_LSB_FIRST).
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, or left at the default (0) indicating protocol words are
eight bit bytes. The spi_transfer.bits_per_word can override this for each transfer.
irq
Negative, or the number passed to request_irq to receive interrupts from this device.
controller_state
Controller's runtime state
controller_data
Board-specific definitions for controller, such as FIFO initialization parameters; from board_info.controller_data
modalias[SPI_NAME_SIZE]
Name of the driver to use with this device, or an alias for that name. This appears in the sysfs "modalias" attribute for driver
coldplugging, and in uevents used for hotplugging
cs_gpio
gpio number of the chipselect line (optional, -ENOENT when when not using a GPIO line)
DESCRIPTION
A 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; another might be information about
how this particular board wires the chip's pins.
COPYRIGHT Kernel Hackers Manual 3.10 June 2014 STRUCT SPI_DEVICE(9)
Check Out this Related Man Page
STRUCT SPI_TRANSFER(9) Serial Peripheral Interface (S STRUCT SPI_TRANSFER(9)NAME
struct_spi_transfer - a read/write buffer pair
SYNOPSIS
struct spi_transfer {
const void * tx_buf;
void * rx_buf;
unsigned len;
dma_addr_t tx_dma;
dma_addr_t rx_dma;
unsigned cs_change:1;
u8 bits_per_word;
u16 delay_usecs;
u32 speed_hz;
struct list_head transfer_list;
};
MEMBERS
tx_buf
data to be written (dma-safe memory), or NULL
rx_buf
data to be read (dma-safe memory), or NULL
len
size of rx and tx buffers (in bytes)
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
cs_change
affects chipselect after this transfer completes
bits_per_word
select a bits_per_word other than the device default for this transfer. If 0 the default (from spi_device) is used.
delay_usecs
microseconds to delay after this transfer before (optionally) changing the chipselect status, then starting the next transfer or
completing this spi_message.
speed_hz
Select a speed other than the device default for this transfer. If 0 the default (from spi_device) is used.
transfer_list
transfers are sequenced through spi_message.transfers
DESCRIPTION
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.
If the transmit buffer is null, zeroes 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.)
In-memory data values are always in native CPU byte order, translated from the wire byte order (big-endian except with SPI_LSB_FIRST). So
for example when bits_per_word is sixteen, buffers are 2N bytes long (len = 2N) and hold N sixteen bit words in CPU byte order.
When the word size of the SPI transfer is not a power-of-two multiple of eight bits, those in-memory words include extra bits. In-memory
words are always seen by protocol drivers as right-justified, so the undefined (rx) or unused (tx) bits are always the most significant
bits.
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
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. On multi-device SPI busses with
nothing blocking messages going to other devices, this is just a performance hint; starting a message to another device deselects this one.
But in other cases, this can be used to ensure correctness. Some devices need protocol transactions to be built from a series of
spi_message submissions, where the content of one message is determined by the results of previous messages and where the whole transaction
ends when the chipselect goes intactive.
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. After you submit a message and its transfers, ignore them
until its completion callback.
COPYRIGHT Kernel Hackers Manual 3.10 June 2014 STRUCT SPI_TRANSFER(9)