^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ====================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Overview of Linux kernel SPI support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ====================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) 02-Feb-2012
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) What is SPI?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) ------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) The "Serial Peripheral Interface" (SPI) is a synchronous four wire serial
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) link used to connect microcontrollers to sensors, memory, and peripherals.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) It's a simple "de facto" standard, not complicated enough to acquire a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) standardization body. SPI uses a master/slave configuration.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) The three signal wires hold a clock (SCK, often on the order of 10 MHz),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) Slave Out" (MISO) signals. (Other names are also used.) There are four
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) clocking modes through which data is exchanged; mode-0 and mode-3 are most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) commonly used. Each clock cycle shifts data out and data in; the clock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) doesn't cycle except when there is a data bit to shift. Not all data bits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) are used though; not every protocol uses those full duplex capabilities.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) SPI masters use a fourth "chip select" line to activate a given SPI slave
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) device, so those three signal wires may be connected to several chips
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) in parallel. All SPI slaves support chipselects; they are usually active
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) low signals, labeled nCSx for slave 'x' (e.g. nCS0). Some devices have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) other signals, often including an interrupt to the master.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) Unlike serial busses like USB or SMBus, even low level protocols for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) SPI slave functions are usually not interoperable between vendors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) (except for commodities like SPI memory chips).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) - SPI may be used for request/response style device protocols, as with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) touchscreen sensors and memory chips.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) - It may also be used to stream data in either direction (half duplex),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) or both of them at the same time (full duplex).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) - Some devices may use eight bit words. Others may use different word
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) lengths, such as streams of 12-bit or 20-bit digital samples.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) - Words are usually sent with their most significant bit (MSB) first,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) but sometimes the least significant bit (LSB) goes first instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) - Sometimes SPI is used to daisy-chain devices, like shift registers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) In the same way, SPI slaves will only rarely support any kind of automatic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) discovery/enumeration protocol. The tree of slave devices accessible from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) a given SPI master will normally be set up manually, with configuration
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) tables.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) SPI is only one of the names used by such four-wire protocols, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) most controllers have no problem handling "MicroWire" (think of it as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) half-duplex SPI, for request/response protocols), SSP ("Synchronous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) Serial Protocol"), PSP ("Programmable Serial Protocol"), and other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) related protocols.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) Some chips eliminate a signal line by combining MOSI and MISO, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) limiting themselves to half-duplex at the hardware level. In fact
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) some SPI chips have this signal mode as a strapping option. These
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) can be accessed using the same programming interface as SPI, but of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) course they won't handle full duplex transfers. You may find such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) chips described as using "three wire" signaling: SCK, data, nCSx.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) (That data line is sometimes called MOMI or SISO.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) Microcontrollers often support both master and slave sides of the SPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) protocol. This document (and Linux) supports both the master and slave
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) sides of SPI interactions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) Who uses it? On what kinds of systems?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) ---------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) Linux developers using SPI are probably writing device drivers for embedded
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) systems boards. SPI is used to control external chips, and it is also a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) protocol supported by every MMC or SD memory card. (The older "DataFlash"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) cards, predating MMC cards but using the same connectors and card shape,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) support only SPI.) Some PC hardware uses SPI flash for BIOS code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) SPI slave chips range from digital/analog converters used for analog
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) sensors and codecs, to memory, to peripherals like USB controllers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) or Ethernet adapters; and more.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) Most systems using SPI will integrate a few devices on a mainboard.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) Some provide SPI links on expansion connectors; in cases where no
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) dedicated SPI controller exists, GPIO pins can be used to create a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) low speed "bitbanging" adapter. Very few systems will "hotplug" an SPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) controller; the reasons to use SPI focus on low cost and simple operation,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) and if dynamic reconfiguration is important, USB will often be a more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) appropriate low-pincount peripheral bus.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) Many microcontrollers that can run Linux integrate one or more I/O
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) interfaces with SPI modes. Given SPI support, they could use MMC or SD
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) cards without needing a special purpose MMC/SD/SDIO controller.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) I'm confused. What are these four SPI "clock modes"?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) -----------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) It's easy to be confused here, and the vendor documentation you'll
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) find isn't necessarily helpful. The four modes combine two mode bits:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) - CPOL indicates the initial clock polarity. CPOL=0 means the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) clock starts low, so the first (leading) edge is rising, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) the second (trailing) edge is falling. CPOL=1 means the clock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) starts high, so the first (leading) edge is falling.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) - CPHA indicates the clock phase used to sample data; CPHA=0 says
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) sample on the leading edge, CPHA=1 means the trailing edge.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) Since the signal needs to stablize before it's sampled, CPHA=0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) implies that its data is written half a clock before the first
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) clock edge. The chipselect may have made it become available.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) Chip specs won't always say "uses SPI mode X" in as many words,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) but their timing diagrams will make the CPOL and CPHA modes clear.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) In the SPI mode number, CPOL is the high order bit and CPHA is the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) low order bit. So when a chip's timing diagram shows the clock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) starting low (CPOL=0) and data stabilized for sampling during the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) trailing clock edge (CPHA=1), that's SPI mode 1.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) Note that the clock mode is relevant as soon as the chipselect goes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) active. So the master must set the clock to inactive before selecting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) a slave, and the slave can tell the chosen polarity by sampling the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) clock level when its select line goes active. That's why many devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) support for example both modes 0 and 3: they don't care about polarity,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) and always clock data in/out on rising clock edges.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) How do these driver programming interfaces work?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) ------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) The <linux/spi/spi.h> header file includes kerneldoc, as does the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) main source code, and you should certainly read that chapter of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) kernel API document. This is just an overview, so you get the big
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) picture before those details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) SPI requests always go into I/O queues. Requests for a given SPI device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) are always executed in FIFO order, and complete asynchronously through
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) completion callbacks. There are also some simple synchronous wrappers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) for those calls, including ones for common transaction types like writing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) a command and then reading its response.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) There are two types of SPI driver, here called:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) Controller drivers ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) controllers may be built into System-On-Chip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) processors, and often support both Master and Slave roles.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) These drivers touch hardware registers and may use DMA.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) Or they can be PIO bitbangers, needing just GPIO pins.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) Protocol drivers ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) these pass messages through the controller
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) driver to communicate with a Slave or Master device on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) other side of an SPI link.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) So for example one protocol driver might talk to the MTD layer to export
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) data to filesystems stored on SPI flash like DataFlash; and others might
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) control audio interfaces, present touchscreen sensors as input interfaces,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) or monitor temperature and voltage levels during industrial processing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) And those might all be sharing the same controller driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) A "struct spi_device" encapsulates the controller-side interface between
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) those two types of drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) There is a minimal core of SPI programming interfaces, focussing on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) using the driver model to connect controller and protocol drivers using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) device tables provided by board specific initialization code. SPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) shows up in sysfs in several locations::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) /sys/devices/.../CTLR ... physical node for a given SPI controller
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) /sys/devices/.../CTLR/spiB.C ... spi_device on bus "B",
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) chipselect C, accessed through CTLR.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) /sys/bus/spi/devices/spiB.C ... symlink to that physical
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) .../CTLR/spiB.C device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) /sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) that should be used with this device (for hotplug/coldplug)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) /sys/class/spi_master/spiB ... symlink (or actual device node) to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) a logical node which could hold class related state for the SPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) master controller managing bus "B". All spiB.* devices share one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) physical SPI bus segment, with SCLK, MOSI, and MISO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) /sys/devices/.../CTLR/slave ... virtual file for (un)registering the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) slave device for an SPI slave controller.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) Writing the driver name of an SPI slave handler to this file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) registers the slave device; writing "(null)" unregisters the slave
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) Reading from this file shows the name of the slave device ("(null)"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) if not registered).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) /sys/class/spi_slave/spiB ... symlink (or actual device node) to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) a logical node which could hold class related state for the SPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) slave controller on bus "B". When registered, a single spiB.*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) device is present here, possible sharing the physical SPI bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) segment with other SPI slave devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) Note that the actual location of the controller's class state depends
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) on whether you enabled CONFIG_SYSFS_DEPRECATED or not. At this time,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) the only class-specific state is the bus number ("B" in "spiB"), so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) those /sys/class entries are only useful to quickly identify busses.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) How does board-specific init code declare SPI devices?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) ------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) Linux needs several kinds of information to properly configure SPI devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) That information is normally provided by board-specific code, even for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) chips that do support some of automated discovery/enumeration.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) Declare Controllers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) ^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) The first kind of information is a list of what SPI controllers exist.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) For System-on-Chip (SOC) based boards, these will usually be platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) devices, and the controller may need some platform_data in order to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) operate properly. The "struct platform_device" will include resources
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) like the physical address of the controller's first register and its IRQ.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) Platforms will often abstract the "register SPI controller" operation,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) maybe coupling it with code to initialize pin configurations, so that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) the arch/.../mach-*/board-*.c files for several boards can all share the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) same basic controller setup code. This is because most SOCs have several
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) SPI-capable controllers, and only the ones actually usable on a given
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) board should normally be set up and registered.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) So for example arch/.../mach-*/board-*.c files might have code like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) #include <mach/spi.h> /* for mysoc_spi_data */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) /* if your mach-* infrastructure doesn't support kernels that can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) * run on multiple boards, pdata wouldn't benefit from "__init".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) static struct mysoc_spi_data pdata __initdata = { ... };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) static __init board_init(void)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) /* this board only uses SPI controller #2 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) mysoc_register_spi(2, &pdata);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) And SOC-specific utility code might look something like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) #include <mach/spi.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) static struct platform_device spi2 = { ... };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) void mysoc_register_spi(unsigned n, struct mysoc_spi_data *pdata)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) struct mysoc_spi_data *pdata2;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) pdata2 = kmalloc(sizeof *pdata2, GFP_KERNEL);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) *pdata2 = pdata;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) if (n == 2) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) spi2->dev.platform_data = pdata2;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) register_platform_device(&spi2);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) /* also: set up pin modes so the spi2 signals are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) * visible on the relevant pins ... bootloaders on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) * production boards may already have done this, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) * developer boards will often need Linux to do it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) Notice how the platform_data for boards may be different, even if the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) same SOC controller is used. For example, on one board SPI might use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) an external clock, where another derives the SPI clock from current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) settings of some master clock.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) Declare Slave Devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) ^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) The second kind of information is a list of what SPI slave devices exist
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) on the target board, often with some board-specific data needed for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) driver to work correctly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) Normally your arch/.../mach-*/board-*.c files would provide a small table
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) listing the SPI devices on each board. (This would typically be only a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) small handful.) That might look like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) static struct ads7846_platform_data ads_info = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) .vref_delay_usecs = 100,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) .x_plate_ohms = 580,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) .y_plate_ohms = 410,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) static struct spi_board_info spi_board_info[] __initdata = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) .modalias = "ads7846",
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) .platform_data = &ads_info,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) .mode = SPI_MODE_0,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) .irq = GPIO_IRQ(31),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) .max_speed_hz = 120000 /* max sample rate at 3V */ * 16,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) .bus_num = 1,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) .chip_select = 0,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) },
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) Again, notice how board-specific information is provided; each chip may need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) several types. This example shows generic constraints like the fastest SPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) clock to allow (a function of board voltage in this case) or how an IRQ pin
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) is wired, plus chip-specific constraints like an important delay that's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) changed by the capacitance at one pin.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) (There's also "controller_data", information that may be useful to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) controller driver. An example would be peripheral-specific DMA tuning
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) data or chipselect callbacks. This is stored in spi_device later.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) The board_info should provide enough information to let the system work
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) without the chip's driver being loaded. The most troublesome aspect of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) that is likely the SPI_CS_HIGH bit in the spi_device.mode field, since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) sharing a bus with a device that interprets chipselect "backwards" is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) not possible until the infrastructure knows how to deselect it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) Then your board initialization code would register that table with the SPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) infrastructure, so that it's available later when the SPI master controller
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) driver is registered::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) Like with other static board-specific setup, you won't unregister those.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) The widely used "card" style computers bundle memory, cpu, and little else
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) onto a card that's maybe just thirty square centimeters. On such systems,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) your ``arch/.../mach-.../board-*.c`` file would primarily provide information
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) about the devices on the mainboard into which such a card is plugged. That
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) certainly includes SPI devices hooked up through the card connectors!
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) Non-static Configurations
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) ^^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) Developer boards often play by different rules than product boards, and one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) example is the potential need to hotplug SPI devices and/or controllers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) For those cases you might need to use spi_busnum_to_master() to look
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) up the spi bus master, and will likely need spi_new_device() to provide the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) board info based on the board that was hotplugged. Of course, you'd later
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) call at least spi_unregister_device() when that board is removed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) configurations will also be dynamic. Fortunately, such devices all support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) basic device identification probes, so they should hotplug normally.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) How do I write an "SPI Protocol Driver"?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) ----------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) Most SPI drivers are currently kernel drivers, but there's also support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) for userspace drivers. Here we talk only about kernel drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) SPI protocol drivers somewhat resemble platform device drivers::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) static struct spi_driver CHIP_driver = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) .driver = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) .name = "CHIP",
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) .owner = THIS_MODULE,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) .pm = &CHIP_pm_ops,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) },
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) .probe = CHIP_probe,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) .remove = CHIP_remove,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) The driver core will automatically attempt to bind this driver to any SPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) device whose board_info gave a modalias of "CHIP". Your probe() code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) might look like this unless you're creating a device which is managing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) a bus (appearing under /sys/class/spi_master).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) static int CHIP_probe(struct spi_device *spi)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) struct CHIP *chip;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) struct CHIP_platform_data *pdata;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) /* assuming the driver requires board-specific data: */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383) pdata = &spi->dev.platform_data;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) if (!pdata)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) return -ENODEV;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) /* get memory for driver's per-chip state */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) chip = kzalloc(sizeof *chip, GFP_KERNEL);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) if (!chip)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) return -ENOMEM;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) spi_set_drvdata(spi, chip);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) ... etc
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) return 0;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) As soon as it enters probe(), the driver may issue I/O requests to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) the SPI device using "struct spi_message". When remove() returns,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) or after probe() fails, the driver guarantees that it won't submit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) any more such messages.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) - An spi_message is a sequence of protocol operations, executed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) as one atomic sequence. SPI driver controls include:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) + when bidirectional reads and writes start ... by how its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) sequence of spi_transfer requests is arranged;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) + which I/O buffers are used ... each spi_transfer wraps a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) buffer for each transfer direction, supporting full duplex
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) (two pointers, maybe the same one in both cases) and half
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) duplex (one pointer is NULL) transfers;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) + optionally defining short delays after transfers ... using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) the spi_transfer.delay_usecs setting (this delay can be the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) only protocol effect, if the buffer length is zero);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) + whether the chipselect becomes inactive after a transfer and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) any delay ... by using the spi_transfer.cs_change flag;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) + hinting whether the next message is likely to go to this same
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) device ... using the spi_transfer.cs_change flag on the last
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) transfer in that atomic group, and potentially saving costs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) for chip deselect and select operations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) - Follow standard kernel rules, and provide DMA-safe buffers in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) your messages. That way controller drivers using DMA aren't forced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) to make extra copies unless the hardware requires it (e.g. working
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) around hardware errata that force the use of bounce buffering).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) If standard dma_map_single() handling of these buffers is inappropriate,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) you can use spi_message.is_dma_mapped to tell the controller driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432) that you've already provided the relevant DMA addresses.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) - The basic I/O primitive is spi_async(). Async requests may be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) issued in any context (irq handler, task, etc) and completion
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) is reported using a callback provided with the message.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) After any detected error, the chip is deselected and processing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) of that spi_message is aborted.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) - There are also synchronous wrappers like spi_sync(), and wrappers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) like spi_read(), spi_write(), and spi_write_then_read(). These
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) may be issued only in contexts that may sleep, and they're all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443) clean (and small, and "optional") layers over spi_async().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) - The spi_write_then_read() call, and convenience wrappers around
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) it, should only be used with small amounts of data where the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) cost of an extra copy may be ignored. It's designed to support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) common RPC-style requests, such as writing an eight bit command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449) and reading a sixteen bit response -- spi_w8r16() being one its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) wrappers, doing exactly that.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) Some drivers may need to modify spi_device characteristics like the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) transfer mode, wordsize, or clock rate. This is done with spi_setup(),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) which would normally be called from probe() before the first I/O is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) done to the device. However, that can also be called at any time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456) that no message is pending for that device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) While "spi_device" would be the bottom boundary of the driver, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) upper boundaries might include sysfs (especially for sensor readings),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) the input layer, ALSA, networking, MTD, the character device framework,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) or other Linux subsystems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) Note that there are two types of memory your driver must manage as part
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) of interacting with SPI devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) - I/O buffers use the usual Linux rules, and must be DMA-safe.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) You'd normally allocate them from the heap or free page pool.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468) Don't use the stack, or anything that's declared "static".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) - The spi_message and spi_transfer metadata used to glue those
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) I/O buffers into a group of protocol transactions. These can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) be allocated anywhere it's convenient, including as part of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) other allocate-once driver data structures. Zero-init these.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) If you like, spi_message_alloc() and spi_message_free() convenience
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) routines are available to allocate and zero-initialize an spi_message
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477) with several transfers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) How do I write an "SPI Master Controller Driver"?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) -------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) An SPI controller will probably be registered on the platform_bus; write
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483) a driver to bind to the device, whichever bus is involved.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485) The main task of this type of driver is to provide an "spi_master".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486) Use spi_alloc_master() to allocate the master, and spi_master_get_devdata()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487) to get the driver-private data allocated for that device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) struct spi_master *master;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) struct CONTROLLER *c;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) master = spi_alloc_master(dev, sizeof *c);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) if (!master)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) return -ENODEV;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) c = spi_master_get_devdata(master);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) The driver will initialize the fields of that spi_master, including the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501) bus number (maybe the same as the platform device ID) and three methods
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) used to interact with the SPI core and SPI protocol drivers. It will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503) also initialize its own internal state. (See below about bus numbering
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504) and those methods.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506) After you initialize the spi_master, then use spi_register_master() to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507) publish it to the rest of the system. At that time, device nodes for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508) controller and any predeclared spi devices will be made available, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509) the driver model core will take care of binding them to drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511) If you need to remove your SPI controller driver, spi_unregister_master()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512) will reverse the effect of spi_register_master().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515) Bus Numbering
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516) ^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518) Bus numbering is important, since that's how Linux identifies a given
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519) SPI bus (shared SCK, MOSI, MISO). Valid bus numbers start at zero. On
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520) SOC systems, the bus numbers should match the numbers defined by the chip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) manufacturer. For example, hardware controller SPI2 would be bus number 2,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522) and spi_board_info for devices connected to it would use that number.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524) If you don't have such hardware-assigned bus number, and for some reason
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525) you can't just assign them, then provide a negative bus number. That will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) then be replaced by a dynamically assigned number. You'd then need to treat
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527) this as a non-static configuration (see above).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530) SPI Master Methods
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531) ^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533) ``master->setup(struct spi_device *spi)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534) This sets up the device clock rate, SPI mode, and word sizes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535) Drivers may change the defaults provided by board_info, and then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536) call spi_setup(spi) to invoke this routine. It may sleep.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538) Unless each SPI slave has its own configuration registers, don't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539) change them right away ... otherwise drivers could corrupt I/O
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540) that's in progress for other SPI devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) .. note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544) BUG ALERT: for some reason the first version of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) many spi_master drivers seems to get this wrong.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546) When you code setup(), ASSUME that the controller
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547) is actively processing transfers for another device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) ``master->cleanup(struct spi_device *spi)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550) Your controller driver may use spi_device.controller_state to hold
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551) state it dynamically associates with that device. If you do that,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) be sure to provide the cleanup() method to free that state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554) ``master->prepare_transfer_hardware(struct spi_master *master)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555) This will be called by the queue mechanism to signal to the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556) that a message is coming in soon, so the subsystem requests the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) driver to prepare the transfer hardware by issuing this call.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558) This may sleep.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560) ``master->unprepare_transfer_hardware(struct spi_master *master)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561) This will be called by the queue mechanism to signal to the driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562) that there are no more messages pending in the queue and it may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563) relax the hardware (e.g. by power management calls). This may sleep.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565) ``master->transfer_one_message(struct spi_master *master, struct spi_message *mesg)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566) The subsystem calls the driver to transfer a single message while
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567) queuing transfers that arrive in the meantime. When the driver is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568) finished with this message, it must call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569) spi_finalize_current_message() so the subsystem can issue the next
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570) message. This may sleep.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572) ``master->transfer_one(struct spi_master *master, struct spi_device *spi, struct spi_transfer *transfer)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573) The subsystem calls the driver to transfer a single transfer while
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574) queuing transfers that arrive in the meantime. When the driver is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575) finished with this transfer, it must call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576) spi_finalize_current_transfer() so the subsystem can issue the next
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577) transfer. This may sleep. Note: transfer_one and transfer_one_message
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578) are mutually exclusive; when both are set, the generic subsystem does
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) not call your transfer_one callback.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581) Return values:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583) * negative errno: error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584) * 0: transfer is finished
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585) * 1: transfer is still in progress
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587) ``master->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, u8 hold_clk_cycles, u8 inactive_clk_cycles)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) This method allows SPI client drivers to request SPI master controller
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589) for configuring device specific CS setup, hold and inactive timing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590) requirements.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) Deprecated Methods
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593) ^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 595) ``master->transfer(struct spi_device *spi, struct spi_message *message)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 596) This must not sleep. Its responsibility is to arrange that the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 597) transfer happens and its complete() callback is issued. The two
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 598) will normally happen later, after other transfers complete, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 599) if the controller is idle it will need to be kickstarted. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 600) method is not used on queued controllers and must be NULL if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 601) transfer_one_message() and (un)prepare_transfer_hardware() are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 602) implemented.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 603)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 604)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 605) SPI Message Queue
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 606) ^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 607)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 608) If you are happy with the standard queueing mechanism provided by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 609) SPI subsystem, just implement the queued methods specified above. Using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 610) the message queue has the upside of centralizing a lot of code and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 611) providing pure process-context execution of methods. The message queue
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 612) can also be elevated to realtime priority on high-priority SPI traffic.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 613)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 614) Unless the queueing mechanism in the SPI subsystem is selected, the bulk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 615) of the driver will be managing the I/O queue fed by the now deprecated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 616) function transfer().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 617)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 618) That queue could be purely conceptual. For example, a driver used only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 619) for low-frequency sensor access might be fine using synchronous PIO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 620)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 621) But the queue will probably be very real, using message->queue, PIO,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 622) often DMA (especially if the root filesystem is in SPI flash), and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 623) execution contexts like IRQ handlers, tasklets, or workqueues (such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 624) as keventd). Your driver can be as fancy, or as simple, as you need.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 625) Such a transfer() method would normally just add the message to a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 626) queue, and then start some asynchronous transfer engine (unless it's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 627) already running).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 628)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 629)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 630) THANKS TO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 631) ---------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 632) Contributors to Linux-SPI discussions include (in alphabetical order,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 633) by last name):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 634)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 635) - Mark Brown
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 636) - David Brownell
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 637) - Russell King
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 638) - Grant Likely
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 639) - Dmitry Pervushin
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 640) - Stephen Street
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 641) - Mark Underwood
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 642) - Andrew Victor
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 643) - Linus Walleij
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 644) - Vitaly Wool
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags