- 06 Jul, 2022 6 commits
-
-
Mark Brown authored
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>: This patch series addresses an issue in the spi-amd driver and, while there, performs some additional cleanups, like simplifying the error handling in the probe function and removing an unused struct member. For improving code readability, it also adds some kernel-doc comments.
-
Cristian Ciocaltea authored
Provide documentation comments in the kernel-doc format for enum amd_spi_versions and struct amd_spi. Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20220706100626.1234731-6-cristian.ciocaltea@collabora.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Cristian Ciocaltea authored
The io_base_addr member of struct amd_spi is not referenced anywhere in the driver implementation and there is no indication that it could be used in the future, hence drop it. Signed-off-by:
-
Cristian Ciocaltea authored
Simplify the error handling in probe function by switching from dev_err() to dev_err_probe(). Signed-off-by:
-
Cristian Ciocaltea authored
Make use of the devm variant of spi_alloc_master() in order to cleanup and simplify the error handling in the probe function by getting rid of the goto statements. Signed-off-by:
-
Cristian Ciocaltea authored
Enabling the SPI CS35L41 audio codec driver for Steam Deck [1] revealed a problem with the current AMD SPI controller driver implementation, consisting of an unrecoverable system hang. The issue can be prevented if we ensure the max transfer size and the max message size do not exceed the FIFO buffer size. According to the implementation of the downstream driver, the AMD SPI controller is not able to handle more than 70 bytes per transfer, which corresponds to the size of the FIFO buffer. Hence, let's fix this by setting the SPI limits mentioned above. [1] https://lore.kernel.org/r/20220621213819.262537-1-cristian.ciocaltea@collabora.comReported-by:
Anastasios Vacharakis <vacharakis@o2mail.de> Fixes: bbb336f3 ("spi: spi-amd: Add AMD SPI controller driver support") Signed-off-by:
-
- 04 Jul, 2022 2 commits
-
-
Krzysztof Kozlowski authored
During the conversion the bindings lost list of required properties. Fixes: c58db2ab ("spi: convert Xilinx Zynq UltraScale+ MPSoC GQSPI bindings to YAML") Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20220704130618.199231-2-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
During the conversion the bindings lost list of required properties. Fixes: aa796868 ("spi: convert Cadence SPI bindings to YAML") Signed-off-by:
-
- 01 Jul, 2022 1 commit
-
-
Conor Dooley authored
Most users of dw-apb-ssi use spi-{r,t}x-bus-width of 1, however the Canaan k210 is wired up for a width of 4. Quoting Serge: The modern DW APB SSI controllers of v.4.* and newer also support the enhanced SPI Modes too (Dual, Quad and Octal). Since the IP-core version is auto-detected at run-time there is no way to create a DT-schema correctly constraining the Rx/Tx SPI bus widths. /endquote As such, drop the restriction on only supporting a bus width of 1. Link: https://lore.kernel.org/all/20220620205654.g7fyipwytbww5757@mobilestation/Signed-off-by:Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Serge Semin <fancer.lancer@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Tested-by:
Niklas Cassel <niklas.cassel@wdc.com> Link: https://lore.kernel.org/r/20220629184343.3438856-5-mail@conchuod.ieSigned-off-by:
-
- 30 Jun, 2022 5 commits
-
-
Mark Brown authored
Merge series from David Jander <david@protonic.nl>: This series fixes some coding style issues. No functional change.
-
David Jander authored
Reported-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
David Jander <david@protonic.nl> Link: https://lore.kernel.org/r/20220629142519.3985486-4-david@protonic.nlSigned-off-by:
-
David Jander authored
Capitalize first word in comment where appropriate and add parentheses to function names. Reported-by:
-
David Jander authored
Reported-by:
-
Jarkko Nikula authored
Add support for LPSS SPI on Intel Meteor Lake-P. It has three controllers each having two chip selects. This squashes a fix from Ap, Kamal <kamal.ap@intel.com> fixing incorrect PCI ID of 3rd controller. Signed-off-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by:
-
- 29 Jun, 2022 6 commits
-
-
Mark Brown authored
Merge series from Chanho Park <chanho61.park@samsung.com>: Add to support Exynos Auto v9 SoC's spi. By supporting USI(Universal Serial Interface) mode, the SoC can support up to 12 spi ports. Thus, we need to increase MAX_SPI_PORTS from 6 to 12. The spi of the SoC can support loopback mode unlike previous exynos SoCs. To separate the feature, we need to add .has_loopback to the s3c64xx_spi_port_config. Furthermore, it uses 4 as the default internal clock divider. We also need to clk_div field of the structure and assign "2" as the default value to the existing SoC's port config. Device tree definitions of exynosautov9-spi will be added in separated patchset to include usi(i2c/uart/spi) nodes all together.
-
Mika Westerberg authored
Intel Meteor Lake-P has the same SPI serial flash controller as Alder Lake-P. Add Meteor Lake-P PCI ID to the driver list of supported devices. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20220629113403.79942-1-mika.westerberg@linux.intel.comSigned-off-by:
-
Chanho Park authored
Define "samsung,exynosautov9-spi" for Exynos Auto v9's spi. Reviewed-by:
Andi Shyti <andi@etezian.org> Signed-off-by:
Chanho Park <chanho61.park@samsung.com> Link: https://lore.kernel.org/r/20220629102304.65712-4-chanho61.park@samsung.comSigned-off-by:
-
Chanho Park authored
Add exynosautov9 spi port configuration. It supports up to 12 spis so MAX_SPI_PORTS should be increased from 6 to 12. It has DIV_4 as the default internal clock divider and an internal loopback mode to run a loopback test. Reviewed-by:
-
Chanho Park authored
Modern exynos SoCs such as Exynos Auto v9 have different internal clock divider, for example "4". To support this internal value, this adds clk_div of the s3c64xx_spi_port_config and assign "2" as the default value to existing s3c64xx_spi_port_config. Signed-off-by:
-
Chanho Park authored
Modern exynos SoCs can support self loopback mode via setting BIT(3) of MODE_CFG register. Previous SoCs don't have the bit so we need to add has_loopback field in the s3c64xx_spi_port_config. Exynos Auto v9 SoC has the bit and it will define the field to "true". When it is set, SPI_LOOP mode will be marked. Reviewed-by:
-
- 28 Jun, 2022 1 commit
-
-
Mark Brown authored
Merge series from David Jander <david@protonic.nl>: These patches optimize the spi_sync call for the common case that the worker thread is idle and the queue is empty. It also opens the possibility to potentially further optimize the async path also, since it doesn't need to take into account the direct sync path anymore. As an example for the performance gain, on an i.MX8MM SoC with a SPI CAN controller attached (MCP2518FD), the time the interrupt line stays active (which corresponds roughly with the time it takes to send 3 relatively short consecutive spi_sync messages) is reduced from 98us to only 72us by this patch. A note about message ordering: This patch series should not change the behavior of message ordering when coming from the same context. This means that if a client driver issues one or more spi_async() messages immediately followed by a spi_sync() message in the same context, it can still rely on these messages being sent out in the order they were fired.
-
- 27 Jun, 2022 18 commits
-
-
Chanho Park authored
This fixes the sequence of dma_release_channel. Since commit f52b03c7 ("spi: s3c64xx: requests spi-dma channel only during data transfer"), dma_release_channel has been located in the s3c64xx_spi_transfer_one but this makes invalid return of can_dma callback. __spi_unmap_msg will check whether the request is requested by dma or not via can_dma callback. When it is calling to check it, the channels will be already released at the end of s3c64xx_spi_transfer_one so the callback function will return always "false". So, they can't be unmapped from __spi_unmap_msg call. To fix this, we need to add unprepare_transfer_hardware callback and move the dma_release_channel from s3c64xx_spi_transfer_one to there. Fixes: f52b03c7 ("spi: s3c64xx: requests spi-dma channel only during data transfer") Signed-off-by:
-
Guo Mengqi authored
Add missing clk_disable_unprepare() in synquacer_spi_resume(). Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Guo Mengqi <guomengqi3@huawei.com> Link: https://lore.kernel.org/r/20220624005614.49434-1-guomengqi3@huawei.comSigned-off-by:
-
David Jander authored
There are only a few drivers that do not call spi_finalize_current_message() in the context of transfer_one_message(), and even for those cases the completion ctlr->cur_msg_completion is not needed always. The calls to complete() and wait_for_completion() each take a spin-lock, which is costly. This patch makes it possible to avoid those calls in the big majority of cases, by introducing two flags that with the help of ordering via barriers can avoid using the completion safely. In case of a race with the context calling spi_finalize_current_message(), the scheme errs on the safe side and takes the completion. The impact of this patch is worth the effort: On a i.MX8MM SoC, the time the SPI bus is idle between two consecutive calls to spi_sync(), is reduced from 19.6us to 16.8us... roughly 15%. Signed-off-by:
-
David Jander authored
This patch introduces a completion that is completed in spi_finalize_current_message() and waited for in __spi_pump_transfer_message(). This way all manipulation of ctlr->cur_msg is done with the io_mutex held and strictly ordered: __spi_pump_transfer_message() will not return until spi_finalize_current_message() is done using ctlr->cur_msg, and its calling context is only touching ctlr->cur_msg after returning. Due to this, we can safely drop the spin-locks around ctlr->cur_msg. Signed-off-by:
-
David Jander authored
Some drivers rely on this to point to the currently processed message, so set this here also. Signed-off-by:
-
David Jander authored
Now this flag is written entirely in the mutex, so no need for READ_ONCE Signed-off-by:
-
David Jander authored
The ctlr->idling flag is never checked now, so we don't need to set it either. Signed-off-by:
-
David Jander authored
Since the whole idling transition is locked by the io_mutex now, there is no need to check this flag anymore. Signed-off-by:
-
David Jander authored
Now that the idling flag is wholly behind the io_mutex, this broken piece of code can be safely removed. Signed-off-by:
-
David Jander authored
Signed-off-by:
-
David Jander authored
This way, the spi sync path does not need to deal with the idling transition. Signed-off-by:
-
David Jander authored
The interaction with the controller message queue and its corresponding auxiliary flags and variables requires the use of the queue_lock which is costly. Since spi_sync will transfer the complete message anyway, and not return until it is finished, there is no need to put the message into the queue if the queue is empty. This can save a lot of overhead. As an example of how significant this is, when using the MCP2518FD SPI CAN controller on a i.MX8MM SoC, the time during which the interrupt line stays active (during 3 relatively short spi_sync messages), is reduced from 98us to 72us by this patch. Signed-off-by:
-
David Jander authored
This enables the possibility to transfer a message that is not at the current tip of the async message queue. This is in preparation of the next patch(es) which enable spi_sync messages to skip the queue altogether. Signed-off-by:
-
Mark Brown authored
We deprecated open coding of the transfer queue back in 2017 so it's high time we finished up converting drivers to use the standard message queue code. The mpc52xx-psc driver is fairly straightforward so convert to use transfer_one_message(), it looks like the driver would be a good fit for transfer_one() with a little bit of updating but this smaller change seems safer. The driver seems like a good candidate for transfer_one() but the chip select function is actually doing rather more than just updating the chip select and both transfer_one() and transfer_one_message() are current APIs so leave that refactoring for another day, ideally by someone with the hardware. Signed-off-by:
-
Mark Brown authored
We deprecated open coding of the transfer queue back in 2017 so it's high time we finished up converting drivers to use the standard message queue code. The SH driver is fairly straightforward so convert to use transfer_one_message(), it looks like the driver would be a good fit for transfer_one() with a little bit of updating but this smaller change seems safer. I'm not actually clear how the driver worked robustly previously, it clears SSA and CR1 when queueing a transfer which looks like it would interfere with any running transfer. This clearing has been moved to the start of the message transfer function. I'm also unclear how exactly the chip select is managed with this driver. Signed-off-by:
-
Krzysztof Kozlowski authored
Document samsung,exynos4210-spi compatible which is already used on several Exynos SoCs. Signed-off-by:
-
Serge Semin authored
Currently if the source DMA device isn't ready to provide the channels capable of the SPI DMA transfers, the DW SSI controller will be registered with no DMA support. It isn't right since all what the driver needs to do is to postpone the probe procedure until the DMA device is ready. Let's fix that in the framework of the DWC SSI generic DMA implementation. First we need to use the dma_request_chan() method instead of the dma_request_slave_channel() function, because the later one is deprecated and most importantly doesn't return the failure cause but the NULL-pointer. Second we need to stop the DW SSI controller probe procedure if the -EPROBE_DEFER error is returned on the DMA initialization. The procedure will resume later when the channels are ready to be requested. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by:
-
Krzysztof Kozlowski authored
All struct s3c64xx_spi_port_config should be const. Fixes: 4ebb15a1 ("spi: s3c64xx: Add spi port configuration for Tesla FSD SoC") Signed-off-by:
-
- 23 Jun, 2022 1 commit
-
-
Eddie James authored
Only timeout after at least one iteration of checking the status registers. In addition, increase the transfer timeout to 1 second. Signed-off-by:
Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20220623140547.71762-1-eajames@linux.ibm.comSigned-off-by:
-
