aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-sqlite.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2020-10-08spi: dw: Explicitly de-assert CS on SPI transfer completionSerge Semin1-1/+1
By design of the currently available native set_cs callback, the CS de-assertion will be done only if it's required by the corresponding controller capability. But in order to pre-fill the Tx FIFO buffer with data during the SPI memory ops execution the SER register needs to be left cleared before that. We'll also need a way to explicitly set and clear the corresponding CS bit at a certain moment of the operation. Let's alter the set_cs function then to also de-activate the CS, when it's required. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-15-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: De-assert chip-select on resetSerge Semin1-3/+4
SPI memory operations implementation will require to have the CS register cleared before executing the operation in order not to have the transmission automatically started prior the Tx FIFO is pre-initialized. Let's clear the register then on explicit controller reset to fulfil the requirements in case of an error or having the CS left set by a bootloader or another software. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-14-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Discard chip enabling on DMA setup errorSerge Semin1-3/+1
It's pointless to enable the chip back if the DMA setup procedure fails, since we'll disable it on the next transfer anyway. For the same reason We don't do that in case of a failure detected in any other methods called from the transfer_one() method. While at it consider any non-zero value returned from the dma_setup callback to be erroneous as it's supposed to be in the kernel. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-13-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Unmask IRQs after enabling the chipSerge Semin1-2/+2
It's theoretically erroneous to enable IRQ before the chip is turned on. If IRQ handler gets executed before the chip is enabled, then any data written to the Tx FIFO will be just ignored. I say "theoretically" because we haven't noticed any problem with that, but let's fix it anyway just in case... Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-12-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Perform IRQ setup in a dedicated functionSerge Semin1-18/+23
In order to make the transfer_one() callback method more readable and for unification with the DMA-based transfer, let's detach the IRQ setup procedure into a dedicated function. While at it rename the IRQ-based transfer handler function to be dw_spi-prefixe and looking more like the DMA-related one. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-11-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Refactor IRQ-based SPI transfer procedureSerge Semin1-9/+24
Current IRQ-based SPI transfer execution procedure doesn't work well at the final stage of the execution. If all the Tx data is sent out (written to the Tx FIFO) but there is some data left to receive, the Tx FIFO Empty IRQ will constantly happen until all of the requested inbound data is received. Though for a short period of time, but it will make the system less responsive. In order to fix that let's refactor the SPI transfer execution procedure by taking the Rx FIFO Full IRQ into account. We'll read and write SPI transfer data each time the IRQ happens as before. If all the outbound data is sent out, we'll disable the Tx FIFO Empty IRQ. If there is still some data to receive, we'll adjust the Rx FIFO Threshold level, so the next IRQ would be raised at the moment of all incoming data being available in the Rx FIFO. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-10-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Refactor data IO procedureSerge Semin2-23/+19
The Tx and Rx data write/read procedure can be significantly simplified by using Tx/Rx transfer lengths instead of the end pointers. By having the Tx/Rx data leftover lengths (in the number of transfer words) we can get rid of all subtraction and division operations utilized here and there in the tx_max(), rx_max(), dw_writer() and dw_reader() methods. Such modification will not only give us the more optimized IO procedures, but will make the data IO methods much more readable than before. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-9-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Add DW SPI controller config structureSerge Semin2-12/+27
DW APB SSI controller can be used by the two SPI core interfaces: traditional SPI transfers and SPI memory operations. The controller needs to be accordingly configured at runtime when the corresponding operations are executed. In order to do that for the both interfaces from a single function we introduce a new data wrapper for the transfer mode, data width, number of data frames (for the automatic data transfer) and the bus frequency. It will be used by the update_config() method to tune the DW APB SSI up. The update_config() method is made exported to be used not only by the DW SPI core driver, but by the glue layer drivers too. This will be required in a coming further commit. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-8-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Update Rx sample delay in the config functionSerge Semin1-7/+6
Rx sample delay can be SPI device specific, and should be synchronously initialized with the rest of the communication and peripheral device related controller setups. So let's move the Rx-sample delay setup into the DW APB SSI configuration update method. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-7-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Simplify the SPI bus speed config procedureSerge Semin1-13/+10
The code currently responsible for the SPI communication speed setting up is a bit messy. Most likely for some historical reason the bus frequency is saved in the peripheral chip private data. It's pointless now since the custom communication speed is a SPI-transfer-specific thing and only if there is no SPI transfer data specified (like during the SPI memory operations) it can be taken from the SPI device structure. But even in the later case there is no point in having the clock divider and the SPI bus frequency saved in the chip data, because the controller can be used for both SPI-transfer-based and SPI-transfer-less communications. From software point of view keeping the current clock divider in an SPI-device specific storage may give a small performance gain (to avoid sometimes a round-up division), but in comparison to the total SPI transfer time it just doesn't worth saving a few CPU cycles in comparison to the total SPI transfer time while having the harder to read code. The only optimization, which could worth preserving in the code is to avoid unnecessary DW SPI controller registers update if it's possible. So to speak let's simplify the SPI communication speed update procedure by removing the clock-related fields from the peripheral chip data and update the DW SPI clock divider only if it's really changed. The later change is reached by keeping the effective SPI bus speed in the internal DW SPI private data. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-6-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Update SPI bus speed in a config functionSerge Semin1-14/+14
The SPI bus speed update functionality will be useful in another parts of the driver too (like to implement the SPI memory operations and from the DW SPI glue layers). Let's move it to the update_cr0() method then and since the later is now updating not only the CTRLR0 register alter its prototype to have a generic function name not related to CR0. Leave the too long line with the chip->clk_div setting as is for now, since it's going to be changed later anyway. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-5-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Detach SPI device specific CR0 config methodSerge Semin1-13/+30
Indeed there is no point in detecting the SPI peripheral device parameters and initializing the CR0 register fields each time an SPI transfer is executed. Instead let's define a dedicated CR0 chip-data member, which will be initialized in accordance with the SPI device settings at the moment of setting it up. By doing so we'll finally make the SPI device chip_data serving as it's supposed to - to preserve the SPI device specific DW SPI configuration. See spi-fsl-dspi.c, spi-pl022.c, spi-pxa2xx.c drivers for example of the way the chip data is utilized. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Add DWC SSI capabilitySerge Semin4-75/+40
Currently DWC SSI core is supported by means of setting up the core-specific update_cr0() callback. It isn't suitable for multiple reasons. First of all having exported several methods doing the same thing but for different chips makes the code harder to maintain. Secondly the spi-dw-core driver exports the methods, then the spi-dw-mmio driver sets the private data callback with one of them so to be called by the core driver again. That makes the code logic too complicated. Thirdly using callbacks for just updating the CR0 register is problematic, since in case if the register needed to be updated from different parts of the code, we'd have to create another callback (for instance the SPI device-specific parameters don't need to be calculated each time the SPI transfer is submitted, so it's better to pre-calculate the CR0 data at the SPI-device setup stage). So keeping all the above in mind let's discard the update_cr0() callbacks, define a generic and static dw_spi_update_cr0() method and create the DW_SPI_CAP_DWC_SSI capability, which when enabled would activate the alternative CR0 register layout. While at it add the comments to the code path of the normal DW APB SSI controller setup to make the dw_spi_update_cr0() method looking coherent. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08spi: dw: Use an explicit set_cs assignmentSerge Semin1-4/+4
Simplify the dw_spi_add_host() method a bit by replacing the currently implemented default set_cs callback setting up and later having it overwritten by a custom function with direct if-else-based callback assignment. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-06spi: spi-mtk-nor: Add power management supportIkjoon Jang1-22/+76
This patch adds dev_pm_ops to mtk-nor to support suspend/resume, auto suspend delay is set to -1 by default. Accessing registers are only permitted after its clock is enabled to deal with unknown state of operating clk at probe time. Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Link: https://lore.kernel.org/r/20201006155010.v5.4.I68983b582d949a91866163bab588ff3c2a0d0275@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-06spi: spi-mtk-nor: support 36bit dma addressingIkjoon Jang1-1/+20
This patch enables 36bit dma address support to spi-mtk-nor. Currently this is enabled only for mt8192-nor. Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Link: https://lore.kernel.org/r/20201006155010.v5.3.Id1cb208392928afc7ceed4de06924243c7858cd0@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-06spi: spi-mtk-nor: use dma_alloc_coherent() for bounce bufferIkjoon Jang1-42/+52
Use dma_alloc_coherent() for bounce buffer instead of kmalloc() to make sure the bounce buffer to be allocated within its DMAable range. Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Link: https://lore.kernel.org/r/20201006155010.v5.2.I06cb65401ab5ad63ea30c4788d26633928d80f38@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-06dt-bindings: spi: add mt8192-nor compatible stringIkjoon Jang1-0/+1
Add MT8192 spi-nor controller support. Signed-off-by: Ikjoon Jang <ikjn@chromium.org> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201006155010.v5.1.I4cd089ef1fe576535c6b6e4f1778eaab1c4441cf@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-05spi: renesas,sh-msiof: Add r8a77961 supportGeert Uytterhoeven1-0/+1
Document R-Car M3-W+ (R8A77961) SoC bindings. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201005112549.22222-1-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-02spi: spi-s3c64xx: Turn on interrupts upon resumeŁukasz Stelmach1-0/+4
s3c64xx_spi_hwinit() disables interrupts. In s3c64xx_spi_probe() after calling s3c64xx_spi_hwinit() they are enabled with the following call. Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> Link: https://lore.kernel.org/r/20201002122243.26849-10-l.stelmach@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-02spi: spi-s3c64xx: Increase transfer timeoutŁukasz Stelmach1-1/+2
Increase timeout by 30 ms for some wiggle room and set the minimum value to 100 ms. This ensures a non-zero value for short transfers which may take less than 1 ms. The timeout value does not affect performance because it is used with a completion. Similar formula is used in other drivers e.g. sun4i, sun6i. Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> Link: https://lore.kernel.org/r/20201002122243.26849-9-l.stelmach@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-02spi: spi-s3c64xx: Ensure cur_speed holds actual clock valueŁukasz Stelmach1-0/+1
Make sure the cur_speed value used in s3c64xx_enable_datapath() to configure DMA channel and in s3c64xx_wait_for_*() to calculate the transfer timeout is set to the actual value of (half) the clock speed. Don't change non-CMU case, because no frequency calculation errors have been reported. Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Suggested-by: Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> Link: https://lore.kernel.org/r/20201002122243.26849-8-l.stelmach@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-02spi: spi-s3c64xx: Fix doc comment for struct s3c64xx_spi_driver_dataŁukasz Stelmach1-4/+1
Remove descriptions for non-existent fields and fix indentation. Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> Link: https://lore.kernel.org/r/20201002122243.26849-7-l.stelmach@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-02spi: spi-s3c64xx: Rename S3C64XX_SPI_SLAVE_* to S3C64XX_SPI_CS_*Łukasz Stelmach1-13/+13
Rename S3C64XX_SPI_SLAVE_* to S3C64XX_SPI_CS_* to match documentation. Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201002122243.26849-6-l.stelmach@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-02spi: spi-s3c64xx: Report more information when errors occurŁukasz Stelmach1-4/+15
Report amount of pending data when a transfer stops due to errors. Report if DMA was used to transfer data and print the status code. Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> Link: https://lore.kernel.org/r/20201002122243.26849-5-l.stelmach@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-02spi: spi-s3c64xx: Check return valuesŁukasz Stelmach1-9/+41
Check return values in prepare_dma() and s3c64xx_spi_config() and propagate errors upwards. Fixes: 788437273fa8 ("spi: s3c64xx: move to generic dmaengine API") Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> Link: https://lore.kernel.org/r/20201002122243.26849-4-l.stelmach@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-02spi: spi-s3s64xx: Add S3C64XX_SPI_QUIRK_CS_AUTO for Exynos3250Łukasz Stelmach1-0/+1
Fix issues with DMA transfers bigger than 512 bytes on Exynos3250. Without the patches such transfers fail. The vendor kernel for ARTIK5 handles CS in a simmilar way. Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201002122243.26849-3-l.stelmach@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-02spi: spi-s3c64xx: swap s3c64xx_spi_set_cs() and s3c64xx_enable_datapath()Łukasz Stelmach1-2/+2
Fix issues with DMA transfers bigger than 512 bytes on Exynos3250. Without the patches such transfers fail to complete. This solution to the problem is found in the vendor kernel for ARTIK5 boards based on Exynos3250. Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com> Link: https://lore.kernel.org/r/20201002122243.26849-2-l.stelmach@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01spi: spi-stm32: remove redundant irqsave and irqrestore in hardIRQBarry Song1-5/+4
Running in hardIRQ, disabling IRQ is redundant. Signed-off-by: Barry Song <song.bao.hua@hisilicon.com> Link: https://lore.kernel.org/r/20200926001616.21292-2-song.bao.hua@hisilicon.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01spi: spi-tegra20-sflash: remove redundant irqsave and irqrestore in hardIRQBarry Song1-3/+2
Running in hardIRQ, disabling IRQ is redundant. Signed-off-by: Barry Song <song.bao.hua@hisilicon.com> Link: https://lore.kernel.org/r/20200926001616.21292-1-song.bao.hua@hisilicon.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01spi: atmel: Exposing effective spi speedThomas Kopp1-0/+1
This patch implements the reporting of the effectively used speed_hz for the transfer by setting xfer->effective_speed_hz. See the following patch, which adds this feature to the SPI core for more information: commit 5d7e2b5ed585 ("spi: core: allow reporting the effectivly used speed_hz for a transfer") Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200921071036.2091-1-thomas.kopp@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01spi: spi-mtk-nor: fix op checks in supports_opChuanhong Guo1-12/+9
commit a59b2c7c56bf7 ("spi: spi-mtk-nor: support standard spi properties") tries to inverse the logic of supports_op when adding spi_mem_default_supports_op check, but it didn't get it done properly. There are two regressions introduced by this commit: 1. reading ops supported by program mode is rejected. 2. all ops with special controller routines are incorrectly further checked against program mode. This commits inverses the logic back: 1. check spi_mem_default_supports_op and reject unsupported ops first. 2. return true for ops with special controller routines. 3. check the left ops against controller program mode. Fixes: a59b2c7c56bf7 ("spi: spi-mtk-nor: support standard spi properties") Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200924152730.733243-4-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01spi: spi-mtk-nor: add helper for checking prg mode opsChuanhong Guo1-7/+69
op checking/resizing logic for the newly added mtk_nor_spi_mem_prg is more complicated. Add two helper functions for them: mtk_nor_match_prg: check whether an op is supported by prg mode. mtk_nor_adj_prg_size: adjust data size for mtk_nor_spi_mem_prg. mtk_nor_match_prg isn't called yet because supports_op is currently broken. It'll be used in the next fix commit. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200924152730.733243-3-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-01spi: spi-mtk-nor: make use of full capability of prg modeChuanhong Guo1-2/+80
"program" mode on this controller can trigger up to 56 bits of data shifting. During the operation, data in PRGDATA[0-5] will be shifted out from MOSI, and data from MISO will be continuously filling SHREG[0-9]. Currently this mode is used to implement transfer_one_message for 6-byte full-duplex transfer, but it can execute a transfer for up-to 7 bytes as long as the last byte is read only. transfer_one_message is expected to perform full-duplex transfer, instead of transfer with specific format. mtk_nor_spi_mem_prg is added here to use this extra byte. Newer version of this controller can trigger longer data shifting with shift bytes more than PRGDATA_MAX + SHREG_MAX. This patch is implemented with that in mind and it checks against both SHREG_MAX and PRG_CNT_MAX for future support of new controllers. Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200924152730.733243-2-gch981213@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: spi-dw: Remove extraneous lockingSerge Semin2-13/+2
There is no point in having the commit 19b61392c5a8 ("spi: spi-dw: Add lock protect dw_spi rx/tx to prevent concurrent calls") applied. The commit author made an assumption that the problem with the rx data mismatch was due to the lack of the data protection. While most likely it was caused by the lack of the memory barrier. So having the commit bfda044533b2 ("spi: dw: use "smp_mb()" to avoid sending spi data error") applied would be enough to fix the problem. Indeed the spin unlock operation makes sure each memory operation issued before the release will be completed before it's completed. In other words it works as an implicit one way memory barrier. So having both smp_mb() and the spin_unlock_irqrestore() here is just redundant. One of them would be enough. It's better to leave the smp_mb() since the Tx/Rx buffers consistency is provided by the data transfer algorithm implementation: first we initialize the buffers pointers, then make sure the assignments are visible by the other CPUs by calling the smp_mb(), only after that enable the interrupt, which handler uses the buffers. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-5-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw: Add KeemBay Master capabilitySerge Semin3-17/+15
In a further commit we'll have to get rid of the update_cr0() callback and define a DW SSI capability instead. Since Keem Bay master/slave functionality is controller by the CTRL0 register bitfield, we need to first move the master mode selection into the internal corresponding update_cr0 method, which would be activated by means of the dedicated DW_SPI_CAP_KEEMBAY_MST capability setup. Note this will be also useful if the driver will be ever altered to support the DW SPI slave interface. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-11-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw: Convert CS-override to DW SPI capabilitiesSerge Semin3-4/+9
There are several vendor-specific versions of the DW SPI controllers, each of which may have some peculiarities with respect to the original IP-core. Seeing it has already caused adding flags and a callback into the DW SPI private data, let's introduce a generic capabilities interface to tune the generic DW SPI controller driver up in accordance with the particular controller specifics. It's done by converting a simple Alpine-specific CS-override capability into the DW SPI controller capability activated by setting the DW_SPI_CAP_CS_OVERRIDE flag. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-10-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw: Discard DW SSI chip type storagesSerge Semin2-5/+2
Keeping SPI peripheral devices type is pointless since first it hasn't been functionally utilized by any of the client drivers/code and second it won't work for Microwire type at the very least. Moreover there is no point in setting up the type by means of the chip-data in the modern kernel. The peripheral devices with specific interface type need to be detected in order to activate the corresponding frame format. It most likely will require some peripheral device specific DT property or whatever to find out the interface protocol. So let's remove the serial interface type fields from the DW APB SSI controller and the SPI peripheral device private data. Note we'll preserve the explicit SSI_MOTO_SPI interface type setting up to signify the only currently supported interface protocol. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-9-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw: Use relaxed IO-methods to access FIFOsSerge Semin1-14/+4
In accordance with [1] the relaxed methods are guaranteed to be ordered with respect to other accesses from the same CPU thread to the same peripheral. This is what we need during the data read/write from/to the controller FIFOs being executed within a single IRQ handler or a kernel task. Such optimization shall significantly speed the data reader and writer up. For instance, the relaxed IO-accessors utilization on Baikal-T1 lets the driver to support the SPI memory operations with bus frequency three-fold faster than if normal IO-accessors would be used. [1] "LINUX KERNEL MEMORY BARRIERS", Documentation/memory-barriers.txt, Section "KERNEL I/O BARRIER EFFECTS" Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-8-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw: Disable all IRQs when controller is unusedSerge Semin1-5/+5
It's a good practice to disable all IRQs if a device is fully unused. In our case it is supposed to be done before requesting the IRQ and after the last byte of an SPI transfer is received. In the former case it's required to prevent the IRQ handler invocation before the driver data is fully initialized (which may happen if the IRQs status has been left uncleared before the device is probed). So we just moved the spi_hw_init() method invocation to the earlier stage before requesting the IRQ. In the later case there is just no point in having any of the IRQs enabled between SPI transfers and when there is no SPI message currently being processed. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-7-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw: Clear IRQ status on DW SPI controller resetSerge Semin1-3/+4
It turns out the IRQ status isn't cleared after switching the controller off and getting it back on, which may cause raising false error interrupts if controller has been unsuccessfully used by, for instance, a bootloader before the driver is loaded. Let's explicitly clear the interrupts status in the dedicated controller reset method. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-6-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw: Initialize n_bytes before the memory barrierSerge Semin1-1/+1
Since n_bytes field of the DW SPI private data is also utilized by the IRQ handler, we need to make sure it' initialization is done before the memory barrier. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw: Discard IRQ threshold macroSerge Semin1-3/+0
The macro has been unused since a half of FIFO length was defined to be a marker of the IRQ. Let's remove it definition. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw-dma: Add one-by-one SG list entries transferSerge Semin2-1/+137
In case if at least one of the requested DMA engine channels doesn't support the hardware accelerated SG list entries traverse, the DMA driver will most likely work that around by performing the IRQ-based SG list entries resubmission. That might and will cause a problem if the DMA Tx channel is recharged and re-executed before the Rx DMA channel. Due to non-deterministic IRQ-handler execution latency the DMA Tx channel will start pushing data to the SPI bus before the Rx DMA channel is even reinitialized with the next inbound SG list entry. By doing so the DMA Tx channel will implicitly start filling the DW APB SSI Rx FIFO up, which while the DMA Rx channel being recharged and re-executed will eventually be overflown. In order to solve the problem we have to feed the DMA engine with SG list entries one-by-one. It shall keep the DW APB SSI Tx and Rx FIFOs synchronized and prevent the Rx FIFO overflow. Since in general the SPI tx_sg and rx_sg lists may have different number of entries of different lengths (though total length should match) we virtually split the SG-lists to the set of DMA transfers, which length is a minimum of the ordered SG-entries lengths. The solution described above is only executed if a full-duplex SPI transfer is requested and the DMA engine hasn't provided channels with hardware accelerated SG list traverse capability to handle both SG lists at once. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200920112322.24585-12-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw-dma: Pass exact data to the DMA submit and wait methodsSerge Semin1-18/+17
In order to use the DMA submission and waiting methods in both generic DMA-based SPI transfer and one-by-one DMA SG entries transmission functions, we need to modify the dw_spi_dma_wait() and dw_spi_dma_submit_tx()/dw_spi_dma_submit_rx() prototypes. So instead of getting the SPI transfer object as the second argument they must accept the exact data structure instances they imply to use. Those are the current transfer length and the SPI bus frequency in case of dw_spi_dma_wait(), and SG list together with number of list entries in case of the DMA Tx/Rx submission methods. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112322.24585-11-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw-dma: Move DMAC register cleanup to DMA transfer methodSerge Semin1-9/+8
DW APB SSI DMA driver doesn't use the native SPI core wait API since commit bdbdf0f06337 ("spi: dw: Locally wait for the DMA transfers completion"). Due to that the driver can now clear the DMAC register in a single place synchronously with the DMA transactions completion or failure. After that all the possible code paths are still covered: 1) DMA completion callbacks are executed in case if the corresponding DMA transactions are finished. When they are, one of them will eventually wake the SPI messages pump kernel thread and dw_spi_dma_transfer_all() method will clean the DMAC register as implied by this patch. 2) dma_stop is called when the SPI core detects an error either returned from the transfer_one() callback or set in the SPI message status field. Both types of errors will be noticed by the dw_spi_dma_transfer_all() method. 3) dma_exit is called when either SPI controller driver or the corresponding device is removed. In any case the SPI core will first flush the SPI messages pump kernel thread, so any pending or in-fly SPI transfers will be finished before that. Due to all of that let's simplify the DW APB SSI DMA driver a bit and move the DMAC register cleanup to a single place in the dw_spi_dma_transfer_all() method. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112322.24585-10-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw-dma: Detach DMA transfer into a dedicated methodSerge Semin1-2/+10
In order to add an alternative method of DMA-based SPI transfer first we need to detach the currently available one from the common code. Here we move the normal DMA-based SPI transfer execution functionality into a dedicated method. It will be utilized if either the DMA engine supports an unlimited number SG entries or Tx-only SPI transfer is requested. But currently just use it for any SPI transfer. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112322.24585-9-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw-dma: Remove DMA Tx-desc passing aroundSerge Semin1-17/+14
It's pointless to pass the Rx and Tx transfers DMA Tx-descriptors, since they are used in the Tx/Rx submit method only. Instead just return the submission status from these methods. This alteration will make the code less complex. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112322.24585-8-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw-dma: Check DMA Tx-desc submission statusSerge Semin1-2/+18
We suggest to add the dmaengine_submit() return value test for errors. It has been unnecessary while the driver was expected to be utilized in pair with DW DMAC. But since now the driver can be used with any DMA engine, it might be useful to track the errors on DMA submissions so not miss them and get into an unpredictable driver behaviour. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112322.24585-7-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-09-29spi: dw-dma: Move DMA transfers submission to the channels prep methodsSerge Semin1-10/+12
Indeed we can freely move the dmaengine_submit() method invocation and the Tx and Rx busy flag setting into the DMA Tx/Rx prepare methods. Since the Tx/Rx preparation method is now mainly used for the DMA transfers submission, here we suggest to rename it to have the _submit_{r,t}x suffix instead. By having this alteration applied first we implement another code preparation before adding the one-by-one DMA SG entries transmission, second we now have the dma_async_tx_descriptor descriptor used locally only in the new DMA transfers submission methods (this will be cleaned up a bit later), third we make the generic transfer method more readable, where now the functionality of submission, execution and wait procedures is transparently split up instead of having a preparation, intermixed submission/execution and wait procedures. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112322.24585-6-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.