Lines Matching +full:half +full:- +full:bus
5 02-Feb-2012
8 ------------
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
53 half-duplex SPI, for request/response protocols), SSP ("Synchronous
58 limiting themselves to half-duplex at the hardware level. In fact
71 ---------------------------------------
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
109 implies that its data is written half a clock before the first
129 ------------------------------------------------
144 controllers may be built into System-On-Chip
160 A "struct spi_device" encapsulates the controller-side interface between
170 /sys/devices/.../CTLR/spiB.C ... spi_device on bus "B",
173 /sys/bus/spi/devices/spiB.C ... symlink to that physical
179 /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices
183 master controller managing bus "B". All spiB.* devices share one
184 physical SPI bus segment, with SCLK, MOSI, and MISO.
196 slave controller on bus "B". When registered, a single spiB.*
197 device is present here, possible sharing the physical SPI bus
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;
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
318 sharing a bus with a device that interprets chipselect "backwards" is
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 ----------------------------------------
373 a bus (appearing under /sys/class/spi_master).
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
410 (two pointers, maybe the same one in both cases) and half
428 - Follow standard kernel rules, and provide DMA-safe buffers in
437 - The basic I/O primitive is spi_async(). Async requests may be
443 - There are also synchronous wrappers like spi_sync(), and wrappers
448 - The spi_write_then_read() call, and convenience wrappers around
451 common RPC-style requests, such as writing an eight bit command
452 and reading a sixteen bit response -- spi_w8r16() being one its
469 - I/O buffers use the usual Linux rules, and must be DMA-safe.
473 - The spi_message and spi_transfer metadata used to glue those
476 other allocate-once driver data structures. Zero-init these.
479 routines are available to allocate and zero-initialize an spi_message
484 -------------------------------------------------
486 a driver to bind to the device, whichever bus is involved.
490 to get the driver-private data allocated for that device.
499 return -ENODEV;
504 bus number (maybe the same as the platform device ID) and three methods
506 also initialize its own internal state. (See below about bus numbering
518 Bus Numbering
521 Bus numbering is important, since that's how Linux identifies a given
522 SPI bus (shared SCK, MOSI, MISO). Valid bus numbers start at zero. On
523 SOC systems, the bus numbers should match the numbers defined by the chip
524 manufacturer. For example, hardware controller SPI2 would be bus number 2,
527 If you don't have such hardware-assigned bus number, and for some reason
528 you can't just assign them, then provide a negative bus number. That will
530 this as a non-static configuration (see above).
536 ``master->setup(struct spi_device *spi)``
552 ``master->cleanup(struct spi_device *spi)``
557 ``master->prepare_transfer_hardware(struct spi_master *master)``
563 ``master->unprepare_transfer_hardware(struct spi_master *master)``
568 ``master->transfer_one_message(struct spi_master *master, struct spi_message *mesg)``
575 ``master->transfer_one(struct spi_master *master, struct spi_device *spi, struct spi_transfer *tran…
590 ``master->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, u8 hold_clk_cycles, u8 inactiv…
598 ``master->transfer(struct spi_device *spi, struct spi_message *message)``
614 providing pure process-context execution of methods. The message queue
615 can also be elevated to realtime priority on high-priority SPI traffic.
622 for low-frequency sensor access might be fine using synchronous PIO.
624 But the queue will probably be very real, using message->queue, PIO,
634 ---------
635 Contributors to Linux-SPI discussions include (in alphabetical order,
638 - Mark Brown
639 - David Brownell
640 - Russell King
641 - Grant Likely
642 - Dmitry Pervushin
643 - Stephen Street
644 - Mark Underwood
645 - Andrew Victor
646 - Linus Walleij
647 - Vitaly Wool