summaryrefslogtreecommitdiff
path: root/drivers/spi/spi-bcm2835.c
AgeCommit message (Collapse)Author
2024-02-05spi: bcm2835: implement ctlr->max_transfer_sizeDavid Lechner
The core SPI code will handle splitting transfers if needed as long as ctlr->max_transfer_size is implemented. It does this in __spi_pump_transfer_message() immediately before calling ctlr->prepare_message. So effectively, this change does not alter the behavior of the driver. Also, several peripheral drivers make use of spi_max_transfer_size(), so this should improve compatibility with those drivers. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20240126220024.3926403-2-dlechner@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-10-10spi: bcm2835: add a sentinel at the end of the lookup arrayBartosz Golaszewski
GPIOLIB expects the array of lookup entries to be terminated with an empty member. We need to increase the size of the variable length array in the lookup table by 1. Fixes: 21f252cd29f0 ("spi: bcm2835: reduce the abuse of the GPIO API") Reported-by: Hans de Goede <hdegoede@redhat.com> Closes: https://lore.kernel.org/lkml/29764d46-8d3d-9794-bbde-d7928a91cbb5@redhat.com/ Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231004183906.97845-1-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-18spi: bcm2835: reduce the abuse of the GPIO APIBartosz Golaszewski
Currently the bcm2835 SPI driver uses functions that are available exclusively to GPIO providers as a way to handle a platform quirk. Let's use a slightly better alternative that avoids poking around in GPIOLIB's internals and use GPIO lookup tables. Link: https://www.spinics.net/lists/linux-gpio/msg36218.html Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230911161553.24313-1-brgl@bgdev.pl Signed-off-by: Mark Brown <broonie@kernel.org>
2023-09-11spi: bcm2835: Use helper function devm_clk_get_enabled()Li Zetao
Since commit 7ef9651e9792 ("clk: Provide new devm_clk helpers for prepared and enabled clocks"), devm_clk_get() and clk_prepare_enable() can now be replaced by devm_clk_get_enabled() when driver enables (and possibly prepares) the clocks for the whole lifetime of the device. Moreover, it is no longer necessary to unprepare and disable the clocks explicitly. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Li Zetao <lizetao1@huawei.com> Link: https://lore.kernel.org/r/20230823133938.1359106-7-lizetao1@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-07spi: switch to use modern nameMark Brown
Merge series from Yang Yingliang <yangyingliang@huawei.com>: After introducing devm_spi_alloc_host/spi_alloc_host(), the legacy named function devm_spi_alloc_master/spi_alloc_master() can be replaced. And also change other legacy name master/slave to modern name host/target or controller.
2023-08-07spi: Do not check for 0 return after calling platform_get_irq()Ruan Jinjie
It is not possible for platform_get_irq() to return 0. Use the return value from platform_get_irq(). Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> # Link: https://lore.kernel.org/r/20230802093238.975906-1-ruanjinjie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-08-07spi: bcm2835: switch to use modern nameYang Yingliang
Change legacy name master/slave to modern name host/target. No functional changed. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230728093221.3312026-6-yangyingliang@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-31spi: Use dev_err_probe instead of dev_errWang Ming
It is possible that dma_request_chan will return EPROBE_DEFER, which means that dev is not ready yet. In this case, dev_err(dev), there will be no output. This patch fixes the bug. Signed-off-by: Wang Ming <machel@vivo.com> Link: https://lore.kernel.org/r/20230726105457.3743-1-machel@vivo.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-20spi: fix return value check in bcm2835_spi_probe()Yuanjun Gong
in bcm2835_spi_probe(), clk_prepare_enable() may fail, therefore, the return value of clk_prepare_enable() should be checked, and the function should return error if clk_prepare_enable() fails. Signed-off-by: Yuanjun Gong <ruc_gongyuanjun@163.com> Link: https://lore.kernel.org/r/20230720140859.33883-1-ruc_gongyuanjun@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-07-14spi: Explicitly include correct DT includesRob Herring
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230714174955.4064174-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-31spi: bcm2835: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Convert this driver from always returning zero in the remove callback to the void returning variant. Now that bcm2835_spi_remove returns no error code any more, bcm2835_spi_shutdown() does the same thing as bcm2835_spi_remove(). So drop the shutdown function and use bcm2835_spi_remove() as .shutdown callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230330211022.2460233-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2023-03-11spi: Replace all spi->chip_select and spi->cs_gpiod references with function ↵Amit Kumar Mahapatra via Alsa-devel
call Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod members of struct spi_device to be an array. But changing the type of these members to array would break the spi driver functionality. To make the transition smoother introduced four new APIs to get/set the spi->chip_select & spi->cs_gpiod and replaced all spi->chip_select and spi->cs_gpiod references with get or set API calls. While adding multi-cs support in further patches the chip_select & cs_gpiod members of the spi_device structure would be converted to arrays & the "idx" parameter of the APIs would be used as array index i.e., spi->chip_select[idx] & spi->cs_gpiod[idx] respectively. Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Acked-by: Heiko Stuebner <heiko@sntech.de> # Rockchip drivers Reviewed-by: Michal Simek <michal.simek@amd.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> # Aspeed driver Reviewed-by: Dhruva Gole <d-gole@ti.com> # SPI Cadence QSPI Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> # spi-stm32-qspi Acked-by: William Zhang <william.zhang@broadcom.com> # bcm63xx-hsspi driver Reviewed-by: Serge Semin <fancer.lancer@gmail.com> # DW SSI part Link: https://lore.kernel.org/r/167847070432.26.15076794204368669839@mailman-core.alsa-project.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-02Merge tag 'spi-v5.20' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi updates from Mark Brown: "The big update this time around is some excellent work from David Jander who went through the fast path and really eliminated overheads, meaning that we are seeing a huge reduction in the time spent between transfers for single threaded clients. Benchmarking has been coming out at about a halving of overhead which is clearly visible in system level usage that stresses SPI like some CAN and IIO applications, especially with small transfers. Thanks to David for taking the time to drill down into this and push the work upstream. Otherwise there's been a bunch of new device support and the usual updates. - Optimisation of the fast path, particularly around the number and types of locking operations, from David Jander. - Support for Arbel NPCM845, HP GXP, Intel Meteor Lake and Thunder Bay, MediaTek MT8188 and MT8365, Microchip FPGAs, nVidia Tegra 241 and Samsung Exynos Auto v9 and 4210" * tag 'spi-v5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (97 commits) MAINTAINERS: add spi support to GXP spi: dt-bindings: add documentation for hpe,gxp-spifi spi: spi-gxp: Add support for HPE GXP SoCs spi: a3700: support BE for AC5 SPI driver spi/panel: dt-bindings: drop CPHA and CPOL from common properties spi: bcm2835: enable shared interrupt support spi: dt-bindings: spi-controller: correct example indentation spi: dt-bindings: qcom,spi-geni-qcom: allow three interconnects spi: npcm-fiu: Add NPCM8XX support dt-binding: spi: Add npcm845 compatible to npcm-fiu document spi: npcm-fiu: Modify direct read dummy configuration spi: atmel: remove #ifdef CONFIG_{PM, SLEEP} spi: dt-bindings: Add compatible for MediaTek MT8188 spi: dt-bindings: mediatek,spi-mtk-nor: Update bindings for nor flash spi: dt-bindings: atmel,at91rm9200-spi: convert to json-schema spi: tegra20-slink: fix UAF in tegra_slink_remove() spi: Fix simplification of devm_spi_register_controller spi: microchip-core: switch to use dev_err_probe() spi: microchip-core: switch to use devm_spi_alloc_master() spi: microchip-core: fix UAF in mchp_corespi_remove() ...
2022-07-25spi: bcm2835: enable shared interrupt supportMartin Sperl
BCM2711 shares an interrupt betweem 5 SPI interfaces (0, 3, 4, 5 & 6). Another interrupt is shared between SPI1, SPI2 and UART1, which also affects BCM2835/6/7. Acting on an interrupt intended for another interface ought to be harmless (although potentially inefficient), but it can cause this driver to crash - presumably because some critical state is not ready. Add a test to the spi-bcm2835 interrupt service routine that interrupts are enabled on this interface to avoid the crash and improve efficiency. Signed-off-by: Martin Sperl <kernel@martin.sperl.org> Link: https://github.com/raspberrypi/linux/issues/5048 Suggested-by: https://github.com/boe-pi Co-developed-by: Phil Elwell <phil@raspberrypi.com> Signed-off-by: Phil Elwell <phil@raspberrypi.com> Cc: Mark Brown <broonie@kernel.org> Cc: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20220719105305.3076354-1-mkl@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2022-07-20spi: bcm2835: bcm2835_spi_handle_err(): fix NULL pointer deref for non DMA ↵Marc Kleine-Budde
transfers In case a IRQ based transfer times out the bcm2835_spi_handle_err() function is called. Since commit 1513ceee70f2 ("spi: bcm2835: Drop dma_pending flag") the TX and RX DMA transfers are unconditionally canceled, leading to NULL pointer derefs if ctlr->dma_tx or ctlr->dma_rx are not set. Fix the NULL pointer deref by checking that ctlr->dma_tx and ctlr->dma_rx are valid pointers before accessing them. Fixes: 1513ceee70f2 ("spi: bcm2835: Drop dma_pending flag") Cc: Lukas Wunner <lukas@wunner.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20220719072234.2782764-1-mkl@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-07-20spi: spi-bcm2835: Fix deadlockAlexandru Tachici
The bcm2835_spi_transfer_one function can create a deadlock if it is called while another thread already has the CCF lock. Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com> Fixes: f8043872e796 ("spi: add driver for BCM2835") Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210716210245.13240-2-alexandru.tachici@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-06-02spi: bcm2835: Allow arbitrary number of slavesLukas Wunner
Since commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for ->prepare_message()"), the number of slaves has been limited by a compile-time constant. This was necessitated by statically-sized arrays in the driver private data which contain per-slave register values. As suggested by Mark, move those register values to a per-slave controller_state which is allocated on ->setup and freed on ->cleanup. The limitation on the number of slaves is thus lifted. Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: Joe Burmeister <joe.burmeister@devtank.co.uk> Cc: Phil Elwell <phil@raspberrypi.com> Link: https://lore.kernel.org/r/a847c01f09400801e74e0630bf5a0197591554da.1622150204.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-24spi: bcm2835: Fix out-of-bounds access with more than 4 slavesLukas Wunner
Commit 571e31fa60b3 ("spi: bcm2835: Cache CS register value for ->prepare_message()") limited the number of slaves to 3 at compile-time. The limitation was necessitated by a statically-sized array prepare_cs[] in the driver private data which contains a per-slave register value. The commit sought to enforce the limitation at run-time by setting the controller's num_chipselect to 3: Slaves with a higher chipselect are rejected by spi_add_device(). However the commit neglected that num_chipselect only limits the number of *native* chipselects. If GPIO chipselects are specified in the device tree for more than 3 slaves, num_chipselect is silently raised by of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to the statically-sized array prepare_cs[]. As a bandaid fix which is backportable to stable, raise the number of allowed slaves to 24 (which "ought to be enough for anybody"), enforce the limitation on slave ->setup and revert num_chipselect to 3 (which is the number of native chipselects supported by the controller). An upcoming for-next commit will allow an arbitrary number of slaves. Fixes: 571e31fa60b3 ("spi: bcm2835: Cache CS register value for ->prepare_message()") Reported-by: Joe Burmeister <joe.burmeister@devtank.co.uk> Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v5.4+ Cc: Phil Elwell <phil@raspberrypi.com> Link: https://lore.kernel.org/r/75854affc1923309fde05e47494263bde73e5592.1621703210.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-14spi: bcm2835: Call the dedicated transfer completion function.Vincent Pelletier
spi_finalize_current_transfer currently only calls "complete", so no functional change is expected. Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com> Link: https://lore.kernel.org/r/633c3d5c350dde4d14ce2120c32698c25b95d302.1610062884.git.plr.vincent@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-13spi: bcm2835: Set controller max_speed_hzRichard Fitzgerald
Set the struct spi_controller max_speed_hz. This is based on the reported source clock frequency during probe. The maximum bus clock is half the source clock (as per the code in bcm2835_spi_transfer_one). Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210107164825.21919-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-12spi: bcm2835: Fix use-after-free on unbindLukas Wunner
bcm2835_spi_remove() accesses the driver's private data after calling spi_unregister_controller() even though that function releases the last reference on the spi_controller and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound. Fixes: f8043872e796 ("spi: add driver for BCM2835") Reported-by: Sascha Hauer <s.hauer@pengutronix.de> Reported-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v3.10+: 123456789abc: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v3.10+ Cc: Vladimir Oltean <olteanv@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/ad66e0a0ad96feb848814842ecf5b6a4539ef35c.1605121038.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-06spi: bcm2835: remove use of uninitialized gpio flags variableMartin Hundebøll
Removing the duplicate gpio chip select level handling in bcm2835_spi_setup() left the lflags variable uninitialized. Avoid trhe use of such variable by passing default flags to gpiochip_request_own_desc(). Fixes: 5e31ba0c0543 ("spi: bcm2835: fix gpio cs level inversion") Signed-off-by: Martin Hundebøll <martin@geanix.com> Link: https://lore.kernel.org/r/20201105090615.620315-1-martin@geanix.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-29spi: bcm2835: fix gpio cs level inversionMartin Hundebøll
The work on improving gpio chip-select in spi core, and the following fixes, has caused the bcm2835 spi driver to use wrong levels. Fix this by simply removing level handling in the bcm2835 driver, and let the core do its work. Fixes: 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") Cc: <stable@vger.kernel.org> Signed-off-by: Martin Hundebøll <martin@geanix.com> Link: https://lore.kernel.org/r/20201014090230.2706810-1-martin@geanix.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-14spi: bcm2835: Make polling_limit_us staticJason Yan
This eliminates the following sparse warning: drivers/spi/spi-bcm2835.c:78:14: warning: symbol 'polling_limit_us' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200912072211.602735-1-yanaijie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-08spi: bcm2835: Simplify with dev_err_probe()Krzysztof Kozlowski
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and the error value gets printed. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20200901152713.18629-4-krzk@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-17spi: bcm2835: support effective_speed_hzMartin Sperl
Setting spi_transfer->effective_speed_hz in transfer_one so that it can get used in cs_change_delay configured with delay as a muliple of SPI clock cycles. Signed-off-by: Martin Sperl <kernel@martin.sperl.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20200709074120.110069-2-mkl@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-01spi: bcm2835: Micro-optimise FIFO loopsRobin Murphy
The blind and counted loops are always called with nonzero count, so convert them to do-while loops that lead to slightly more efficient code generation. With GCC 8.3 this shaves off 1-2 instructions per iteration in each case. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/9242863077acf9a64e4b3720e479855b88d19e82.1592261248.git.robin.murphy@arm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-01spi: bcm2835: Micro-optimise IRQ handlerRobin Murphy
The IRQ handler only needs the struct spi_controller for the sake of the completion at the end of a transfer. Passing the struct bcm2835_spi directly as the IRQ data allows that level of indirection to be pushed into the completion path for the reverse lookup, and avoided entirely in all other cases. This saves one explicit load in the critical path, plus (for a GCC 8.3 build) two registers worth of stack frame overhead. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/6b401cb521539caffab21f05b4c8cba6c9d27c6e.1592261248.git.robin.murphy@arm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-01spi: bcm3835: Tidy up bcm2835_spi_reset_hw()Robin Murphy
It doesn't need a struct spi_controller, and every callsite has already retrieved the appropriate struct bcm2835_spi, so just pass that directly. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/eca458ae1a0d3934d0627f90e25d294fefd4b13d.1592261248.git.robin.murphy@arm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-29spi: bcm2835: Remove shared interrupt supportMark Brown
This reverts commit ecfbd3cf3b8b since Lukas Wunner noticed that we start operating on the hardware before we check to see if this is a spurious interrupt. Reported-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-29spi: bcm2835: Enable shared interrupt supportMartin Sperl
bcm2711, Rasberry Pi 4's SoC, shares one interrupt for multiple instances of the bcm2835 SPI controller. So this enables shared interrupt support for them. The early bail out in the interrupt routine avoids messing with buffers of transfers being done by other means. Otherwise, the driver can handle receiving interrupts asserted by other controllers during an IRQ based transfer. Signed-off-by: Martin Sperl <kernel@martin.sperl.org> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20200528185805.28991-1-nsaenzjulienne@suse.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-29spi: bcm2835: Implement shutdown callbackFlorian Fainelli
Make sure we clear the FIFOs, stop the block, disable the clock and release the DMA channel. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20200528190605.24850-1-f.fainelli@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20spi: bcm2835: Tear down DMA before turning off SPI controllerLukas Wunner
On unbind of the BCM2835 SPI driver, the SPI controller is disabled first and the DMA channels are terminated and torn down afterwards. This seems backwards: In the theoretical case that DMA is active, it might try to fill the SPI FIFOs even after the controller has been disabled. Reverse the order, thereby mirroring what's done on ->probe(). Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/ac79f1e3d6fd9a1f5e0cb4008c43b98ea70be3c2.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-20Merge branch 'for-5.7' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.8
2020-05-20spi: bcm2835: Fix controller unregister orderLukas Wunner
The BCM2835 SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes bcm2835_spi_remove() before unregistering the SPI controller via devres_release_all(). This order is incorrect: bcm2835_spi_remove() tears down the DMA channels and turns off the SPI controller, including its interrupts and clock. The SPI controller is thus no longer usable. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. If their drivers need to access the SPI bus, e.g. to quiesce their interrupts, unbinding will fail. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unbinding of slaves. Fix by using the non-devm variant spi_register_controller(). Note that the struct spi_controller as well as the driver-private data are not freed until after bcm2835_spi_remove() has finished, so accessing them is safe. Fixes: 247263dba208 ("spi: bcm2835: use devm_spi_register_master()") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v3.13+ Link: https://lore.kernel.org/r/2397dd70cdbe95e0bc4da2b9fca0f31cb94e5aed.1589557526.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-06spi: bcm2835: Fix error return code in bcm2835_dma_init()Wei Yongjun
Fix to return negative error code -ENOMEM from the dma mapping error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20200506125607.90952-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-05spi: bcm2835: Fixes bare use of unsignedJacko Dirks
Signed-off-by: Jacko Dirks <jdirks.linuxdev@gmail.com> Link: https://lore.kernel.org/r/20200503200033.GA3256@vasteMachine Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09spi: bcm2835: Raise maximum number of slaves to 4Lukas Wunner
The "RevPi Connect Flat" PLC offered by KUNBUS has 4 slaves attached to the BCM2835 SPI master. Raise the maximum number of slaves in the driver accordingly. Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/01453fd062de2d49bd74a847e13a0781cbf8143d.1578572268.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-17spi: bcm2835: no dev_err() on clk_get() -EPROBE_DEFERJim Quinlan
Use dev_dbg() on -EPROBE_DEFER and dev_err() on all other errors. Signed-off-by: Jim Quinlan <jquinlan@broadcom.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/20191216230802.45715-2-jquinlan@broadcom.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-16spi: bcm2835: Use dma_request_chan() instead dma_request_slave_channel()Peter Ujfalusi
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20191212135550.4634-4-peter.ujfalusi@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-16spi: bcm2835: Release the DMA channel if probe fails after dma_initPeter Ujfalusi
The DMA channel was not released if either devm_request_irq() or devm_spi_register_controller() failed. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Link: https://lore.kernel.org/r/20191212135550.4634-3-peter.ujfalusi@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-05spi: bcm2835: fix typo in commentChris Packham
GPIOS_OUT_LOW should be GPIOD_OUT_LOW. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20191105214134.25142-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-15Merge branch 'spi-5.4' into spi-nextMark Brown
2019-09-11spi: bcm2835: Speed up RX-only DMA transfers by zero-filling TX FIFOLukas Wunner
The BCM2835 SPI driver currently sets the SPI_CONTROLLER_MUST_TX flag. When performing an RX-only transfer, this flag causes the SPI core to allocate and DMA-map a dummy buffer which is copied to the TX FIFO. The dummy buffer is necessary because the chip is not capable of automatically clocking out null bytes. Avoid the overhead induced by the dummy buffer by preallocating a reusable DMA transaction which fills the TX FIFO by cyclically copying from the zero page. The transaction requires very little CPU time to submit and generates no interrupts while running. Specifics are provided in kerneldoc comments. [Nathan Chancellor contributed a DMA mapping fixup for an early version of this commit, hence his Signed-off-by.] Tested-by: Nuno Sá <nuno.sa@analog.com> Tested-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Link: https://lore.kernel.org/r/f45920af18dbf06e34129bbc406f53dc9c5d1075.1568187525.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11spi: bcm2835: Speed up TX-only DMA transfers by clearing RX FIFOLukas Wunner
The BCM2835 SPI driver currently sets the SPI_CONTROLLER_MUST_RX flag. When performing a TX-only transfer, this flag causes the SPI core to allocate and DMA-map a dummy buffer into which the RX FIFO contents are copied. The dummy buffer is necessary because the chip is not capable of disabling the receiver or automatically throwing away received data. Not reading the RX FIFO isn't an option either since transmission is halted once it's full. Avoid the overhead induced by the dummy buffer by preallocating a reusable DMA transaction which cyclically clears the RX FIFO. The transaction requires very little CPU time to submit and generates no interrupts while running. Specifics are provided in kerneldoc comments. With a ks8851 Ethernet chip attached to the SPI controller, I am seeing a 30 us reduction in ping time with this commit (1.819 ms vs. 1.849 ms, average of 100,000 packets) as well as a 2% reduction in CPU time (75:08 vs. 76:39 for transmission of 5 GByte over the SPI bus). The commit uses the TX DMA interrupt to signal completion of a transfer. This interrupt is raised once all bytes have been written to the TX FIFO and it is then necessary to busy-wait for the TX FIFO to become empty before the transfer can be finalized. As an alternative approach, I have explored using the SPI controller's DONE interrupt to detect completion. This interrupt is signaled when the TX FIFO becomes empty, avoiding the need to busy-wait. However latency deteriorates compared to the present commit and surprisingly, CPU time is slightly higher as well: It turns out that in 45% of the cases, no busy-waiting is needed at all and in 76% of the cases, less than 10 busy-wait iterations are sufficient for the TX FIFO to drain. This was measured on an RT kernel. On a vanilla kernel, wakeup latency is worse and thus fewer iterations are needed. The measurements were made with an SPI clock of 20 MHz, they may differ slightly for slower or faster clock speeds. Previously we always used the RX DMA interrupt to signal completion of a transfer. Using the TX DMA interrupt now introduces a race condition: TX DMA is always started before RX DMA so that bytes are already clocked out while RX DMA is still being set up. But if a TX-only transfer is very short, then the TX DMA interrupt may occur before RX DMA is set up. If the interrupt happens to occur on the same CPU, setup of RX DMA may even be delayed until after the interrupt was handled. I've solved this by having the TX DMA callback clear the RX FIFO while busy-waiting for the TX FIFO to drain, thus avoiding a dependency on setup of RX DMA. Additionally, I am using a lock-free mechanism with two flags, tx_dma_active and rx_dma_active plus memory barriers to terminate RX DMA either by the TX DMA callback or immediately after setting it up, whichever wins the race. I've explored an alternative approach which temporarily disables the TX DMA callback until RX DMA has been set up (using tasklet_disable(), local_bh_disable() or local_irq_save()), but the performance was minimally worse. [Nathan Chancellor contributed a DMA mapping fixup for an early version of this commit, hence his Signed-off-by.] Tested-by: Nuno Sá <nuno.sa@analog.com> Tested-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Link: https://lore.kernel.org/r/874949385f28251e2dcaa9494e39a27b50e9f9e4.1568187525.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11spi: bcm2835: Cache CS register value for ->prepare_message()Lukas Wunner
The BCM2835 SPI driver needs to set up the clock polarity in its ->prepare_message() hook before spi_transfer_one_message() asserts chip select to avoid a gratuitous clock signal edge (cf. commit acace73df2c1 ("spi: bcm2835: set up spi-mode before asserting cs-gpio")). Precalculate the CS register value (which selects the clock polarity) once in ->setup() and use that cached value in ->prepare_message() and ->transfer_one(). This avoids one MMIO read per message and one per transfer, yielding a small latency improvement. Additionally, a forthcoming commit will use the precalculated value to derive the register value for clearing the RX FIFO, which will eliminate the need for an RX dummy buffer when performing TX-only DMA transfers. Tested-by: Nuno Sá <nuno.sa@analog.com> Tested-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Link: https://lore.kernel.org/r/d17c1d7fcdc97fffa961b8737cfd80eeb14f9416.1568187525.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11spi: bcm2835: Drop dma_pending flagLukas Wunner
The BCM2835 SPI driver uses a flag to keep track of whether a DMA transfer is in progress. The flag is used to avoid terminating DMA channels multiple times if a transfer finishes orderly while simultaneously the SPI core invokes the ->handle_err() callback because the transfer took too long. However terminating DMA channels multiple times is perfectly fine, so the flag is unnecessary for this particular purpose. The flag is also used to avoid invoking bcm2835_spi_undo_prologue() multiple times under this race condition. However multiple *concurrent* invocations can no longer happen since commit 2527704d8411 ("spi: bcm2835: Synchronize with callback on DMA termination") because the ->handle_err() callback now uses the _sync() variant when terminating DMA channels. The only raison d'être of the flag is therefore that bcm2835_spi_undo_prologue() cannot cope with multiple *sequential* invocations. Achieve that by setting tx_prologue to 0 at the end of the function. Subsequent invocations thus become no-ops. With that, the dma_pending flag becomes unnecessary, so drop it. Tested-by: Nuno Sá <nuno.sa@analog.com> Tested-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Link: https://lore.kernel.org/r/062b03b7f86af77a13ce0ec3b22e0bdbfcfba10d.1568187525.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-10spi: bcm2835: Work around DONE bit erratumLukas Wunner
Commit 3bd7f6589f67 ("spi: bcm2835: Overcome sglist entry length limitation") amended the BCM2835 SPI driver with support for DMA transfers whose buffers are not aligned to 4 bytes and require more than one sglist entry. When testing this feature with upcoming commits to speed up TX-only and RX-only transfers, I noticed that SPI transmission sometimes breaks. A function introduced by the commit, bcm2835_spi_transfer_prologue(), performs one or two PIO transmissions as a prologue to the actual DMA transmission. It turns out that the breakage goes away if the DONE bit in the CS register is set when ending such a PIO transmission. The DONE bit signifies emptiness of the TX FIFO. According to the spec, the bit is of type RO, so writing it should never have any effect. Perhaps the spec is wrong and the bit is actually of type RW1C. E.g. the I2C controller on the BCM2835 does have an RW1C DONE bit which needs to be cleared by the driver. Another, possibly more likely explanation is that it's a hardware erratum since the issue does not occur consistently. Either way, amend bcm2835_spi_transfer_prologue() to always write the DONE bit. Usually a transmission is ended by bcm2835_spi_reset_hw(). If the transmission was successful, the TX FIFO is empty and thus the DONE bit is set when bcm2835_spi_reset_hw() reads the CS register. The bit is then written back to the register, so we happen to do the right thing. However if DONE is not set, e.g. because transmission is aborted with a non-empty TX FIFO, the bit won't be written by bcm2835_spi_reset_hw() and it seems possible that transmission might subsequently break. To be on the safe side, likewise amend bcm2835_spi_reset_hw() to always write the bit. Tested-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Link: https://lore.kernel.org/r/edb004dff4af6106f6bfcb89e1a96391e96eb857.1564825752.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: bcm2835: use devm_platform_ioremap_resource() to simplify codeYueHaibing
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-7-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-08-28spi: bcm2835: Convert to use CS GPIO descriptorsLinus Walleij
This converts the BCM2835 SPI master driver to use GPIO descriptors for chip select handling. The BCM2835 driver was relying on the core to drive the CS high/low so very small changes were needed for this part. If it managed to request the CS from the device tree node, all is pretty straight forward. However for native GPIOs this driver has a quite unorthodox loopback to request some GPIOs from the SoC GPIO chip by looking it up from the device tree using gpiochip_find() and then offseting hard into its numberspace. This has been augmented a bit by using gpiochip_request_own_desc() but this code really needs to be verified. If "native CS" is actually an SoC GPIO, why is it even done this way? Should this GPIO not just be defined in the device tree like any other CS GPIO? I'm confused. Cc: Lukas Wunner <lukas@wunner.de> Cc: Stefan Wahren <stefan.wahren@i2se.com> Cc: Martin Sperl <kernel@martin.sperl.org> Cc: Chris Boot <bootc@bootc.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190804003852.1312-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3-58-ga151 (git 2.39.0) at 2024-12-27 00:27:17 +0000