- 23 Jun, 2023 1 commit
-
-
Mark Brown authored
Merge series from Miquel Raynal <miquel.raynal@bootlin.com>: I recently came across an issue with the Atmel spi controller driver which would stop my transfers after a too small timeout when performing big transfers (reading a 4MiB flash in one transfer). My initial idea was to derive a the maximum amount of time a transfer would take depending on its size and use that as value to avoid erroring-out when not relevant. Mark wanted to go further by creating a core helper doing that, based on the heuristics from the sun6i driver. Here is a small series of 3 patches doing exactly that.
-
- 22 Jun, 2023 4 commits
-
-
Miquel Raynal authored
A helper was recently added to the core to factorize common code between drivers, like the amount of time a driver should wait for a transfer to happen. It is of course possible to use a default value (like eg. 1s) but it is way stronger to adapt this amount of time to the transfer. Indeed, long transfers (eg. 4MiB) on a slow single-spi bus might take more than the usual second of timeout and prevent lengthy transfers. The core helper was heavily inspired by the logic applied in this driver, the only difference being the minimum amount of time which was enlarged from 0.1s to 0.5s. Use this helper instead of open-coding it. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
Jernej Škrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/Message-Id: <20230622090634.3411468-4-miquel.raynal@bootlin.com> Signed-off-by:
Mark Brown <broonie@kernel.org>
-
Miquel Raynal authored
A slow SPI bus clocks at ~20MHz, which means it would transfer about 2500 bytes per second with a single data line. Big transfers, like when dealing with flashes can easily reach a few MiB. The current DMA timeout is set to 1 second, which means any working transfer of about 4MiB will always be cancelled. With the above derivations, on a slow bus, we can assume every byte will take at most 0.4ms. Said otherwise, we could add 4ms to the 1-second timeout delay every 10kiB. On a 4MiB transfer, it would bring the timeout delay up to 2.6s which still seems rather acceptable for a timeout. The consequence of this is that long transfers might be allowed, which hence requires the need to interrupt the transfer if wanted by the user. We can hence switch to the _interruptible variant of wait_for_completion. This leads to a little bit more handling to also handle the interrupted case but looks really acceptable overall. While at it, we drop the useless, noisy and redundant WARN_ON() call. Signed-off-by:
Ryan Wanner <ryan.wanner@microchip.com> Link: https://lore.kernel.org/r/Message-Id: <20230622090634.3411468-3-miquel.raynal@bootlin.com> Signed-off-by:
-
Valentin Caron authored
STM32F4-F7 are, from hardware point of view, capable to handle device mode. So this property should not be forced at false in dt-bindings. Signed-off-by:
Valentin Caron <valentin.caron@foss.st.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/Message-Id: <20230621115523.923176-3-valentin.caron@foss.st.com> Signed-off-by:
-
Miquel Raynal authored
Big transfers might take a bit of time, too constraining timeouts might lead to false positives. In order to simplify the drivers work and with the goal of factorizing code in mind, let's add a helper that can be used by any spi controller driver to derive a relevant per-transfer timeout value. The logic is simple: we know how much time it would take to transfer a byte, we can easily derive the total theoretical amount of time involved for each transfer. We multiply it by two to have a bit of margin and enforce a minimum of 500ms. Suggested-by:
-
- 19 Jun, 2023 1 commit
-
-
Neil Armstrong authored
Now spi_geni_grab_gpi_chan() errors are correctly reported, the -EPROBE_DEFER error should be returned from probe in case the GPI dma driver is built as module and/or not probed yet. Fixes: b59c1224 ("spi: spi-geni-qcom: Add support for GPI dma") Fixes: 6532582c ("spi: spi-geni-qcom: fix error handling in spi_geni_grab_gpi_chan()") Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230615-topic-sm8550-upstream-fix-spi-geni-qcom-probe-v2-1-670c3d9e8c9c@linaro.orgSigned-off-by:
-
- 15 Jun, 2023 4 commits
-
-
Alain Volmat authored
STM32F4 and STM32F7 can't switch to spi device mode. Forbid this property with compatible "st,stm32f4-spi". Signed-off-by:
Alain Volmat <alain.volmat@foss.st.com> Signed-off-by:
-
Valentin Caron authored
Add support for stm32h7 to use SPI controller in device role. In such case, the spi instance should have the spi-slave property defined. Signed-off-by:
-
Alain Volmat authored
Avoid usage of deprecated dmaengine_terminate_all and use dmaengine_terminate_sync and dmaengine_terminate_async instead. Signed-off-by:
-
Alain Volmat authored
Preparing introduction of SPI device, rename the spi_master structure into spi_controller. This doesn't have any functional impact since spi_master was already a macro for spi_controller. Referring now to ctrl instead of master since the spi_controller structure might not be used as a master controller only. Signed-off-by:
-
- 07 Jun, 2023 2 commits
-
-
Mark Brown authored
Merge series from Andi Shyti <andi.shyti@kernel.org>: Two small cleanups in the probe function. The first puts in use the managed spi master allocation while the second implements the dev_err_probe() function.
-
Abe Kohandel authored
Remove a misleading comment about the DMA operations of the Intel Mount Evans SoC's SPI Controller as requested by Serge. Signed-off-by:
Abe Kohandel <abe.kohandel@intel.com> Link: https://lore.kernel.org/linux-spi/20230606191333.247ucbf7h3tlooxf@mobilestation/ Fixes: 0760d5d0 ("spi: dw: Add compatible for Intel Mount Evans SoC") Reviewed-by:
Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20230606231844.726272-1-abe.kohandel@intel.comSigned-off-by:
-
- 06 Jun, 2023 4 commits
-
-
Abe Kohandel authored
Document the DesignWare SSI controller compatible for Intel Mount Evans Integrated Management Complex SoC. Signed-off-by:
-
Abe Kohandel authored
The Intel Mount Evans SoC's Integrated Management Complex uses the SPI controller for access to a NOR SPI FLASH. However, the SoC doesn't provide a mechanism to override the native chip select signal. This driver doesn't use DMA for memory operations when a chip select override is not provided due to the native chip select timing behavior. As a result no DMA configuration is done for the controller and this configuration is not tested. The controller also has an errata where a full TX FIFO can result in data corruption. The suggested workaround is to never completely fill the FIFO. The TX FIFO has a size of 32 so the fifo_len is set to 31. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20230606145402.474866-2-abe.kohandel@intel.comSigned-off-by:
-
Andi Shyti authored
Simplify the code by using dev_err_probe() instead of dev_err() and 'return'. Signed-off-by:
Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20230606012051.2139333-3-andi.shyti@kernel.orgSigned-off-by:
-
Andi Shyti authored
Use devm_spi_alloc_master() and get rid of one goto error path Signed-off-by:
-
- 02 Jun, 2023 2 commits
-
-
Mårten Lindahl authored
When the spi controller is registered and the cs_gpiods cannot be assigned, causing a defer of the probe, there is an error print saying: "probe - problem registering spi master" This should not be announced as an error. Print this message for all errors except for the probe defer. Signed-off-by:
Mårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20230602-pl022-defer-fix-v2-1-383f6bc2293a@axis.comSigned-off-by:
-
Rasmus Villemoes authored
Commit 87c61417 (spi: spi-imx: fix MX51_ECSPI_* macros when cs > 3) ensured that the argument passed to the macros was masked with &3, so that we no longer write outside the intended fields in the various control registers. When all chip selects are gpios, this works just fine. However, when a mix of native and gpio chip selects are in use, that masking is too naive. Say, for example, that SS0 is muxed as native chip select, and there is also a chip at 4 (obviously with a gpio cs). In that case, when accessing the latter chip, both the SS0 pin and the gpio pin will be asserted low. The fix for this is to use the ->unused_native_cs value as channel number for any spi device which uses a gpio as chip select. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://lore.kernel.org/r/20230602115731.708883-1-linux@rasmusvillemoes.dkSigned-off-by:
-
- 01 Jun, 2023 4 commits
-
-
Andi Shyti authored
Replace the tuple devm_clk_get()/clk_prepare_enable() with the single function devm_clk_get_enabled(). Signed-off-by:
-
Krzysztof Kozlowski authored
Remove address/size-cells because they are already mentioned by common spi-controller.yaml. Signed-off-by:
-
Krzysztof Kozlowski authored
Remove cs-gpios because it is already mentioned by common spi-controller.yaml. Signed-off-by:
-
Krzysztof Kozlowski authored
Remove properties already mentioned by common spi-controller.yaml and switch to unevaluatedProperties:false to achieve same functional effect. This makes the binding a bit smaller. Similarly there is no need to allow additionalProperties for children, because spi-controller.yaml already does it. Signed-off-by:
-
- 31 May, 2023 2 commits
-
-
Serge Semin authored
Just drop a redundant empty line from the dw_spi_debugfs_init() function left in the framework of the commit 0178f1e5 ("spi-dw-core.c: Fix error checking for debugfs_create_dir") after removing the last return statement. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20230530221725.26319-1-Sergey.Semin@baikalelectronics.ruSigned-off-by:
-
Alexander Stein authored
Having no DMA is not an error. The simplest reason is not having it configured. SPI will still be usable, so raise a warning instead to get still some attention. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20230531072850.739021-1-alexander.stein@ew.tq-group.comSigned-off-by:
-
- 30 May, 2023 16 commits
-
-
Douglas Anderson authored
A warning added in commit b5762d95 ("spi: spi-qcom-qspi: Add DMA mode support") was missing a newline. Add it. Reported-by:
Stephen Boyd <swboyd@chromium.org> Closes: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/4573857/comment/44331d65_79128099/ Fixes: b5762d95 ("spi: spi-qcom-qspi: Add DMA mode support") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230530111348.1.Ibd1f4827e18a26dc802cd6e5ac300d83dc1bc41c@changeidSigned-off-by:
-
Krzysztof Kozlowski authored
Make the pattern matching node names a bit stricter to improve DTS consistency. The pattern is restricted to: 1. Only one unit address or one -N suffix, 2. -N suffixes to decimal numbers. Suggested-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Mark Brown authored
Get the fixes into CI for development.
-
Mark Brown authored
Merge series from Boerge Struempfel <boerge.struempfel@gmail.com>: Some spi controller switch the mosi line to high, whenever they are idle. This may not be desired in all use cases. For example neopixel leds can get confused and flicker due to misinterpreting the idle state. Therefore, we introduce a new spi-mode bit, with which the idle behaviour can be overwritten on a per device basis.
-
Mark Brown authored
Merge series from Uwe Kleine-König <u.kleine-koenig@pengutronix.de>: Hello, compared to (implicit) v1 sent in March with Message-Id: <20230309094704.2568531-1-u.kleine-koenig@pengutronix.de>, I reworked patch 1 on feedback by AngeloGioacchino Del Regno. Patches 2 and 3 got his Reviewed-by. Best regards Uwe Uwe Kleine-König (3): spi: mt65xx: Properly handle failures in .remove() spi: mt65xx: Convert to platform remove callback returning void spi: mt65xx: Don't disguise a "return 0" as "return ret" drivers/spi/spi-mt65xx.c | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) base-commit: ac9a7868 -- 2.39.2
-
Boerge Struempfel authored
Added the three missing spi mode bits SPI_3WIRE_HIZ, SPI_RX_CPHA_FLIP, and SPI_MOSI_IDLE_LOW. Signed-off-by:
Boerge Struempfel <boerge.struempfel@gmail.com> Link: https://lore.kernel.org/r/20230530141641.1155691-6-boerge.struempfel@gmail.comSigned-off-by:
-
Boerge Struempfel authored
In order to increase usability, the command line options are sorted into logical groups. In addition, the usage string was sorted alphabetically, and the missing parameters '8','i' and 'o' were added. Furthermore, the option descriptions were moved further to the right, in order to allow for longer option names. Signed-off-by:
-
Boerge Struempfel authored
Allow userspace to set SPI_MOSI_IDLE_LOW and the SPI_3WIRE_HIZ mode bit using the SPI_IOC_WR_MODE32 ioctl. Signed-off-by:
-
Boerge Struempfel authored
By default, the spi-imx controller pulls the mosi line high, whenever it is idle. This behaviour can be inverted per CS by setting the corresponding DATA_CTL bit in the config register of the controller. Also, since the controller mode-bits have to be touched anyways, the SPI_CPOL and SPI_CPHA are replaced by the combined SPI_MODE_X_MASK flag. Signed-off-by:
-
Boerge Struempfel authored
Some spi controller switch the mosi line to high, whenever they are idle. This may not be desired in all use cases. For example neopixel leds can get confused and flicker due to misinterpreting the idle state. Therefore, we introduce a new spi-mode bit, with which the idle behaviour can be overwritten on a per device basis. Signed-off-by:
-
Osama Muhammad authored
This patch fixes the error checking in spi-dw-core.c in debugfs_create_dir. The DebugFS kernel API is developed in a way that the caller can safely ignore the errors that occur during the creation of DebugFS nodes. Signed-off-by:
Osama Muhammad <osmtendev@gmail.com> Link: https://lore.kernel.org/r/20230520224025.14928-1-osmtendev@gmail.comSigned-off-by:
-
Lars-Peter Clausen authored
The `width_available` array is currently placed on the `f_ospi_supports_op_width()` function's stack. But the array is never modified. Make it `static const`. This makes the code slightly smaller and more efficient. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20230528195830.164669-3-lars@metafoo.deSigned-off-by:
-
Lars-Peter Clausen authored
Use `min_t` instead of `min` with casting the individual arguments. Signed-off-by:
-
Lars-Peter Clausen authored
Replace the combination of devm_clk_get_enable() plus clk_prepare_enable() with devm_clk_get_enabled(). Slightly reduces the amount of boilerplate code. Signed-off-by:
-
Uwe Kleine-König authored
Because of the earlier if (ret) return ret; ret is always zero at the end of mtk_spi_suspend(). Write it as explicit return 0 for slightly improved clearness. Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230530081648.2199419-4-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
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. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by:
-
