Lines Matching +full:clock +full:- +full:master

5 02-Feb-2012
8 ------------
12 standardization body. SPI uses a master/slave configuration.
14 The three signal wires hold a clock (SCK, often on the order of 10 MHz),
15 and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In,
17 clocking modes through which data is exchanged; mode-0 and mode-3 are most
18 commonly used. Each clock cycle shifts data out and data in; the clock
26 other signals, often including an interrupt to the master.
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.
48 a given SPI master will normally be set up manually, with configuration
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 ---------------------------------------
88 appropriate low-pincount peripheral bus.
95 I'm confused. What are these four SPI "clock modes"?
96 -----------------------------------------------------
100 - CPOL indicates the initial clock polarity. CPOL=0 means the
101 clock starts low, so the first (leading) edge is rising, and
102 the second (trailing) edge is falling. CPOL=1 means the clock
105 - CPHA indicates the clock phase used to sample data; CPHA=0 says
109 implies that its data is written half a clock before the first
110 clock edge. The chipselect may have made it become available.
116 low order bit. So when a chip's timing diagram shows the clock
118 trailing clock edge (CPHA=1), that's SPI mode 1.
120 Note that the clock mode is relevant as soon as the chipselect goes
121 active. So the master must set the clock to inactive before selecting
123 clock level when its select line goes active. That's why many devices
125 and always clock data in/out on rising clock edges.
129 ------------------------------------------------
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
183 master controller managing bus "B". All spiB.* devices share one
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;
273 an external clock, where another derives the SPI clock from current
274 settings of some master clock.
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
307 clock to allow (a function of board voltage in this case) or how an IRQ pin
308 is wired, plus chip-specific constraints like an important delay that's
312 controller driver. An example would be peripheral-specific DMA tuning
322 infrastructure, so that it's available later when the SPI master controller
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
343 up the spi bus master, and will likely need spi_new_device() to provide the
353 ----------------------------------------
382 /* assuming the driver requires board-specific data: */
383 pdata = &spi->dev.platform_data;
385 return -ENODEV;
387 /* get memory for driver's per-chip state */
390 return -ENOMEM;
402 - An spi_message is a sequence of protocol operations, executed
425 - Follow standard kernel rules, and provide DMA-safe buffers in
434 - The basic I/O primitive is spi_async(). Async requests may be
440 - There are also synchronous wrappers like spi_sync(), and wrappers
445 - The spi_write_then_read() call, and convenience wrappers around
448 common RPC-style requests, such as writing an eight bit command
449 and reading a sixteen bit response -- spi_w8r16() being one its
453 transfer mode, wordsize, or clock rate. This is done with spi_setup(),
466 - I/O buffers use the usual Linux rules, and must be DMA-safe.
470 - The spi_message and spi_transfer metadata used to glue those
473 other allocate-once driver data structures. Zero-init these.
476 routines are available to allocate and zero-initialize an spi_message
480 How do I write an "SPI Master Controller Driver"?
481 -------------------------------------------------
486 Use spi_alloc_master() to allocate the master, and spi_master_get_devdata()
487 to get the driver-private data allocated for that device.
491 struct spi_master *master;
494 master = spi_alloc_master(dev, sizeof *c);
495 if (!master)
496 return -ENODEV;
498 c = spi_master_get_devdata(master);
524 If you don't have such hardware-assigned bus number, and for some reason
527 this as a non-static configuration (see above).
530 SPI Master Methods
533 ``master->setup(struct spi_device *spi)``
534 This sets up the device clock rate, SPI mode, and word sizes.
549 ``master->cleanup(struct spi_device *spi)``
554 ``master->prepare_transfer_hardware(struct spi_master *master)``
560 ``master->unprepare_transfer_hardware(struct spi_master *master)``
565 ``master->transfer_one_message(struct spi_master *master, struct spi_message *mesg)``
572 ``master->transfer_one(struct spi_master *master, struct spi_device *spi, struct spi_transfer *tran…
587 ``master->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, u8 hold_clk_cycles, u8 inactiv…
588 This method allows SPI client drivers to request SPI master controller
595 ``master->transfer(struct spi_device *spi, struct spi_message *message)``
611 providing pure process-context execution of methods. The message queue
612 can also be elevated to realtime priority on high-priority SPI traffic.
619 for low-frequency sensor access might be fine using synchronous PIO.
621 But the queue will probably be very real, using message->queue, PIO,
631 ---------
632 Contributors to Linux-SPI discussions include (in alphabetical order,
635 - Mark Brown
636 - David Brownell
637 - Russell King
638 - Grant Likely
639 - Dmitry Pervushin
640 - Stephen Street
641 - Mark Underwood
642 - Andrew Victor
643 - Linus Walleij
644 - Vitaly Wool