Lines Matching +full:no +full:- +full:idle +full:- +full:on +full:- +full:init
5 02-Feb-2012
8 ------------
14 The three signal wires hold a clock (SCK, often on the order of 10 MHz),
17 clocking modes through which data is exchanged; mode-0 and mode-3 are most
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.
51 SPI is only one of the names used by such four-wire protocols, and
52 most controllers have no problem handling "MicroWire" (think of it as
53 half-duplex SPI, for request/response protocols), SSP ("Synchronous
58 limiting themselves to half-duplex at the hardware level. In fact
70 Who uses it? On what kinds of systems?
71 ---------------------------------------
82 Most systems using SPI will integrate a few devices on a mainboard.
83 Some provide SPI links on expansion connectors; in cases where no
86 controller; the reasons to use SPI focus on low cost and simple operation,
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
106 sample on the leading edge, CPHA=1 means the trailing edge.
125 and always clock data in/out on rising clock edges.
129 ------------------------------------------------
144 controllers may be built into System-On-Chip
151 driver to communicate with a target or Controller device on the
155 data to filesystems stored on SPI flash like DataFlash; and others might
160 A "struct spi_device" encapsulates the controller-side interface between
163 There is a minimal core of SPI programming interfaces, focussing on
170 /sys/devices/.../CTLR/spiB.C ... spi_device on bus "B",
195 class related state for the SPI target controller on bus "B". When
199 At this time, the only class-specific state is the bus number ("B" in "spiB"),
203 How does board-specific init code declare SPI devices?
204 ------------------------------------------------------
206 That information is normally provided by board-specific code, even for
213 For System-on-Chip (SOC) based boards, these will usually be platform
220 the arch/.../mach-*/board-*.c files for several boards can all share the
222 SPI-capable controllers, and only the ones actually usable on a given
225 So for example arch/.../mach-*/board-*.c files might have code like::
229 /* if your mach-* infrastructure doesn't support kernels that can
230 * run on multiple boards, pdata wouldn't benefit from "__init".
242 And SOC-specific utility code might look something like::
256 spi2->dev.platform_data = pdata2;
260 * visible on the relevant pins ... bootloaders on
269 same SOC controller is used. For example, on one board SPI might use
277 on the target board, often with some board-specific data needed for the
280 Normally your arch/.../mach-*/board-*.c files would provide a small table
281 listing the SPI devices on each board. (This would typically be only a
302 Again, notice how board-specific information is provided; each chip may need
305 is wired, plus chip-specific constraints like an important delay that's
309 controller driver. An example would be peripheral-specific DMA tuning
324 Like with other static board-specific setup, you won't unregister those.
327 onto a card that's maybe just thirty square centimeters. On such systems,
328 your ``arch/.../mach-.../board-*.c`` file would primarily provide information
329 about the devices on the mainboard into which such a card is plugged. That
333 Non-static Configurations
342 ----------------------------------------
370 /* assuming the driver requires board-specific data: */
371 pdata = &spi->dev.platform_data;
373 return -ENODEV;
375 /* get memory for driver's per-chip state */
378 return -ENOMEM;
390 - An spi_message is a sequence of protocol operations, executed
412 device ... using the spi_transfer.cs_change flag on the last
416 - Follow standard kernel rules, and provide DMA-safe buffers in
421 - The basic I/O primitive is spi_async(). Async requests may be
427 - There are also synchronous wrappers like spi_sync(), and wrappers
432 - The spi_write_then_read() call, and convenience wrappers around
435 common RPC-style requests, such as writing an eight bit command
436 and reading a sixteen bit response -- spi_w8r16() being one its
443 that no message is pending for that device.
453 - I/O buffers use the usual Linux rules, and must be DMA-safe.
457 - The spi_message and spi_transfer metadata used to glue those
460 other allocate-once driver data structures. Zero-init these.
463 routines are available to allocate and zero-initialize an spi_message
468 -------------------------------------------------
469 An SPI controller will probably be registered on the platform_bus; write
474 spi_controller_get_devdata() to get the driver-private data allocated for that
484 return -ENODEV;
506 SPI bus (shared SCK, MOSI, MISO). Valid bus numbers start at zero. On
511 If you don't have such hardware-assigned bus number, and for some reason
514 this as a non-static configuration (see above).
520 ``ctlr->setup(struct spi_device *spi)``
536 ``ctlr->cleanup(struct spi_device *spi)``
541 ``ctlr->prepare_transfer_hardware(struct spi_controller *ctlr)``
547 ``ctlr->unprepare_transfer_hardware(struct spi_controller *ctlr)``
549 that there are no more messages pending in the queue and it may
552 ``ctlr->transfer_one_message(struct spi_controller *ctlr, struct spi_message *mesg)``
559 ``ctrl->transfer_one(struct spi_controller *ctlr, struct spi_device *spi, struct spi_transfer *tran…
574 ``ctrl->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, u8 hold_clk_cycles, u8 inactive_…
582 ``ctrl->transfer(struct spi_device *spi, struct spi_message *message)``
586 if the controller is idle it will need to be kickstarted. This
587 method is not used on queued controllers and must be NULL if
598 providing pure process-context execution of methods. The message queue
599 can also be elevated to realtime priority on high-priority SPI traffic.
606 for low-frequency sensor access might be fine using synchronous PIO.
608 But the queue will probably be very real, using message->queue, PIO,
618 ------------------------------
654 MOSI idle state configuration
696 of their ``struct spi_controller``. The configuration to idle MOSI low is
701 ---------
702 Contributors to Linux-SPI discussions include (in alphabetical order,
705 - Mark Brown
706 - David Brownell
707 - Russell King
708 - Grant Likely
709 - Dmitry Pervushin
710 - Stephen Street
711 - Mark Underwood
712 - Andrew Victor
713 - Linus Walleij
714 - Vitaly Wool