Lines Matching +full:clock +full:- +full:names
4 21-May-2007
7 ------------
13 The three signal wires hold a clock (SCK, often on the order of 10 MHz),
15 Slave Out" (MISO) signals. (Other names are also used.) There are four
16 clocking modes through which data is exchanged; mode-0 and mode-3 are most
17 commonly used. Each clock cycle shifts data out and data in; the clock
31 - SPI may be used for request/response style device protocols, as with
34 - It may also be used to stream data in either direction (half duplex),
37 - Some devices may use eight bit words. Others may different word
38 lengths, such as streams of 12-bit or 20-bit digital samples.
40 - Words are usually sent with their most significant bit (MSB) first,
43 - Sometimes SPI is used to daisy-chain devices, like shift registers.
50 SPI is only one of the names used by such four-wire protocols, and
52 half-duplex SPI, for request/response protocols), SSP ("Synchronous
57 limiting themselves to half-duplex at the hardware level. In fact
70 ---------------------------------------
87 appropriate low-pincount peripheral bus.
94 I'm confused. What are these four SPI "clock modes"?
95 -----------------------------------------------------
99 - CPOL indicates the initial clock polarity. CPOL=0 means the
100 clock starts low, so the first (leading) edge is rising, and
101 the second (trailing) edge is falling. CPOL=1 means the clock
104 - CPHA indicates the clock phase used to sample data; CPHA=0 says
108 implies that its data is written half a clock before the first
109 clock edge. The chipselect may have made it become available.
115 low order bit. So when a chip's timing diagram shows the clock
117 trailing clock edge (CPHA=1), that's SPI mode 1.
119 Note that the clock mode is relevant as soon as the chipselect goes
120 active. So the master must set the clock to inactive before selecting
122 clock level when its select line goes active. That's why many devices
124 and alway clock data in/out on rising clock edges.
128 ------------------------------------------------
142 Controller drivers ... controllers may be built in to System-On-Chip
157 A "struct spi_device" encapsulates the master-side interface between
186 the only class-specific state is the bus number ("B" in "spiB"), so
190 How does board-specific init code declare SPI devices?
191 ------------------------------------------------------
193 That information is normally provided by board-specific code, even for
199 For System-on-Chip (SOC) based boards, these will usually be platform
206 the arch/.../mach-*/board-*.c files for several boards can all share the
208 SPI-capable controllers, and only the ones actually usable on a given
211 So for example arch/.../mach-*/board-*.c files might have code like:
215 /* if your mach-* infrastructure doesn't support kernels that can
228 And SOC-specific utility code might look something like:
242 spi2->dev.platform_data = pdata2;
256 an external clock, where another derives the SPI clock from current
257 settings of some master clock.
263 on the target board, often with some board-specific data needed for the
266 Normally your arch/.../mach-*/board-*.c files would provide a small table
288 Again, notice how board-specific information is provided; each chip may need
290 clock to allow (a function of board voltage in this case) or how an IRQ pin
291 is wired, plus chip-specific constraints like an important delay that's
295 controller driver. An example would be peripheral-specific DMA tuning
310 Like with other static board-specific setup, you won't unregister those.
314 your arch/.../mach-.../board-*.c file would primarily provide information
319 NON-STATIC CONFIGURATIONS
335 ----------------------------------------
363 /* assuming the driver requires board-specific data: */
364 pdata = &spi->dev.platform_data;
366 return -ENODEV;
368 /* get memory for driver's per-chip state */
371 return -ENOMEM;
383 - An spi_message is a sequence of protocol operations, executed
406 - Follow standard kernel rules, and provide DMA-safe buffers in
415 - The basic I/O primitive is spi_async(). Async requests may be
421 - There are also synchronous wrappers like spi_sync(), and wrappers
426 - The spi_write_then_read() call, and convenience wrappers around
429 common RPC-style requests, such as writing an eight bit command
430 and reading a sixteen bit response -- spi_w8r16() being one its
434 transfer mode, wordsize, or clock rate. This is done with spi_setup(),
447 - I/O buffers use the usual Linux rules, and must be DMA-safe.
451 - The spi_message and spi_transfer metadata used to glue those
454 other allocate-once driver data structures. Zero-init these.
457 routines are available to allocate and zero-initialize an spi_message
462 -------------------------------------------------
468 to get the driver-private data allocated for that device.
475 return -ENODEV;
502 If you don't have such hardware-assigned bus number, and for some reason
505 this as a non-static configuration (see above).
510 master->setup(struct spi_device *spi)
511 This sets up the device clock rate, SPI mode, and word sizes.
524 master->transfer(struct spi_device *spi, struct spi_message *message)
530 master->cleanup(struct spi_device *spi)
541 for low-frequency sensor access might be fine using synchronous PIO.
543 But the queue will probably be very real, using message->queue, PIO,
553 ---------
554 Contributors to Linux-SPI discussions include (in alphabetical order,