Lines Matching +full:slave +full:- +full:kernel
2 Overview of Linux kernel SPI support
5 02-Feb-2012
8 ------------
12 standardization body. SPI uses a master/slave configuration.
15 and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In,
16 Slave Out" (MISO) signals. (Other names are also used.) There are four
17 clocking modes through which data is exchanged; mode-0 and mode-3 are most
22 SPI masters use a fourth "chip select" line to activate a given SPI slave
25 low signals, labeled nCSx for slave 'x' (e.g. nCS0). Some devices have
29 SPI slave functions are usually not interoperable between vendors
32 - SPI may be used for request/response style device protocols, as with
35 - It may also be used to stream data in either direction (half duplex),
38 - Some devices may use eight bit words. Others may use different word
39 lengths, such as streams of 12-bit or 20-bit digital samples.
41 - Words are usually sent with their most significant bit (MSB) first,
44 - Sometimes SPI is used to daisy-chain devices, like shift registers.
47 discovery/enumeration protocol. The tree of slave devices accessible from
51 SPI is only one of the names used by such four-wire protocols, and
53 half-duplex SPI, for request/response protocols), SSP ("Synchronous
58 limiting themselves to half-duplex at the hardware level. In fact
65 Microcontrollers often support both master and slave sides of the SPI
66 protocol. This document (and Linux) supports both the master and slave
71 ---------------------------------------
78 SPI slave chips range from digital/analog converters used for analog
88 appropriate low-pincount peripheral bus.
96 -----------------------------------------------------
100 - CPOL indicates the initial clock polarity. CPOL=0 means the
105 - CPHA indicates the clock phase used to sample data; CPHA=0 says
122 a slave, and the slave can tell the chosen polarity by sampling the
129 ------------------------------------------------
132 kernel API document. This is just an overview, so you get the big
144 controllers may be built into System-On-Chip
145 processors, and often support both Master and Slave roles.
151 driver to communicate with a Slave or Master device on the
160 A "struct spi_device" encapsulates the controller-side interface between
186 /sys/devices/.../CTLR/slave ... virtual file for (un)registering the
187 slave device for an SPI slave controller.
188 Writing the driver name of an SPI slave handler to this file
189 registers the slave device; writing "(null)" unregisters the slave
191 Reading from this file shows the name of the slave device ("(null)"
196 slave controller on bus "B". When registered, a single spiB.*
198 segment with other SPI slave devices.
202 the only class-specific state is the bus number ("B" in "spiB"), so
206 How does board-specific init code declare SPI devices?
207 ------------------------------------------------------
209 That information is normally provided by board-specific code, even for
216 For System-on-Chip (SOC) based boards, these will usually be platform
223 the arch/.../mach-*/board-*.c files for several boards can all share the
225 SPI-capable controllers, and only the ones actually usable on a given
228 So for example arch/.../mach-*/board-*.c files might have code like::
232 /* if your mach-* infrastructure doesn't support kernels that can
245 And SOC-specific utility code might look something like::
259 spi2->dev.platform_data = pdata2;
276 Declare Slave Devices
279 The second kind of information is a list of what SPI slave devices exist
280 on the target board, often with some board-specific data needed for the
283 Normally your arch/.../mach-*/board-*.c files would provide a small table
305 Again, notice how board-specific information is provided; each chip may need
308 is wired, plus chip-specific constraints like an important delay that's
312 controller driver. An example would be peripheral-specific DMA tuning
327 Like with other static board-specific setup, you won't unregister those.
331 your ``arch/.../mach-.../board-*.c`` file would primarily provide information
336 Non-static Configurations
345 ----------------------------------------
346 Most SPI drivers are currently kernel drivers, but there's also support
347 for userspace drivers. Here we talk only about kernel drivers.
374 /* assuming the driver requires board-specific data: */
375 pdata = &spi->dev.platform_data;
377 return -ENODEV;
379 /* get memory for driver's per-chip state */
382 return -ENOMEM;
394 - An spi_message is a sequence of protocol operations, executed
420 - Follow standard kernel rules, and provide DMA-safe buffers in
429 - The basic I/O primitive is spi_async(). Async requests may be
435 - There are also synchronous wrappers like spi_sync(), and wrappers
440 - The spi_write_then_read() call, and convenience wrappers around
443 common RPC-style requests, such as writing an eight bit command
444 and reading a sixteen bit response -- spi_w8r16() being one its
461 - I/O buffers use the usual Linux rules, and must be DMA-safe.
465 - The spi_message and spi_transfer metadata used to glue those
468 other allocate-once driver data structures. Zero-init these.
471 routines are available to allocate and zero-initialize an spi_message
476 -------------------------------------------------
482 to get the driver-private data allocated for that device.
491 return -ENODEV;
519 If you don't have such hardware-assigned bus number, and for some reason
522 this as a non-static configuration (see above).
528 ``master->setup(struct spi_device *spi)``
533 Unless each SPI slave has its own configuration registers, don't
544 ``master->cleanup(struct spi_device *spi)``
549 ``master->prepare_transfer_hardware(struct spi_master *master)``
555 ``master->unprepare_transfer_hardware(struct spi_master *master)``
560 ``master->transfer_one_message(struct spi_master *master, struct spi_message *mesg)``
567 ``master->transfer_one(struct spi_master *master, struct spi_device *spi, struct spi_transfer *tran…
582 ``master->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, u8 hold_clk_cycles, u8 inactiv…
590 ``master->transfer(struct spi_device *spi, struct spi_message *message)``
606 providing pure process-context execution of methods. The message queue
607 can also be elevated to realtime priority on high-priority SPI traffic.
614 for low-frequency sensor access might be fine using synchronous PIO.
616 But the queue will probably be very real, using message->queue, PIO,
626 ---------
627 Contributors to Linux-SPI discussions include (in alphabetical order,
630 - Mark Brown
631 - David Brownell
632 - Russell King
633 - Grant Likely
634 - Dmitry Pervushin
635 - Stephen Street
636 - Mark Underwood
637 - Andrew Victor
638 - Linus Walleij
639 - Vitaly Wool