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