aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/spi/spi.h
AgeCommit message (Collapse)Author
2024-02-23spi: introduce SPI_MODE_X_MASK macroOleksij Rempel
[ Upstream commit 029b42d8519cef70c4fb5fcaccd08f1053ed2bf0 ] Provide a macro to filter all SPI_MODE_0,1,2,3 mode in one run. The latest SPI framework will parse the devicetree in following call sequence: of_register_spi_device() -> of_spi_parse_dt() So, driver do not need to pars the devicetree and will get prepared flags in the probe. On one hand it is good far most drivers. On other hand some drivers need to filter flags provide by SPI framework and apply know to work flags. This drivers may use SPI_MODE_X_MASK to filter MODE flags and set own, known flags: spi->flags &= ~SPI_MODE_X_MASK; spi->flags |= SPI_MODE_0; Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20201027095724.18654-2-o.rempel@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 6d710b769c1f ("serial: sc16is7xx: add check for unsupported SPI modes during probe") Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14spi: Fix use-after-free with devm_spi_alloc_*William A. Kennington III
[ Upstream commit 794aaf01444d4e765e2b067cba01cc69c1c68ed9 ] We can't rely on the contents of the devres list during spi_unregister_controller(), as the list is already torn down at the time we perform devres_find() for devm_spi_release_controller. This causes devices registered with devm_spi_alloc_{master,slave}() to be mistakenly identified as legacy, non-devm managed devices and have their reference counters decremented below 0. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174 [<b0396f04>] (refcount_warn_saturate) from [<b03c56a4>] (kobject_put+0x90/0x98) [<b03c5614>] (kobject_put) from [<b0447b4c>] (put_device+0x20/0x24) r4:b6700140 [<b0447b2c>] (put_device) from [<b07515e8>] (devm_spi_release_controller+0x3c/0x40) [<b07515ac>] (devm_spi_release_controller) from [<b045343c>] (release_nodes+0x84/0xc4) r5:b6700180 r4:b6700100 [<b04533b8>] (release_nodes) from [<b0454160>] (devres_release_all+0x5c/0x60) r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10 [<b0454104>] (devres_release_all) from [<b044e41c>] (__device_release_driver+0x144/0x1ec) r5:b117ad94 r4:b163dc10 [<b044e2d8>] (__device_release_driver) from [<b044f70c>] (device_driver_detach+0x84/0xa0) r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10 [<b044f688>] (device_driver_detach) from [<b044d274>] (unbind_store+0xe4/0xf8) Instead, determine the devm allocation state as a flag on the controller which is guaranteed to be stable during cleanup. Fixes: 5e844cc37a5c ("spi: Introduce device-managed SPI controller allocation") Signed-off-by: William A. Kennington III <wak@google.com> Link: https://lore.kernel.org/r/20210407095527.2771582-1-wak@google.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-24spi: Introduce device-managed SPI controller allocationLukas Wunner
commit 5e844cc37a5cbaa460e68f9a989d321d63088a89 upstream. SPI driver probing currently comprises two steps, whereas removal comprises only one step: spi_alloc_master() spi_register_controller() spi_unregister_controller() That's because spi_unregister_controller() calls device_unregister() instead of device_del(), thereby releasing the reference on the spi_controller which was obtained by spi_alloc_master(). An SPI driver's private data is contained in the same memory allocation as the spi_controller struct. Thus, once spi_unregister_controller() has been called, the private data is inaccessible. But some drivers need to access it after spi_unregister_controller() to perform further teardown steps. Introduce devm_spi_alloc_master() and devm_spi_alloc_slave(), which release a reference on the spi_controller struct only after the driver has unbound, thereby keeping the memory allocation accessible. Change spi_unregister_controller() to not release a reference if the spi_controller was allocated by one of these new devm functions. The present commit is small enough to be backportable to stable. It allows fixing drivers which use the private data in their ->remove() hook after it's been freed. It also allows fixing drivers which neglect to release a reference on the spi_controller in the probe error path. Long-term, most SPI drivers shall be moved over to the devm functions introduced herein. The few that can't shall be changed in a treewide commit to explicitly release the last reference on the controller. That commit shall amend spi_unregister_controller() to no longer release a reference, thereby completing the migration. As a result, the behaviour will be less surprising and more consistent with subsystems such as IIO, which also includes the private data in the allocation of the generic iio_dev struct, but calls device_del() in iio_device_unregister(). Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/272bae2ef08abd21388c98e23729886663d19192.1605121038.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-04Merge remote-tracking branch 'spi/topic/pump-rt' into spi-nextMark Brown
2019-06-17spi: Add a prototype for exported spi_set_cs_timing()Andy Shevchenko
Compiler is not happy about spi_set_cs_timing() prototype. drivers/spi/spi.c:3016:6: warning: no previous prototype for ‘spi_set_cs_timing’ [-Wmissing-prototypes] void spi_set_cs_timing(struct spi_device *spi, u8 setup, u8 hold, ^~~~~~~~~~~~~~~~~ Let's add it to the header. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-23spi: Allow SPI devices to request the pumping thread be realtimeDouglas Anderson
Right now the only way to get the SPI pumping thread bumped up to realtime priority is for the controller to request it. However it may be that the controller works fine with the normal priority but communication to a particular SPI device on the bus needs realtime priority. Let's add a way for devices to request realtime priority when they set themselves up. NOTE: this will just affect the priority of transfers that end up on the SPI core's pumping thread. In many cases transfers happen in the context of the caller so if you need realtime priority for all transfers you should ensure the calling context is also realtime priority. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-13spi: core: allow reporting the effectivly used speed_hz for a transferMartin Sperl
Provide a means for the spi bus driver to report the effectively used spi clock frequency used for each spi_transfer. Signed-off-by: Martin Sperl <kernel@martin.sperl.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-12Merge tag 'spi-bpw-is-supported' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.3 spi: Add spi_is_bpw_supported() Lets client drivers check and potentially handle issues.
2019-05-08spi: core: allow defining time that cs is deasserted as a multiple of SCKMartin Sperl
Support setting a delay between cs assert and deassert as a multiple of spi clock length. Signed-off-by: Martin Sperl <kernel@martin.sperl.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-08spi: core: allow defining time that cs is deassertedMartin Sperl
For some SPI devices that support speed_hz > 1MHz the default 10 us delay when cs_change = 1 is typically way to long and may result in poor spi bus utilization. This patch makes it possible to control the delay at micro or nano second resolution on a per spi_transfer basis. It even allows an "as fast as possible" mode with: xfer.cs_change_delay_unit = SPI_DELAY_UNIT_NSECS; xfer.cs_change_delay = 0; The delay code is shared between delay_usecs and cs_change_delay for consistency and reuse, so in the future this change_delay_unit could also apply to delay_usec as well. Note that on slower SOCs/CPU actually reaching ns deasserts on cs is not realistic as the gpio overhead alone (without any delays added ) may already leave cs deasserted for more than 1us - at least on a raspberry pi. But at the very least this way we can keep it as short as possible. Signed-off-by: Martin Sperl <kernel@martin.sperl.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-02spi: expand mode supportSowjanya Komatineni
This patch changes mode and mode_bits from u16 to u32 to allow more mode configurations. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-04-12spi: Add spi_is_bpw_supported()Noralf Trønnes
This let SPI clients check if the controller supports a particular word width. drivers/gpu/drm/tinydrm/mipi-dbi.c will use this to determine if the controller supports 16-bit for RGB565 pixels. If it doesn't it will swap the bytes before transfer on little endian machines. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-04-08spi: add a method for configuring CS timingSowjanya Komatineni
This patch creates set_cs_timing SPI master optional method for SPI masters to implement configuring CS timing if applicable. This patch also creates spi_cs_timing accessory for SPI clients to use for requesting SPI master controllers to configure device requested CS setup time, hold time and inactive delay. Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-03-14spi: fix SPI_BPW_RANGE_MASK() regressionArnd Bergmann
Geert points out that I confused the min/max arguments that are reversed between SPI_BPW_RANGE_MASK() and GENMASK(). This time I have verified the result of the macro after fixing the arguments. Cc: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: eefffb42f665 ("spi: work around clang bug in SPI_BPW_RANGE_MASK()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-03-11spi: work around clang bug in SPI_BPW_RANGE_MASK()Arnd Bergmann
Clang-8 evaluates both sides of a ?: expression to check for valid arithmetic even in the side that is never taken. This results in a build warning: drivers/spi/spi-sh-msiof.c:1052:24: error: shift count >= width of type [-Werror,-Wshift-count-overflow] .bits_per_word_mask = SPI_BPW_RANGE_MASK(8, 32), ^~~~~~~~~~~~~~~~~~~~~~~~~ Change the implementation to use the GENMASK() macro that does what we want here but does not have a problem with the shift count overflow. Link: https://bugs.llvm.org/show_bug.cgi?id=38789 Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-30spi: support inter-word delay requirement for devicesJonas Bonn
Some devices are slow and cannot keep up with the SPI bus and therefore require a short delay between words of the SPI transfer. The example of this that I'm looking at is a SAMA5D2 with a minimum SPI clock of 400kHz talking to an AVR-based SPI slave. The AVR cannot put bytes on the bus fast enough to keep up with the SoC's SPI controller even at the lowest bus speed. This patch introduces the ability to specify a required inter-word delay for SPI devices. It is up to the controller driver to configure itself accordingly in order to introduce the requested delay. Note that, for spi_transfer, there is already a field word_delay that provides similar functionality. This field, however, is specified in clock cycles (and worse, SPI controller cycles, not SCK cycles); that makes this value dependent on the master clock instead of the device clock for which the delay is intended to provide some relief. This patch leaves this old word_delay in place and provides a time-based word_delay_us alongside it; the new field fits in the struct padding so struct size is constant. There is only one in-kernel user of the word_delay field and presumably that driver could be reworked to use the time-based value instead. The time-based delay is limited to 8 bits as these delays are intended to be short. The SAMA5D2 that I've tested this on limits delays to a maximum of ~100us, which is already many word-transfer periods even at the minimum transfer speed supported by the controller. Signed-off-by: Jonas Bonn <jonas@norrbonn.se> CC: Mark Brown <broonie@kernel.org> CC: Rob Herring <robh+dt@kernel.org> CC: Mark Rutland <mark.rutland@arm.com> CC: linux-spi@vger.kernel.org CC: devicetree@vger.kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-23spi: Go back to immediate teardownMark Brown
Commit 412e6037324 ("spi: core: avoid waking pump thread from spi_sync instead run teardown delayed") introduced regressions on some boards, apparently connected to spi_mem not triggering shutdown properly any more. Since we've thus far been unable to figure out exactly where the breakage is revert the optimisation for now. Reported-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: kernel@martin.sperl.org
2019-01-09spi: core: avoid waking pump thread from spi_sync instead run teardown delayedMartin Sperl
When spi_sync is running alone with no other spi devices connected to the bus the worker thread is woken during spi_finalize_current_message to run the teardown code every time. This is totally unnecessary in the case that there is no message queued. On a multi-core system this results in one wakeup of the thread for each spi_message processed via spi_sync where in most cases the teardown does not happen as the hw is already in use. This patch now delays the teardown by 1 second by using a separate kthread_delayed_work for the teardown. This avoids waking the kthread too often. For spi_sync transfers in a tight loop (say 40k messages/s) this avoids the penalty of waking the worker thread 40k times/s. On a rasperry pi 3 with 4 cores the results in 32% of a single core only to find out that there is nothing in the queue and it can go back to sleep. With this patch applied the spi-worker is woken exactly once: after the load finishes and the spi bus is idle for 1 second. I believe I have also seen situations where during a spi_sync loop the worker thread (triggered by the last message finished) is slightly faster and _wins_ the race to process the message, so we are actually running the kthread and letting it do some work... This is also no longer observed with this patch applied as. Tested with a new CAN controller driver for the mcp2517fd which uses spi_sync for interrupt handling and spi_async for scheduling of can frames for transmission (in a different thread) Some statistics when receiving 100000 CAN frames with the mcp25xxfd driver on a Raspberry pi 3: without the patch: ------------------ root@raspcm3:~# for x in $(pgrep spi0) $(pgrep irq/94-mcp25xxf) ; do awk '{printf "%-20s %6i\n", $2,$15}' /proc/$x/stat; done (spi0) 5 (irq/94-mcp25xxf) 0 root@raspcm3:~# vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 821960 13592 50848 0 0 80 2 1986 105 1 2 97 0 0 0 0 0 821968 13592 50876 0 0 0 0 8046 30 0 0 100 0 0 0 0 0 821936 13592 50876 0 0 0 0 8032 24 0 0 100 0 0 0 0 0 821936 13592 50876 0 0 0 0 8035 30 0 0 100 0 0 0 0 0 821936 13592 50876 0 0 0 0 8033 22 0 0 100 0 0 2 0 0 821936 13592 50876 0 0 0 0 11598 7129 0 3 97 0 0 1 0 0 821872 13592 50876 0 0 0 0 37741 59003 0 31 69 0 0 2 0 0 821840 13592 50876 0 0 0 0 37762 59078 0 29 71 0 0 2 0 0 821776 13592 50876 0 0 0 0 37593 58792 0 28 72 0 0 1 0 0 821744 13592 50876 0 0 0 0 37642 58881 0 30 70 0 0 2 0 0 821680 13592 50876 0 0 0 0 37490 58602 0 27 73 0 0 1 0 0 821648 13592 50876 0 0 0 0 37412 58418 0 29 71 0 0 1 0 0 821584 13592 50876 0 0 0 0 37337 58288 0 27 73 0 0 1 0 0 821552 13592 50876 0 0 0 0 37584 58774 0 27 73 0 0 0 0 0 821520 13592 50876 0 0 0 0 18363 20566 0 9 91 0 0 0 0 0 821520 13592 50876 0 0 0 0 8037 32 0 0 100 0 0 0 0 0 821520 13592 50876 0 0 0 0 8031 23 0 0 100 0 0 0 0 0 821520 13592 50876 0 0 0 0 8034 26 0 0 100 0 0 0 0 0 821520 13592 50876 0 0 0 0 8033 24 0 0 100 0 0 ^C root@raspcm3:~# for x in $(pgrep spi0) $(pgrep irq/94-mcp25xxf) ; do awk '{printf "%-20s %6i\n", $2,$15}' /proc/$x/stat; done (spi0) 228 (irq/94-mcp25xxf) 794 root@raspcm3:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 17: 34 0 0 0 ARMCTRL-level 1 Edge 3f00b880.mailbox 27: 1 0 0 0 ARMCTRL-level 35 Edge timer 33: 1416870 0 0 0 ARMCTRL-level 41 Edge 3f980000.usb, dwc2_hsotg:usb1 34: 1 0 0 0 ARMCTRL-level 42 Edge vc4 35: 0 0 0 0 ARMCTRL-level 43 Edge 3f004000.txp 40: 1753 0 0 0 ARMCTRL-level 48 Edge DMA IRQ 42: 11 0 0 0 ARMCTRL-level 50 Edge DMA IRQ 44: 11 0 0 0 ARMCTRL-level 52 Edge DMA IRQ 45: 0 0 0 0 ARMCTRL-level 53 Edge DMA IRQ 66: 0 0 0 0 ARMCTRL-level 74 Edge vc4 crtc 69: 0 0 0 0 ARMCTRL-level 77 Edge vc4 crtc 70: 0 0 0 0 ARMCTRL-level 78 Edge vc4 crtc 77: 20 0 0 0 ARMCTRL-level 85 Edge 3f205000.i2c, 3f804000.i2c, 3f805000.i2c 78: 6346 0 0 0 ARMCTRL-level 86 Edge 3f204000.spi 80: 205 0 0 0 ARMCTRL-level 88 Edge mmc0 81: 493 0 0 0 ARMCTRL-level 89 Edge uart-pl011 89: 0 0 0 0 bcm2836-timer 0 Edge arch_timer 90: 4291 3821 2180 1649 bcm2836-timer 1 Edge arch_timer 94: 14289 0 0 0 pinctrl-bcm2835 16 Level mcp25xxfd IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 3645 242371 7919 1328 Rescheduling interrupts IPI3: 112 543 273 194 Function call interrupts IPI4: 0 0 0 0 CPU stop interrupts IPI5: 1 0 0 0 IRQ work interrupts IPI6: 0 0 0 0 completion interrupts Err: 0 top shows 93% for the mcp25xxfd interrupt handler, 31% for spi0. with the patch: --------------- root@raspcm3:~# for x in $(pgrep spi0) $(pgrep irq/94-mcp25xxf) ; do awk '{printf "%-20s %6i\n", $2,$15}' /proc/$x/stat; done (spi0) 0 (irq/94-mcp25xxf) 0 root@raspcm3:~# vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- 0 0 0 804768 13584 62628 0 0 0 0 8038 24 0 0 100 0 0 0 0 0 804768 13584 62628 0 0 0 0 8042 25 0 0 100 0 0 1 0 0 804704 13584 62628 0 0 0 0 9603 2967 0 20 80 0 0 1 0 0 804672 13584 62628 0 0 0 0 9828 3380 0 24 76 0 0 1 0 0 804608 13584 62628 0 0 0 0 9823 3375 0 23 77 0 0 1 0 0 804608 13584 62628 0 0 0 12 9829 3394 0 23 77 0 0 1 0 0 804544 13584 62628 0 0 0 0 9816 3362 0 22 78 0 0 1 0 0 804512 13584 62628 0 0 0 0 9817 3367 0 23 77 0 0 1 0 0 804448 13584 62628 0 0 0 0 9822 3370 0 22 78 0 0 1 0 0 804416 13584 62628 0 0 0 0 9815 3367 0 23 77 0 0 0 0 0 804352 13584 62628 0 0 0 84 9222 2250 0 14 86 0 0 0 0 0 804352 13592 62620 0 0 0 24 8131 209 0 0 93 7 0 0 0 0 804320 13592 62628 0 0 0 0 8041 27 0 0 100 0 0 0 0 0 804352 13592 62628 0 0 0 0 8040 26 0 0 100 0 0 root@raspcm3:~# for x in $(pgrep spi0) $(pgrep irq/94-mcp25xxf) ; do awk '{printf "%-20s %6i\n", $2,$15}' /proc/$x/stat; done (spi0) 0 (irq/94-mcp25xxf) 767 root@raspcm3:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 17: 29 0 0 0 ARMCTRL-level 1 Edge 3f00b880.mailbox 27: 1 0 0 0 ARMCTRL-level 35 Edge timer 33: 1024412 0 0 0 ARMCTRL-level 41 Edge 3f980000.usb, dwc2_hsotg:usb1 34: 1 0 0 0 ARMCTRL-level 42 Edge vc4 35: 0 0 0 0 ARMCTRL-level 43 Edge 3f004000.txp 40: 1773 0 0 0 ARMCTRL-level 48 Edge DMA IRQ 42: 11 0 0 0 ARMCTRL-level 50 Edge DMA IRQ 44: 11 0 0 0 ARMCTRL-level 52 Edge DMA IRQ 45: 0 0 0 0 ARMCTRL-level 53 Edge DMA IRQ 66: 0 0 0 0 ARMCTRL-level 74 Edge vc4 crtc 69: 0 0 0 0 ARMCTRL-level 77 Edge vc4 crtc 70: 0 0 0 0 ARMCTRL-level 78 Edge vc4 crtc 77: 20 0 0 0 ARMCTRL-level 85 Edge 3f205000.i2c, 3f804000.i2c, 3f805000.i2c 78: 6417 0 0 0 ARMCTRL-level 86 Edge 3f204000.spi 80: 237 0 0 0 ARMCTRL-level 88 Edge mmc0 81: 489 0 0 0 ARMCTRL-level 89 Edge uart-pl011 89: 0 0 0 0 bcm2836-timer 0 Edge arch_timer 90: 4048 3704 2383 1892 bcm2836-timer 1 Edge arch_timer 94: 14287 0 0 0 pinctrl-bcm2835 16 Level mcp25xxfd IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 2361 2948 7890 1616 Rescheduling interrupts IPI3: 65 617 301 166 Function call interrupts IPI4: 0 0 0 0 CPU stop interrupts IPI5: 1 0 0 0 IRQ work interrupts IPI6: 0 0 0 0 completion interrupts Err: 0 top shows 91% for the mcp25xxfd interrupt handler, 0% for spi0 So we see that spi0 is no longer getting scheduled wasting CPU cycles There are a lot less context switches and corresponding Rescheduling interrupts All of these show that this improves efficiency of the system and reduces CPU utilization. Signed-off-by: Martin Sperl <kernel@martin.sperl.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-09spi: Optionally use GPIO descriptors for CS GPIOsLinus Walleij
This augments the SPI core to optionally use GPIO descriptors for chip select on a per-master-driver opt-in basis. Drivers using this will rely on the SPI core to look up GPIO descriptors associated with the device, such as when using device tree or board files with GPIO descriptor tables. When getting descriptors from the device tree, this will in turn activate the code in gpiolib that was added in commit 6953c57ab172 ("gpio: of: Handle SPI chipselect legacy bindings") which means that these descriptors are aware of the active low semantics that is the default for SPI CS GPIO lines and we can assume that all of these are "active high" and thus assign SPI_CS_HIGH to all CS lines on the DT path. The previously used gpio_set_value() would call down into gpiod_set_raw_value() and ignore the polarity inversion semantics. It seems like many drivers go to great lengths to set up the CS GPIO line as non-asserted, respecting SPI_CS_HIGH. We pull this out of the SPI drivers and into the core, and by simply requesting the line as GPIOD_OUT_LOW when retrieveing it from the device and relying on the gpiolib to handle any inversion semantics. This way a lot of code can be simplified and removed in each converted driver. The end goal after dealing with each driver in turn, is to delete the non-descriptor path (of_spi_register_master() for example) and let the core deal with only descriptors. The different SPI drivers have complex interactions with the core so we cannot simply change them all over, we need to use a stepwise, bisectable approach so that each driver can be converted and fixed in isolation. This patch has the intended side effect of adding support for ACPI GPIOs as it starts relying on gpiod_get_*() to get the GPIO handle associated with the device. Cc: Linuxarm <linuxarm@huawei.com> Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com> Tested-by: Fangjian (Turing) <f.fangjian@huawei.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-12-04Merge branch 'topic/3wire-gpio' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-4.21 mode conflict
2018-12-03spi: add support for octal mode I/O data transferYogesh Narayan Gaur
Add flags for Octal mode I/O data transfer Required for the SPI controller which can do the data transfer (TX/RX) on 8 data lines e.g. NXP FlexSPI controller. SPI_TX_OCTAL: transmit with 8 wires SPI_RX_OCTAL: receive with 8 wires Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-07spi: gpio: Support 3WIRE high-impedance turn-aroundLinus Walleij
Some devices such as the TPO TPG110 display panel require a "high-impedance turn-around", in effect a clock cycle after switching the line from output to input mode. Support this in the GPIO driver to begin with. Other driver may implement it if they can, it is unclear if this can be achieved with anything else than GPIO bit-banging. Cc: Andrzej Hajda <a.hajda@samsung.com> Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-10-21Merge remote-tracking branch 'spi/topic/of' into spi-nextMark Brown
2018-10-10spi: Add driver_override SPI device attributeTrent Piepho
This attribute works the same was as the identically named attribute for PCI, AMBA, and platform devices. For reference, see: commit 3cf385713460 ("ARM: 8256/1: driver coamba: add device binding path 'driver_override'") commit 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'") commit 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override") If the name of a driver is written to this attribute, then the device will bind to the named driver and only the named driver. The device will bind to the driver even if the driver does not list the device in its id table. This behavior is different than the driver's bind attribute, which only allows binding to devices that are listed as supported by the driver. It can be used to bind a generic driver, like spidev, to a device. Signed-off-by: Trent Piepho <tpiepho@impinj.com> Reviewed-by: Jan Kundrát <jan.kundrat@cesnet.cz> Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-09-27spi: make OF helper available for othersMarco Felsch
The of_find_spi_device_by_node() helper function is useful for other modules too. Export the funciton as GPL like all other spi helper functions and make it available if CONFIG_OF is enabled, because it isn't related to the CONFIG_OF_DYNAMIC context. Finally add a stub if CONFIG_OF isn't enabled, so others must not care about it. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-09-27spi: switch to SPDX license identifierMarco Felsch
Use the appropriate SPDX license identifier and drop the previous license text. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-09-17Merge tag 'spi-cs-word' into spi-4.20Mark Brown
spi: Provide SPI_CS_WORD This provides a SPI operation mode which changes chip select after every word, used by some devices such as ADCs and DACs.
2018-09-17spi: add new SPI_CS_WORD flagDavid Lechner
This adds a new SPI mode flag, SPI_CS_WORD, that is used to indicate that a SPI device requires the chip select to be toggled after each word that is transferred. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-08-29spi: Introduce one new field to set word delayBaolin Wang
For some SPI controllers, after each word size (specified by bits_per_word) transimission, the hardware need some delay to make sure the slave has enough time to receive the whole data. So introducing one new 'word_delay' field of struct spi_tansfer for slave devices to set this inter word delay time. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-11spi: Get rid of the spi_flash_read() APIBoris Brezillon
This API has been replaced by the spi_mem_xx() one, its only user (spi-nor) has been converted to spi_mem_xx() and all SPI controller drivers that were implementing the ->spi_flash_xxx() hooks are also implementing the spi_mem ones. So we can safely get rid of this API. Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@exceet.de> Tested-by: Frieder Schrempf <frieder.schrempf@exceet.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-11spi: Extend the core to ease integration of SPI memory controllersBoris Brezillon
Some controllers are exposing high-level interfaces to access various kind of SPI memories. Unfortunately they do not fit in the current spi_controller model and usually have drivers placed in drivers/mtd/spi-nor which are only supporting SPI NORs and not SPI memories in general. This is an attempt at defining a SPI memory interface which works for all kinds of SPI memories (NORs, NANDs, SRAMs). Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@exceet.de> Tested-by: Frieder Schrempf <frieder.schrempf@exceet.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-30spi: Fix double "when"Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-06-13spi: Generalize SPI "master" to "controller"Geert Uytterhoeven
Now struct spi_master is used for both SPI master and slave controllers, it makes sense to rename it to struct spi_controller, and replace "master" by "controller" where appropriate. For now this conversion is done for SPI core infrastructure only. Wrappers are provided for backwards compatibility, until all SPI drivers have been converted. Noteworthy details: - SPI_MASTER_GPIO_SS is retained, as it only makes sense for SPI master controllers, - spi_busnum_to_master() is retained, as it looks up masters only, - A new field spi_device.controller is added, but spi_device.master is retained for compatibility (both are always initialized by spi_alloc_device()), - spi_flash_read() is used by SPI masters only. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-05-26spi: core: Add support for registering SPI slave controllersGeert Uytterhoeven
Add support for registering SPI slave controllers using the existing SPI master framework: - SPI slave controllers must use spi_alloc_slave() instead of spi_alloc_master(), and should provide an additional callback "slave_abort" to abort an ongoing SPI transfer request, - SPI slave controllers are added to a new "spi_slave" device class, - SPI slave handlers can be bound to the SPI slave device represented by an SPI slave controller using a DT child node named "slave", - Alternatively, (un)binding an SPI slave handler to the SPI slave device represented by an SPI slave controller can be done by (un)registering the slave device through a sysfs virtual file named "slave". From the point of view of an SPI slave protocol handler, an SPI slave controller looks almost like an ordinary SPI master controller. The only exception is that a transfer request will block on the remote SPI master, and may be cancelled using spi_slave_abort(). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-04-26Merge remote-tracking branches 'spi/topic/ti-qspi' and 'spi/topic/xlp' into ↵Mark Brown
spi-next
2017-04-26Merge remote-tracking branches 'spi/topic/devprop', 'spi/topic/fsl', ↵Mark Brown
'spi/topic/fsl-dspi', 'spi/topic/imx' and 'spi/topic/lantiq' into spi-next
2017-04-21spi: Add can_dma like interface for spi_flash_readVignesh R
Add an interface analogous to ->can_dma() for spi_flash_read() interface. This will enable SPI controller drivers to inform SPI core when not to do DMA mappings. Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-03-29spi: dynamycally allocated message initializationEmiliano Ingrassia
Invoke the proper function while initializing a dynamically allocated spi_message to avoid NULL pointer dereference during resources deallocation. Signed-off-by: Emiliano Ingrassia <ingrassia@epigenesys.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-03-06spi: allow attaching device properties to SPI board infoDmitry Torokhov
Generic device properties support statically defined property sets. For them to be usable, we need to attach these property sets before devices are registered and probed. Allowing to attach property list to spi_board_info structure will allow non-ACPI non-DT boards switch to using generic properties and get rid of custom platform data. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-10-21spi: Add Flag to Enable Slave Select with GPIO Chip Select.Thor Thayer
Some SPI masters require slave selection before the transfer can begin [1]. The SPI framework currently selects the chip using either 1) the internal CS mechanism or 2) the GPIO CS, but not both. This patch adds a new master->flags define to indicate both the GPIO CS and the internal chip select mechanism should be used. Tested On: Altera CycloneV development kit Compile tested for build errors on x86_64 (allyesconfigs) [1] DesignWare dw_apb_ssi Databook, Version 3.20a (page 39) Signed-off-by: Thor Thayer <tthayer@opensource.altera.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-30Merge remote-tracking branches 'spi/topic/fsl-espi', 'spi/topic/imx', ↵Mark Brown
'spi/topic/jcore', 'spi/topic/loopback' and 'spi/topic/meson' into spi-next
2016-09-16spi: core: Use spi_sync_transfer() in spi_write()/spi_read()Geert Uytterhoeven
Simplify spi_write() and spi_read() using the spi_sync_transfer() helper. This requires moving spi_sync_transfer() up. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-18spi: introduce max_message_size hook in spi_masterHeiner Kallweit
Recently a maximum transfer size was was introduced in struct spi_master. However there are also spi controllers with a maximum message size, e.g. fsl-espi has a max message size of 64KB. Introduce a hook max_message_size to deal with such limitations. Also make sure that spi_max_transfer_size doesn't return greater values than spi_max_message_size, even if hook max_transfer_size is not set. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-25spi: Split bus and I/O lockingMark Brown
The current SPI code attempts to use bus_lock_mutex for two purposes. One is to implement spi_bus_lock() which grants exclusive access to the bus. The other is to serialize access to the physical hardware. This duplicate purpose causes confusion which leads to cases where access is not locked when a caller holds the bus lock mutex. Fix this by splitting out the I/O functionality into a new io_mutex. This means taking both mutexes in the DMA path, replacing the existing mutex with the new I/O one in the message pump (the mutex now always being taken in the message pump) and taking the bus lock mutex in spi_sync(), allowing __spi_sync() to have no mutex handling. While we're at it hoist the mutex further up the message pump before we power up the device so that all power up/down of the block is covered by it and there are no races with in-line pumping of messages. Reported-by: Rich Felker <dalias@libc.org> Tested-by: Rich Felker <dalias@libc.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-08spi: Add DMA support for spi_flash_read()Vignesh R
Few SPI devices provide accelerated read interfaces to read from SPI-NOR flash devices. These hardwares also support DMA to transfer data from flash to memory either via mem-to-mem DMA or dedicated slave DMA channels. Hence, add support for DMA in order to improve throughput and reduce CPU load. Use spi_map_buf() to get sg table for the buffer and pass it to SPI driver. Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-04-25spi: core: add hook flash_read_supported to spi_masterHeiner Kallweit
If hook spi_flash_read is implemented the fast flash read feature is enabled for all devices attached to the respective master. In most cases there is just one flash chip, however there are also devices with more than one flash chip, namely some WiFi routers. Then the fast flash read feature can be used for the first chip only. OpenWRT implemented an own handling of this case, using controller_data element of spi_device to hold the information whether fast flash read can be used for a device. This patch adds hook flash_read_supported to spi_master which is used to extend spi_flash_read_supported() by checking whether the fast flash read feature can be used for a specific spi_device. If the hook is not implemented the default behavior is to allow fast flash read for all devices (if spi_flash_read is implemented). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-11Merge remote-tracking branches 'spi/topic/res', 'spi/topic/rockchip', ↵Mark Brown
'spi/topic/sh', 'spi/topic/ti-qspi' and 'spi/topic/xilinx' into spi-next
2016-03-11Merge remote-tracking branches 'spi/topic/lp8841', 'spi/topic/msg', ↵Mark Brown
'spi/topic/pl022' and 'spi/topic/pxa2xx' into spi-next
2016-03-11Merge remote-tracking branches 'spi/topic/doc', 'spi/topic/dw' and ↵Mark Brown
'spi/topic/flash' into spi-next
2016-03-11Merge remote-tracking branches 'spi/topic/acpi', 'spi/topic/axi-engine', ↵Mark Brown
'spi/topic/bcm2835' and 'spi/topic/bcm2835aux' into spi-next