Lines Matching +full:capacitance +full:- +full:to +full:- +full:digital
5 02-Feb-2012
8 ------------
10 link used to connect microcontrollers to sensors, memory, and peripherals.
11 It's a simple "de facto" standard, not complicated enough to acquire a
17 clocking modes through which data is exchanged; mode-0 and mode-3 are most
19 doesn't cycle except when there is a data bit to shift. Not all data bits
22 SPI hosts use a fourth "chip select" line to activate a given SPI target
23 device, so those three signal wires may be connected to several chips
26 other signals, often including an interrupt to the host.
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
53 half-duplex SPI, for request/response protocols), SSP ("Synchronous
58 limiting themselves to half-duplex at the hardware level. In fact
71 ---------------------------------------
73 systems boards. SPI is used to control external chips, and it is also a
78 SPI target chips range from digital/analog converters used for analog
79 sensors and codecs, to memory, to peripherals like USB controllers
84 dedicated SPI controller exists, GPIO pins can be used to create a
86 controller; the reasons to use SPI focus on low cost and simple operation,
88 appropriate low-pincount peripheral bus.
96 -----------------------------------------------------
97 It's easy to be confused here, and the vendor documentation you'll
100 - CPOL indicates the initial clock polarity. CPOL=0 means the
105 - CPHA indicates the clock phase used to sample data; CPHA=0 says
108 Since the signal needs to stabilize before it's sampled, CPHA=0
121 active. So the host must set the clock to inactive before selecting
129 ------------------------------------------------
144 controllers may be built into System-On-Chip
151 driver to communicate with a target or Controller device on the
154 So for example one protocol driver might talk to the MTD layer to export
155 data to filesystems stored on SPI flash like DataFlash; and others might
160 A "struct spi_device" encapsulates the controller-side interface between
164 using the driver model to connect controller and protocol drivers using
173 /sys/bus/spi/devices/spiB.C ... symlink to that physical
181 /sys/class/spi_master/spiB ... symlink to a logical node which could hold
188 Writing the driver name of an SPI target handler to this file
194 /sys/class/spi_slave/spiB ... symlink to a logical node which could hold
199 At this time, the only class-specific state is the bus number ("B" in "spiB"),
200 so those /sys/class entries are only useful to quickly identify busses.
203 How does board-specific init code declare SPI devices?
204 ------------------------------------------------------
205 Linux needs several kinds of information to properly configure SPI devices.
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
214 devices, and the controller may need some platform_data in order to
219 maybe coupling it with code to initialize pin configurations, so that
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
242 And SOC-specific utility code might look something like::
256 spi2->dev.platform_data = pdata2;
262 * developer boards will often need Linux to do it.
277 on the target board, often with some board-specific data needed for the
278 driver to work correctly.
280 Normally your arch/.../mach-*/board-*.c files would provide a small table
302 Again, notice how board-specific information is provided; each chip may need
304 clock to allow (a function of board voltage in this case) or how an IRQ pin
305 is wired, plus chip-specific constraints like an important delay that's
306 changed by the capacitance at one pin.
308 (There's also "controller_data", information that may be useful to the
309 controller driver. An example would be peripheral-specific DMA tuning
312 The board_info should provide enough information to let the system work
316 not possible until the infrastructure knows how to deselect it.
324 Like with other static board-specific setup, you won't unregister those.
328 your ``arch/.../mach-.../board-*.c`` file would primarily provide information
333 Non-static Configurations
342 ----------------------------------------
358 The driver core will automatically attempt to bind this driver to any SPI
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;
385 As soon as it enters probe(), the driver may issue I/O requests to
390 - An spi_message is a sequence of protocol operations, executed
405 is microseconds, however this can be adjusted to clock cycles
411 + hinting whether the next message is likely to go to this same
416 - Follow standard kernel rules, and provide DMA-safe buffers in
418 to make extra copies unless the hardware requires it (e.g. working
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
434 cost of an extra copy may be ignored. It's designed to support
435 common RPC-style requests, such as writing an eight bit command
436 and reading a sixteen bit response -- spi_w8r16() being one its
439 Some drivers may need to modify spi_device characteristics like the
442 done to the device. However, that can also be called at any time
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 -------------------------------------------------
470 a driver to bind to the device, whichever bus is involved.
472 The main task of this type of driver is to provide an "spi_controller".
473 Use spi_alloc_host() to allocate the host controller, and
474 spi_controller_get_devdata() to get the driver-private data allocated for that
484 return -ENODEV;
489 number (maybe the same as the platform device ID) and three methods used to
493 After you initialize the spi_controller, then use spi_register_controller() to
494 publish it to the rest of the system. At that time, device nodes for the
496 the driver model core will take care of binding them to drivers.
498 If you need to remove your SPI controller driver, spi_unregister_controller()
509 and spi_board_info for devices connected to it would use that number.
511 If you don't have such hardware-assigned bus number, and for some reason
513 then be replaced by a dynamically assigned number. You'd then need to treat
514 this as a non-static configuration (see above).
520 ``ctlr->setup(struct spi_device *spi)``
523 call spi_setup(spi) to invoke this routine. It may sleep.
532 many spi_controller drivers seems to get this wrong.
536 ``ctlr->cleanup(struct spi_device *spi)``
537 Your controller driver may use spi_device.controller_state to hold
539 be sure to provide the cleanup() method to free that state.
541 ``ctlr->prepare_transfer_hardware(struct spi_controller *ctlr)``
542 This will be called by the queue mechanism to signal to the driver
544 driver to prepare the transfer hardware by issuing this call.
547 ``ctlr->unprepare_transfer_hardware(struct spi_controller *ctlr)``
548 This will be called by the queue mechanism to signal to the driver
552 ``ctlr->transfer_one_message(struct spi_controller *ctlr, struct spi_message *mesg)``
553 The subsystem calls the driver to transfer a single message while
559 ``ctrl->transfer_one(struct spi_controller *ctlr, struct spi_device *spi, struct spi_transfer *tran…
560 The subsystem calls the driver to transfer a single transfer while
574 ``ctrl->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, u8 hold_clk_cycles, u8 inactive_…
575 This method allows SPI client drivers to request SPI host controller
582 ``ctrl->transfer(struct spi_device *spi, struct spi_message *message)``
583 This must not sleep. Its responsibility is to arrange that the
586 if the controller is idle it will need to be kickstarted. This
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,
612 Such a transfer() method would normally just add the message to a
617 Extensions to the SPI protocol
618 ------------------------------
620 manufacturers to implement the SPI protocol in slightly different ways. In most
660 out. For example, if the peripheral expects the MOSI line to be high when the
688 In this extension to the usual SPI protocol, the MOSI line state is specified to
689 be kept high when CS is asserted but the controller is not clocking out data to
696 of their ``struct spi_controller``. The configuration to idle MOSI low is
700 THANKS TO
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