OpenCloudOS-Kernel/drivers/spi/spi-dw-core.c

1013 lines
27 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-only
/*
* Designware SPI core controller driver (refer pxa2xx_spi.c)
*
* Copyright (c) 2009, Intel Corporation.
*/
#include <linux/bitfield.h>
#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
#include <linux/module.h>
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
#include <linux/preempt.h>
#include <linux/highmem.h>
#include <linux/delay.h>
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
#include <linux/slab.h>
#include <linux/spi/spi.h>
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
#include <linux/spi/spi-mem.h>
#include <linux/string.h>
#include <linux/of.h>
#include "spi-dw.h"
#ifdef CONFIG_DEBUG_FS
#include <linux/debugfs.h>
#endif
/* Slave spi_device related */
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
struct dw_spi_chip_data {
u32 cr0;
u32 rx_sample_dly; /* RX sample delay */
};
#ifdef CONFIG_DEBUG_FS
#define DW_SPI_DBGFS_REG(_name, _off) \
{ \
.name = _name, \
.offset = _off, \
}
static const struct debugfs_reg32 dw_spi_dbgfs_regs[] = {
DW_SPI_DBGFS_REG("CTRLR0", DW_SPI_CTRLR0),
DW_SPI_DBGFS_REG("CTRLR1", DW_SPI_CTRLR1),
DW_SPI_DBGFS_REG("SSIENR", DW_SPI_SSIENR),
DW_SPI_DBGFS_REG("SER", DW_SPI_SER),
DW_SPI_DBGFS_REG("BAUDR", DW_SPI_BAUDR),
DW_SPI_DBGFS_REG("TXFTLR", DW_SPI_TXFTLR),
DW_SPI_DBGFS_REG("RXFTLR", DW_SPI_RXFTLR),
DW_SPI_DBGFS_REG("TXFLR", DW_SPI_TXFLR),
DW_SPI_DBGFS_REG("RXFLR", DW_SPI_RXFLR),
DW_SPI_DBGFS_REG("SR", DW_SPI_SR),
DW_SPI_DBGFS_REG("IMR", DW_SPI_IMR),
DW_SPI_DBGFS_REG("ISR", DW_SPI_ISR),
DW_SPI_DBGFS_REG("DMACR", DW_SPI_DMACR),
DW_SPI_DBGFS_REG("DMATDLR", DW_SPI_DMATDLR),
DW_SPI_DBGFS_REG("DMARDLR", DW_SPI_DMARDLR),
DW_SPI_DBGFS_REG("RX_SAMPLE_DLY", DW_SPI_RX_SAMPLE_DLY),
};
static void dw_spi_debugfs_init(struct dw_spi *dws)
{
char name[32];
snprintf(name, 32, "dw_spi%d", dws->master->bus_num);
dws->debugfs = debugfs_create_dir(name, NULL);
dws->regset.regs = dw_spi_dbgfs_regs;
dws->regset.nregs = ARRAY_SIZE(dw_spi_dbgfs_regs);
dws->regset.base = dws->regs;
debugfs_create_regset32("registers", 0400, dws->debugfs, &dws->regset);
}
static void dw_spi_debugfs_remove(struct dw_spi *dws)
{
debugfs_remove_recursive(dws->debugfs);
}
#else
static inline void dw_spi_debugfs_init(struct dw_spi *dws)
{
}
static inline void dw_spi_debugfs_remove(struct dw_spi *dws)
{
}
#endif /* CONFIG_DEBUG_FS */
void dw_spi_set_cs(struct spi_device *spi, bool enable)
{
struct dw_spi *dws = spi_controller_get_devdata(spi->controller);
spi: dw: Fix native CS being unset Commit 6e0a32d6f376 ("spi: dw: Fix default polarity of native chipselect") attempted to fix the problem when GPIO active-high chip-select is utilized to communicate with some SPI slave. It fixed the problem, but broke the normal native CS support. At the same time the reversion commit ada9e3fcc175 ("spi: dw: Correct handling of native chipselect") didn't solve the problem either, since it just inverted the set_cs() polarity perception without taking into account that CS-high might be applicable. Here is what is done to finally fix the problem. DW SPI controller demands any native CS being set in order to proceed with data transfer. So in order to activate the SPI communications we must set any bit in the Slave Select DW SPI controller register no matter whether the platform requests the GPIO- or native CS. Preferably it should be the bit corresponding to the SPI slave CS number. But currently the dw_spi_set_cs() method activates the chip-select only if the second argument is false. Since the second argument of the set_cs callback is expected to be a boolean with "is-high" semantics (actual chip-select pin state value), the bit in the DW SPI Slave Select register will be set only if SPI core requests the driver to set the CS in the low state. So this will work for active-low GPIO-based CS case, and won't work for active-high CS setting the bit when SPI core actually needs to deactivate the CS. This commit fixes the problem for all described cases. So no matter whether an SPI slave needs GPIO- or native-based CS with active-high or low signal the corresponding bit will be set in SER. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Fixes: ada9e3fcc175 ("spi: dw: Correct handling of native chipselect") Fixes: 6e0a32d6f376 ("spi: dw: Fix default polarity of native chipselect") Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200515104758.6934-5-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-15 18:47:43 +08:00
bool cs_high = !!(spi->mode & SPI_CS_HIGH);
spi: dw: Fix native CS being unset Commit 6e0a32d6f376 ("spi: dw: Fix default polarity of native chipselect") attempted to fix the problem when GPIO active-high chip-select is utilized to communicate with some SPI slave. It fixed the problem, but broke the normal native CS support. At the same time the reversion commit ada9e3fcc175 ("spi: dw: Correct handling of native chipselect") didn't solve the problem either, since it just inverted the set_cs() polarity perception without taking into account that CS-high might be applicable. Here is what is done to finally fix the problem. DW SPI controller demands any native CS being set in order to proceed with data transfer. So in order to activate the SPI communications we must set any bit in the Slave Select DW SPI controller register no matter whether the platform requests the GPIO- or native CS. Preferably it should be the bit corresponding to the SPI slave CS number. But currently the dw_spi_set_cs() method activates the chip-select only if the second argument is false. Since the second argument of the set_cs callback is expected to be a boolean with "is-high" semantics (actual chip-select pin state value), the bit in the DW SPI Slave Select register will be set only if SPI core requests the driver to set the CS in the low state. So this will work for active-low GPIO-based CS case, and won't work for active-high CS setting the bit when SPI core actually needs to deactivate the CS. This commit fixes the problem for all described cases. So no matter whether an SPI slave needs GPIO- or native-based CS with active-high or low signal the corresponding bit will be set in SER. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Fixes: ada9e3fcc175 ("spi: dw: Correct handling of native chipselect") Fixes: 6e0a32d6f376 ("spi: dw: Fix default polarity of native chipselect") Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200515104758.6934-5-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-15 18:47:43 +08:00
/*
* DW SPI controller demands any native CS being set in order to
* proceed with data transfer. So in order to activate the SPI
* communications we must set a corresponding bit in the Slave
* Enable register no matter whether the SPI core is configured to
* support active-high or active-low CS level.
*/
if (cs_high == enable)
dw_writel(dws, DW_SPI_SER, BIT(spi_get_chipselect(spi, 0)));
else
dw_writel(dws, DW_SPI_SER, 0);
}
EXPORT_SYMBOL_NS_GPL(dw_spi_set_cs, SPI_DW_CORE);
/* Return the max entries we can fill into tx fifo */
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
static inline u32 dw_spi_tx_max(struct dw_spi *dws)
{
u32 tx_room, rxtx_gap;
tx_room = dws->fifo_len - dw_readl(dws, DW_SPI_TXFLR);
/*
* Another concern is about the tx/rx mismatch, we
* though to use (dws->fifo_len - rxflr - txflr) as
* one maximum value for tx, but it doesn't cover the
* data which is out of tx/rx fifo and inside the
* shift registers. So a control from sw point of
* view is taken.
*/
rxtx_gap = dws->fifo_len - (dws->rx_len - dws->tx_len);
return min3((u32)dws->tx_len, tx_room, rxtx_gap);
}
/* Return the max entries we should read out of rx fifo */
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
static inline u32 dw_spi_rx_max(struct dw_spi *dws)
{
return min_t(u32, dws->rx_len, dw_readl(dws, DW_SPI_RXFLR));
}
static void dw_writer(struct dw_spi *dws)
{
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
u32 max = dw_spi_tx_max(dws);
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
u32 txw = 0;
while (max--) {
if (dws->tx) {
if (dws->n_bytes == 1)
txw = *(u8 *)(dws->tx);
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
else if (dws->n_bytes == 2)
txw = *(u16 *)(dws->tx);
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
else
txw = *(u32 *)(dws->tx);
dws->tx += dws->n_bytes;
}
dw_write_io_reg(dws, DW_SPI_DR, txw);
--dws->tx_len;
}
}
static void dw_reader(struct dw_spi *dws)
{
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
u32 max = dw_spi_rx_max(dws);
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
u32 rxw;
while (max--) {
rxw = dw_read_io_reg(dws, DW_SPI_DR);
if (dws->rx) {
if (dws->n_bytes == 1)
*(u8 *)(dws->rx) = rxw;
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
else if (dws->n_bytes == 2)
*(u16 *)(dws->rx) = rxw;
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
else
*(u32 *)(dws->rx) = rxw;
dws->rx += dws->n_bytes;
}
--dws->rx_len;
}
}
int dw_spi_check_status(struct dw_spi *dws, bool raw)
{
u32 irq_status;
int ret = 0;
if (raw)
irq_status = dw_readl(dws, DW_SPI_RISR);
else
irq_status = dw_readl(dws, DW_SPI_ISR);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
if (irq_status & DW_SPI_INT_RXOI) {
dev_err(&dws->master->dev, "RX FIFO overflow detected\n");
ret = -EIO;
}
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
if (irq_status & DW_SPI_INT_RXUI) {
dev_err(&dws->master->dev, "RX FIFO underflow detected\n");
ret = -EIO;
}
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
if (irq_status & DW_SPI_INT_TXOI) {
dev_err(&dws->master->dev, "TX FIFO overflow detected\n");
ret = -EIO;
}
/* Generically handle the erroneous situation */
if (ret) {
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_reset_chip(dws);
if (dws->master->cur_msg)
dws->master->cur_msg->status = ret;
}
return ret;
}
EXPORT_SYMBOL_NS_GPL(dw_spi_check_status, SPI_DW_CORE);
static irqreturn_t dw_spi_transfer_handler(struct dw_spi *dws)
{
u16 irq_status = dw_readl(dws, DW_SPI_ISR);
if (dw_spi_check_status(dws, false)) {
spi_finalize_current_transfer(dws->master);
return IRQ_HANDLED;
}
/*
* Read data from the Rx FIFO every time we've got a chance executing
* this method. If there is nothing left to receive, terminate the
* procedure. Otherwise adjust the Rx FIFO Threshold level if it's a
* final stage of the transfer. By doing so we'll get the next IRQ
* right when the leftover incoming data is received.
*/
dw_reader(dws);
if (!dws->rx_len) {
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_mask_intr(dws, 0xff);
spi_finalize_current_transfer(dws->master);
} else if (dws->rx_len <= dw_readl(dws, DW_SPI_RXFTLR)) {
dw_writel(dws, DW_SPI_RXFTLR, dws->rx_len - 1);
}
/*
* Send data out if Tx FIFO Empty IRQ is received. The IRQ will be
* disabled after the data transmission is finished so not to
* have the TXE IRQ flood at the final stage of the transfer.
*/
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
if (irq_status & DW_SPI_INT_TXEI) {
dw_writer(dws);
if (!dws->tx_len)
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_mask_intr(dws, DW_SPI_INT_TXEI);
}
return IRQ_HANDLED;
}
static irqreturn_t dw_spi_irq(int irq, void *dev_id)
{
struct spi_controller *master = dev_id;
struct dw_spi *dws = spi_controller_get_devdata(master);
u16 irq_status = dw_readl(dws, DW_SPI_ISR) & DW_SPI_INT_MASK;
if (!irq_status)
return IRQ_NONE;
if (!master->cur_msg) {
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_mask_intr(dws, 0xff);
return IRQ_HANDLED;
}
return dws->transfer_handler(dws);
}
static u32 dw_spi_prepare_cr0(struct dw_spi *dws, struct spi_device *spi)
{
u32 cr0 = 0;
if (dw_spi_ip_is(dws, PSSI)) {
2020-10-08 07:54:51 +08:00
/* CTRLR0[ 5: 4] Frame Format */
cr0 |= FIELD_PREP(DW_PSSI_CTRLR0_FRF_MASK, DW_SPI_CTRLR0_FRF_MOTO_SPI);
2020-10-08 07:54:51 +08:00
/*
* SPI mode (SCPOL|SCPH)
* CTRLR0[ 6] Serial Clock Phase
* CTRLR0[ 7] Serial Clock Polarity
*/
if (spi->mode & SPI_CPOL)
cr0 |= DW_PSSI_CTRLR0_SCPOL;
if (spi->mode & SPI_CPHA)
cr0 |= DW_PSSI_CTRLR0_SCPHA;
spi: dw: Add support for DesignWare DWC_ssi This patch adds initial support for DesignWare DWC_ssi soft IP. DWC_ssi is the enhanced version of DW_apb_ssi, which is currently supported by this driver. Their registers are same, but the bit fields of register CTRLR0 are different. DWC_ssi has additional features compared to DW_apb_ssi. Major enhancements in DWC_ssi are hyper bus protocol, boot mode support and advanced XIP support. DWC_ssi is an AHB slave device, whilst DW_apb_ssi is an APB slave device. Register offset DW_ssi DW_apb_ssi CTRLR0 0x00 0x00 CTRLR1 0x04 0x04 SSIENR 0x08 0x08 MWCR 0x0c 0x0c SER 0x10 0x10 BAUDR 0x14 0x14 TXFTLR 0x18 0x18 RXFTLR 0x1c 0x1c TXFLR 0x20 0x20 RXFLR 0x24 0x24 SR 0x28 0x28 IMR 0x2c 0x2c ISR 0x30 0x30 RISR 0x34 0x34 TXOICR 0x38 0x38 RXOICR 0x3c 0x3c RXUICR 0x40 0x40 MSTICR 0x44 0x44 ICR 0x48 0x48 DMACR 0x4c 0x4c DMATDLR 0x50 0x50 DMARDLR 0x54 0x54 IDR 0x58 0x58 SSI_VERSION_ID 0x5c 0x5c DRx (0 to 35) 0x60+i*0x4 0x60+i*0x4 RX_SAMPLE_DLY 0xf0 0xf0 SPI_CTRLR0 0xf4 0xf4 TXD_DRIVE_EDGE 0xf8 0xf8 XIP_MODE_BITS 0xfc RSVD Register configuration - CTRLR0 DW_ssi DW_apb_ssi SPI_HYPERBUS_EN bit[24] NONE SPI_FRF bit[23:22] bit[22:21] DFS_32 NONE bit[20:16] CFS bit[19:16] bit[15:12] SSTE bit[14] bit[24] SRL bit[13] bit[11] SLV_OE bit[12] bit[10] TMOD bit[11:10] bit[9:8] SCPOL | SPHA bit[9:8] bit[7:6] FRF bit[7:6] bit[5:4] DFS bit[4:0] bit[3:0] The documents used are [1] DW_apb_ssi_databook.pdf version 4.01a (2016.10a). [2] DWC_ssi_databook.pdf version 1.01a. Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200505130618.554-4-wan.ahmad.zainie.wan.mohamad@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-05 21:06:14 +08:00
2020-10-08 07:54:51 +08:00
/* CTRLR0[11] Shift Register Loop */
if (spi->mode & SPI_LOOP)
cr0 |= DW_PSSI_CTRLR0_SRL;
2020-10-08 07:54:51 +08:00
} else {
/* CTRLR0[ 7: 6] Frame Format */
cr0 |= FIELD_PREP(DW_HSSI_CTRLR0_FRF_MASK, DW_SPI_CTRLR0_FRF_MOTO_SPI);
spi: dw: Add support for DesignWare DWC_ssi This patch adds initial support for DesignWare DWC_ssi soft IP. DWC_ssi is the enhanced version of DW_apb_ssi, which is currently supported by this driver. Their registers are same, but the bit fields of register CTRLR0 are different. DWC_ssi has additional features compared to DW_apb_ssi. Major enhancements in DWC_ssi are hyper bus protocol, boot mode support and advanced XIP support. DWC_ssi is an AHB slave device, whilst DW_apb_ssi is an APB slave device. Register offset DW_ssi DW_apb_ssi CTRLR0 0x00 0x00 CTRLR1 0x04 0x04 SSIENR 0x08 0x08 MWCR 0x0c 0x0c SER 0x10 0x10 BAUDR 0x14 0x14 TXFTLR 0x18 0x18 RXFTLR 0x1c 0x1c TXFLR 0x20 0x20 RXFLR 0x24 0x24 SR 0x28 0x28 IMR 0x2c 0x2c ISR 0x30 0x30 RISR 0x34 0x34 TXOICR 0x38 0x38 RXOICR 0x3c 0x3c RXUICR 0x40 0x40 MSTICR 0x44 0x44 ICR 0x48 0x48 DMACR 0x4c 0x4c DMATDLR 0x50 0x50 DMARDLR 0x54 0x54 IDR 0x58 0x58 SSI_VERSION_ID 0x5c 0x5c DRx (0 to 35) 0x60+i*0x4 0x60+i*0x4 RX_SAMPLE_DLY 0xf0 0xf0 SPI_CTRLR0 0xf4 0xf4 TXD_DRIVE_EDGE 0xf8 0xf8 XIP_MODE_BITS 0xfc RSVD Register configuration - CTRLR0 DW_ssi DW_apb_ssi SPI_HYPERBUS_EN bit[24] NONE SPI_FRF bit[23:22] bit[22:21] DFS_32 NONE bit[20:16] CFS bit[19:16] bit[15:12] SSTE bit[14] bit[24] SRL bit[13] bit[11] SLV_OE bit[12] bit[10] TMOD bit[11:10] bit[9:8] SCPOL | SPHA bit[9:8] bit[7:6] FRF bit[7:6] bit[5:4] DFS bit[4:0] bit[3:0] The documents used are [1] DW_apb_ssi_databook.pdf version 4.01a (2016.10a). [2] DWC_ssi_databook.pdf version 1.01a. Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200505130618.554-4-wan.ahmad.zainie.wan.mohamad@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-05 21:06:14 +08:00
2020-10-08 07:54:51 +08:00
/*
* SPI mode (SCPOL|SCPH)
* CTRLR0[ 8] Serial Clock Phase
* CTRLR0[ 9] Serial Clock Polarity
*/
if (spi->mode & SPI_CPOL)
cr0 |= DW_HSSI_CTRLR0_SCPOL;
if (spi->mode & SPI_CPHA)
cr0 |= DW_HSSI_CTRLR0_SCPHA;
spi: dw: Add support for DesignWare DWC_ssi This patch adds initial support for DesignWare DWC_ssi soft IP. DWC_ssi is the enhanced version of DW_apb_ssi, which is currently supported by this driver. Their registers are same, but the bit fields of register CTRLR0 are different. DWC_ssi has additional features compared to DW_apb_ssi. Major enhancements in DWC_ssi are hyper bus protocol, boot mode support and advanced XIP support. DWC_ssi is an AHB slave device, whilst DW_apb_ssi is an APB slave device. Register offset DW_ssi DW_apb_ssi CTRLR0 0x00 0x00 CTRLR1 0x04 0x04 SSIENR 0x08 0x08 MWCR 0x0c 0x0c SER 0x10 0x10 BAUDR 0x14 0x14 TXFTLR 0x18 0x18 RXFTLR 0x1c 0x1c TXFLR 0x20 0x20 RXFLR 0x24 0x24 SR 0x28 0x28 IMR 0x2c 0x2c ISR 0x30 0x30 RISR 0x34 0x34 TXOICR 0x38 0x38 RXOICR 0x3c 0x3c RXUICR 0x40 0x40 MSTICR 0x44 0x44 ICR 0x48 0x48 DMACR 0x4c 0x4c DMATDLR 0x50 0x50 DMARDLR 0x54 0x54 IDR 0x58 0x58 SSI_VERSION_ID 0x5c 0x5c DRx (0 to 35) 0x60+i*0x4 0x60+i*0x4 RX_SAMPLE_DLY 0xf0 0xf0 SPI_CTRLR0 0xf4 0xf4 TXD_DRIVE_EDGE 0xf8 0xf8 XIP_MODE_BITS 0xfc RSVD Register configuration - CTRLR0 DW_ssi DW_apb_ssi SPI_HYPERBUS_EN bit[24] NONE SPI_FRF bit[23:22] bit[22:21] DFS_32 NONE bit[20:16] CFS bit[19:16] bit[15:12] SSTE bit[14] bit[24] SRL bit[13] bit[11] SLV_OE bit[12] bit[10] TMOD bit[11:10] bit[9:8] SCPOL | SPHA bit[9:8] bit[7:6] FRF bit[7:6] bit[5:4] DFS bit[4:0] bit[3:0] The documents used are [1] DW_apb_ssi_databook.pdf version 4.01a (2016.10a). [2] DWC_ssi_databook.pdf version 1.01a. Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200505130618.554-4-wan.ahmad.zainie.wan.mohamad@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-05 21:06:14 +08:00
2020-10-08 07:54:51 +08:00
/* CTRLR0[13] Shift Register Loop */
if (spi->mode & SPI_LOOP)
cr0 |= DW_HSSI_CTRLR0_SRL;
spi: dw: Add support for DesignWare DWC_ssi This patch adds initial support for DesignWare DWC_ssi soft IP. DWC_ssi is the enhanced version of DW_apb_ssi, which is currently supported by this driver. Their registers are same, but the bit fields of register CTRLR0 are different. DWC_ssi has additional features compared to DW_apb_ssi. Major enhancements in DWC_ssi are hyper bus protocol, boot mode support and advanced XIP support. DWC_ssi is an AHB slave device, whilst DW_apb_ssi is an APB slave device. Register offset DW_ssi DW_apb_ssi CTRLR0 0x00 0x00 CTRLR1 0x04 0x04 SSIENR 0x08 0x08 MWCR 0x0c 0x0c SER 0x10 0x10 BAUDR 0x14 0x14 TXFTLR 0x18 0x18 RXFTLR 0x1c 0x1c TXFLR 0x20 0x20 RXFLR 0x24 0x24 SR 0x28 0x28 IMR 0x2c 0x2c ISR 0x30 0x30 RISR 0x34 0x34 TXOICR 0x38 0x38 RXOICR 0x3c 0x3c RXUICR 0x40 0x40 MSTICR 0x44 0x44 ICR 0x48 0x48 DMACR 0x4c 0x4c DMATDLR 0x50 0x50 DMARDLR 0x54 0x54 IDR 0x58 0x58 SSI_VERSION_ID 0x5c 0x5c DRx (0 to 35) 0x60+i*0x4 0x60+i*0x4 RX_SAMPLE_DLY 0xf0 0xf0 SPI_CTRLR0 0xf4 0xf4 TXD_DRIVE_EDGE 0xf8 0xf8 XIP_MODE_BITS 0xfc RSVD Register configuration - CTRLR0 DW_ssi DW_apb_ssi SPI_HYPERBUS_EN bit[24] NONE SPI_FRF bit[23:22] bit[22:21] DFS_32 NONE bit[20:16] CFS bit[19:16] bit[15:12] SSTE bit[14] bit[24] SRL bit[13] bit[11] SLV_OE bit[12] bit[10] TMOD bit[11:10] bit[9:8] SCPOL | SPHA bit[9:8] bit[7:6] FRF bit[7:6] bit[5:4] DFS bit[4:0] bit[3:0] The documents used are [1] DW_apb_ssi_databook.pdf version 4.01a (2016.10a). [2] DWC_ssi_databook.pdf version 1.01a. Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200505130618.554-4-wan.ahmad.zainie.wan.mohamad@intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-05 21:06:14 +08:00
/* CTRLR0[31] MST */
if (dw_spi_ver_is_ge(dws, HSSI, 102A))
cr0 |= DW_HSSI_CTRLR0_MST;
2020-10-08 07:54:51 +08:00
}
return cr0;
}
void dw_spi_update_config(struct dw_spi *dws, struct spi_device *spi,
struct dw_spi_cfg *cfg)
{
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
struct dw_spi_chip_data *chip = spi_get_ctldata(spi);
u32 cr0 = chip->cr0;
spi: dw: Simplify the SPI bus speed config procedure 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-08 07:54:54 +08:00
u32 speed_hz;
u16 clk_div;
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
/* CTRLR0[ 4/3: 0] or CTRLR0[ 20: 16] Data Frame Size */
cr0 |= (cfg->dfs - 1) << dws->dfs_offset;
if (dw_spi_ip_is(dws, PSSI))
/* CTRLR0[ 9:8] Transfer Mode */
cr0 |= FIELD_PREP(DW_PSSI_CTRLR0_TMOD_MASK, cfg->tmode);
else
/* CTRLR0[11:10] Transfer Mode */
cr0 |= FIELD_PREP(DW_HSSI_CTRLR0_TMOD_MASK, cfg->tmode);
2020-10-08 07:54:51 +08:00
dw_writel(dws, DW_SPI_CTRLR0, cr0);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
if (cfg->tmode == DW_SPI_CTRLR0_TMOD_EPROMREAD ||
cfg->tmode == DW_SPI_CTRLR0_TMOD_RO)
dw_writel(dws, DW_SPI_CTRLR1, cfg->ndf ? cfg->ndf - 1 : 0);
spi: dw: Simplify the SPI bus speed config procedure 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-08 07:54:54 +08:00
/* Note DW APB SSI clock divider doesn't support odd numbers */
clk_div = (DIV_ROUND_UP(dws->max_freq, cfg->freq) + 1) & 0xfffe;
spi: dw: Simplify the SPI bus speed config procedure 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-08 07:54:54 +08:00
speed_hz = dws->max_freq / clk_div;
if (dws->current_freq != speed_hz) {
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_set_clk(dws, clk_div);
spi: dw: Simplify the SPI bus speed config procedure 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-08 07:54:54 +08:00
dws->current_freq = speed_hz;
}
/* Update RX sample delay if required */
if (dws->cur_rx_sample_dly != chip->rx_sample_dly) {
dw_writel(dws, DW_SPI_RX_SAMPLE_DLY, chip->rx_sample_dly);
dws->cur_rx_sample_dly = chip->rx_sample_dly;
}
}
EXPORT_SYMBOL_NS_GPL(dw_spi_update_config, SPI_DW_CORE);
static void dw_spi_irq_setup(struct dw_spi *dws)
{
u16 level;
u8 imask;
/*
* Originally Tx and Rx data lengths match. Rx FIFO Threshold level
* will be adjusted at the final stage of the IRQ-based SPI transfer
* execution so not to lose the leftover of the incoming data.
*/
level = min_t(unsigned int, dws->fifo_len / 2, dws->tx_len);
dw_writel(dws, DW_SPI_TXFTLR, level);
dw_writel(dws, DW_SPI_RXFTLR, level - 1);
dws->transfer_handler = dw_spi_transfer_handler;
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
imask = DW_SPI_INT_TXEI | DW_SPI_INT_TXOI |
DW_SPI_INT_RXUI | DW_SPI_INT_RXOI | DW_SPI_INT_RXFI;
dw_spi_umask_intr(dws, imask);
}
/*
* The iterative procedure of the poll-based transfer is simple: write as much
* as possible to the Tx FIFO, wait until the pending to receive data is ready
* to be read, read it from the Rx FIFO and check whether the performed
* procedure has been successful.
*
* Note this method the same way as the IRQ-based transfer won't work well for
* the SPI devices connected to the controller with native CS due to the
* automatic CS assertion/de-assertion.
*/
static int dw_spi_poll_transfer(struct dw_spi *dws,
struct spi_transfer *transfer)
{
struct spi_delay delay;
u16 nbits;
int ret;
delay.unit = SPI_DELAY_UNIT_SCK;
nbits = dws->n_bytes * BITS_PER_BYTE;
do {
dw_writer(dws);
delay.value = nbits * (dws->rx_len - dws->tx_len);
spi_delay_exec(&delay, transfer);
dw_reader(dws);
ret = dw_spi_check_status(dws, true);
if (ret)
return ret;
} while (dws->rx_len);
return 0;
}
static int dw_spi_transfer_one(struct spi_controller *master,
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
struct spi_device *spi,
struct spi_transfer *transfer)
{
struct dw_spi *dws = spi_controller_get_devdata(master);
struct dw_spi_cfg cfg = {
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
.tmode = DW_SPI_CTRLR0_TMOD_TR,
.dfs = transfer->bits_per_word,
.freq = transfer->speed_hz,
};
int ret;
dws->dma_mapped = 0;
dws->n_bytes =
roundup_pow_of_two(DIV_ROUND_UP(transfer->bits_per_word,
BITS_PER_BYTE));
dws->tx = (void *)transfer->tx_buf;
dws->tx_len = transfer->len / dws->n_bytes;
dws->rx = transfer->rx_buf;
dws->rx_len = dws->tx_len;
/* Ensure the data above is visible for all CPUs */
smp_mb();
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_enable_chip(dws, 0);
dw_spi_update_config(dws, spi, &cfg);
spi: dw: Simplify the SPI bus speed config procedure 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-08 07:54:54 +08:00
transfer->effective_speed_hz = dws->current_freq;
/* Check if current transfer is a DMA transaction */
if (master->can_dma && master->can_dma(master, spi, transfer))
dws->dma_mapped = master->cur_msg_mapped;
/* For poll mode just disable all interrupts */
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_mask_intr(dws, 0xff);
if (dws->dma_mapped) {
ret = dws->dma_ops->dma_setup(dws, transfer);
if (ret)
return ret;
}
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_enable_chip(dws, 1);
if (dws->dma_mapped)
return dws->dma_ops->dma_transfer(dws, transfer);
else if (dws->irq == IRQ_NOTCONNECTED)
return dw_spi_poll_transfer(dws, transfer);
dw_spi_irq_setup(dws);
return 1;
}
static void dw_spi_handle_err(struct spi_controller *master,
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
struct spi_message *msg)
{
struct dw_spi *dws = spi_controller_get_devdata(master);
if (dws->dma_mapped)
dws->dma_ops->dma_stop(dws);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_reset_chip(dws);
}
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
static int dw_spi_adjust_mem_op_size(struct spi_mem *mem, struct spi_mem_op *op)
{
if (op->data.dir == SPI_MEM_DATA_IN)
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
op->data.nbytes = clamp_val(op->data.nbytes, 0, DW_SPI_NDF_MASK + 1);
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
return 0;
}
static bool dw_spi_supports_mem_op(struct spi_mem *mem,
const struct spi_mem_op *op)
{
if (op->data.buswidth > 1 || op->addr.buswidth > 1 ||
op->dummy.buswidth > 1 || op->cmd.buswidth > 1)
return false;
return spi_mem_default_supports_op(mem, op);
}
static int dw_spi_init_mem_buf(struct dw_spi *dws, const struct spi_mem_op *op)
{
unsigned int i, j, len;
u8 *out;
/*
* Calculate the total length of the EEPROM command transfer and
* either use the pre-allocated buffer or create a temporary one.
*/
len = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes;
if (op->data.dir == SPI_MEM_DATA_OUT)
len += op->data.nbytes;
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
if (len <= DW_SPI_BUF_SIZE) {
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
out = dws->buf;
} else {
out = kzalloc(len, GFP_KERNEL);
if (!out)
return -ENOMEM;
}
/*
* Collect the operation code, address and dummy bytes into the single
* buffer. If it's a transfer with data to be sent, also copy it into the
* single buffer in order to speed the data transmission up.
*/
for (i = 0; i < op->cmd.nbytes; ++i)
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
out[i] = DW_SPI_GET_BYTE(op->cmd.opcode, op->cmd.nbytes - i - 1);
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
for (j = 0; j < op->addr.nbytes; ++i, ++j)
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
out[i] = DW_SPI_GET_BYTE(op->addr.val, op->addr.nbytes - j - 1);
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
for (j = 0; j < op->dummy.nbytes; ++i, ++j)
out[i] = 0x0;
if (op->data.dir == SPI_MEM_DATA_OUT)
memcpy(&out[i], op->data.buf.out, op->data.nbytes);
dws->n_bytes = 1;
dws->tx = out;
dws->tx_len = len;
if (op->data.dir == SPI_MEM_DATA_IN) {
dws->rx = op->data.buf.in;
dws->rx_len = op->data.nbytes;
} else {
dws->rx = NULL;
dws->rx_len = 0;
}
return 0;
}
static void dw_spi_free_mem_buf(struct dw_spi *dws)
{
if (dws->tx != dws->buf)
kfree(dws->tx);
}
static int dw_spi_write_then_read(struct dw_spi *dws, struct spi_device *spi)
{
u32 room, entries, sts;
unsigned int len;
u8 *buf;
/*
* At initial stage we just pre-fill the Tx FIFO in with no rush,
* since native CS hasn't been enabled yet and the automatic data
* transmission won't start til we do that.
*/
len = min(dws->fifo_len, dws->tx_len);
buf = dws->tx;
while (len--)
dw_write_io_reg(dws, DW_SPI_DR, *buf++);
/*
* After setting any bit in the SER register the transmission will
* start automatically. We have to keep up with that procedure
* otherwise the CS de-assertion will happen whereupon the memory
* operation will be pre-terminated.
*/
len = dws->tx_len - ((void *)buf - dws->tx);
dw_spi_set_cs(spi, false);
while (len) {
entries = readl_relaxed(dws->regs + DW_SPI_TXFLR);
if (!entries) {
dev_err(&dws->master->dev, "CS de-assertion on Tx\n");
return -EIO;
}
room = min(dws->fifo_len - entries, len);
for (; room; --room, --len)
dw_write_io_reg(dws, DW_SPI_DR, *buf++);
}
/*
* Data fetching will start automatically if the EEPROM-read mode is
* activated. We have to keep up with the incoming data pace to
* prevent the Rx FIFO overflow causing the inbound data loss.
*/
len = dws->rx_len;
buf = dws->rx;
while (len) {
entries = readl_relaxed(dws->regs + DW_SPI_RXFLR);
if (!entries) {
sts = readl_relaxed(dws->regs + DW_SPI_RISR);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
if (sts & DW_SPI_INT_RXOI) {
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
dev_err(&dws->master->dev, "FIFO overflow on Rx\n");
return -EIO;
}
continue;
}
entries = min(entries, len);
for (; entries; --entries, --len)
*buf++ = dw_read_io_reg(dws, DW_SPI_DR);
}
return 0;
}
static inline bool dw_spi_ctlr_busy(struct dw_spi *dws)
{
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
return dw_readl(dws, DW_SPI_SR) & DW_SPI_SR_BUSY;
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
}
static int dw_spi_wait_mem_op_done(struct dw_spi *dws)
{
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
int retry = DW_SPI_WAIT_RETRIES;
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
struct spi_delay delay;
unsigned long ns, us;
u32 nents;
nents = dw_readl(dws, DW_SPI_TXFLR);
ns = NSEC_PER_SEC / dws->current_freq * nents;
ns *= dws->n_bytes * BITS_PER_BYTE;
if (ns <= NSEC_PER_USEC) {
delay.unit = SPI_DELAY_UNIT_NSECS;
delay.value = ns;
} else {
us = DIV_ROUND_UP(ns, NSEC_PER_USEC);
delay.unit = SPI_DELAY_UNIT_USECS;
delay.value = clamp_val(us, 0, USHRT_MAX);
}
while (dw_spi_ctlr_busy(dws) && retry--)
spi_delay_exec(&delay, NULL);
if (retry < 0) {
dev_err(&dws->master->dev, "Mem op hanged up\n");
return -EIO;
}
return 0;
}
static void dw_spi_stop_mem_op(struct dw_spi *dws, struct spi_device *spi)
{
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_enable_chip(dws, 0);
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
dw_spi_set_cs(spi, true);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_enable_chip(dws, 1);
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
}
/*
* The SPI memory operation implementation below is the best choice for the
* devices, which are selected by the native chip-select lane. It's
* specifically developed to workaround the problem with automatic chip-select
* lane toggle when there is no data in the Tx FIFO buffer. Luckily the current
* SPI-mem core calls exec_op() callback only if the GPIO-based CS is
* unavailable.
*/
static int dw_spi_exec_mem_op(struct spi_mem *mem, const struct spi_mem_op *op)
{
struct dw_spi *dws = spi_controller_get_devdata(mem->spi->controller);
struct dw_spi_cfg cfg;
unsigned long flags;
int ret;
/*
* Collect the outbound data into a single buffer to speed the
* transmission up at least on the initial stage.
*/
ret = dw_spi_init_mem_buf(dws, op);
if (ret)
return ret;
/*
* DW SPI EEPROM-read mode is required only for the SPI memory Data-IN
* operation. Transmit-only mode is suitable for the rest of them.
*/
cfg.dfs = 8;
cfg.freq = clamp(mem->spi->max_speed_hz, 0U, dws->max_mem_freq);
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
if (op->data.dir == SPI_MEM_DATA_IN) {
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
cfg.tmode = DW_SPI_CTRLR0_TMOD_EPROMREAD;
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
cfg.ndf = op->data.nbytes;
} else {
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
cfg.tmode = DW_SPI_CTRLR0_TMOD_TO;
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
}
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_enable_chip(dws, 0);
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
dw_spi_update_config(dws, mem->spi, &cfg);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_mask_intr(dws, 0xff);
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_enable_chip(dws, 1);
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
/*
* DW APB SSI controller has very nasty peculiarities. First originally
* (without any vendor-specific modifications) it doesn't provide a
* direct way to set and clear the native chip-select signal. Instead
* the controller asserts the CS lane if Tx FIFO isn't empty and a
* transmission is going on, and automatically de-asserts it back to
* the high level if the Tx FIFO doesn't have anything to be pushed
* out. Due to that a multi-tasking or heavy IRQs activity might be
* fatal, since the transfer procedure preemption may cause the Tx FIFO
* getting empty and sudden CS de-assertion, which in the middle of the
* transfer will most likely cause the data loss. Secondly the
* EEPROM-read or Read-only DW SPI transfer modes imply the incoming
* data being automatically pulled in into the Rx FIFO. So if the
* driver software is late in fetching the data from the FIFO before
* it's overflown, new incoming data will be lost. In order to make
* sure the executed memory operations are CS-atomic and to prevent the
* Rx FIFO overflow we have to disable the local interrupts so to block
* any preemption during the subsequent IO operations.
*
* Note. At some circumstances disabling IRQs may not help to prevent
* the problems described above. The CS de-assertion and Rx FIFO
* overflow may still happen due to the relatively slow system bus or
* CPU not working fast enough, so the write-then-read algo implemented
* here just won't keep up with the SPI bus data transfer. Such
* situation is highly platform specific and is supposed to be fixed by
* manually restricting the SPI bus frequency using the
* dws->max_mem_freq parameter.
*/
local_irq_save(flags);
preempt_disable();
ret = dw_spi_write_then_read(dws, mem->spi);
local_irq_restore(flags);
preempt_enable();
/*
* Wait for the operation being finished and check the controller
* status only if there hasn't been any run-time error detected. In the
* former case it's just pointless. In the later one to prevent an
* additional error message printing since any hw error flag being set
* would be due to an error detected on the data transfer.
*/
if (!ret) {
ret = dw_spi_wait_mem_op_done(dws);
if (!ret)
ret = dw_spi_check_status(dws, true);
}
dw_spi_stop_mem_op(dws, mem->spi);
dw_spi_free_mem_buf(dws);
return ret;
}
/*
* Initialize the default memory operations if a glue layer hasn't specified
* custom ones. Direct mapping operations will be preserved anyway since DW SPI
* controller doesn't have an embedded dirmap interface. Note the memory
* operations implemented in this driver is the best choice only for the DW APB
* SSI controller with standard native CS functionality. If a hardware vendor
* has fixed the automatic CS assertion/de-assertion peculiarity, then it will
* be safer to use the normal SPI-messages-based transfers implementation.
*/
static void dw_spi_init_mem_ops(struct dw_spi *dws)
{
if (!dws->mem_ops.exec_op && !(dws->caps & DW_SPI_CAP_CS_OVERRIDE) &&
!dws->set_cs) {
dws->mem_ops.adjust_op_size = dw_spi_adjust_mem_op_size;
dws->mem_ops.supports_op = dw_spi_supports_mem_op;
dws->mem_ops.exec_op = dw_spi_exec_mem_op;
if (!dws->max_mem_freq)
dws->max_mem_freq = dws->max_freq;
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
}
}
/* This may be called twice for each spi dev */
static int dw_spi_setup(struct spi_device *spi)
{
struct dw_spi *dws = spi_controller_get_devdata(spi->controller);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
struct dw_spi_chip_data *chip;
/* Only alloc on first setup */
chip = spi_get_ctldata(spi);
if (!chip) {
struct dw_spi *dws = spi_controller_get_devdata(spi->controller);
u32 rx_sample_dly_ns;
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
chip = kzalloc(sizeof(*chip), GFP_KERNEL);
if (!chip)
return -ENOMEM;
spi_set_ctldata(spi, chip);
/* Get specific / default rx-sample-delay */
if (device_property_read_u32(&spi->dev,
"rx-sample-delay-ns",
&rx_sample_dly_ns) != 0)
/* Use default controller value */
rx_sample_dly_ns = dws->def_rx_sample_dly_ns;
chip->rx_sample_dly = DIV_ROUND_CLOSEST(rx_sample_dly_ns,
NSEC_PER_SEC /
dws->max_freq);
}
/*
* Update CR0 data each time the setup callback is invoked since
* the device parameters could have been changed, for instance, by
* the MMC SPI driver or something else.
*/
chip->cr0 = dw_spi_prepare_cr0(dws, spi);
return 0;
}
spi: dw: Don't use devm_kzalloc in master->setup callback device_add() expects that any memory allocated via devm_* API is only done in the device's probe function. Fix below boot warning: WARNING: CPU: 1 PID: 1 at drivers/base/dd.c:286 driver_probe_device+0x2b4/0x2f4() Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.16.0-10474-g835c90b-dirty #160 [<c0016364>] (unwind_backtrace) from [<c001251c>] (show_stack+0x20/0x24) [<c001251c>] (show_stack) from [<c04eaefc>] (dump_stack+0x7c/0x98) [<c04eaefc>] (dump_stack) from [<c0023d4c>] (warn_slowpath_common+0x78/0x9c) [<c0023d4c>] (warn_slowpath_common) from [<c0023d9c>] (warn_slowpath_null+0x2c/0x34) [<c0023d9c>] (warn_slowpath_null) from [<c0302c60>] (driver_probe_device+0x2b4/0x2f4) [<c0302c60>] (driver_probe_device) from [<c0302d90>] (__device_attach+0x50/0x54) [<c0302d90>] (__device_attach) from [<c0300e60>] (bus_for_each_drv+0x54/0x9c) [<c0300e60>] (bus_for_each_drv) from [<c0302958>] (device_attach+0x84/0x90) [<c0302958>] (device_attach) from [<c0301f10>] (bus_probe_device+0x94/0xb8) [<c0301f10>] (bus_probe_device) from [<c03000c0>] (device_add+0x434/0x4fc) [<c03000c0>] (device_add) from [<c0342dd4>] (spi_add_device+0x98/0x164) [<c0342dd4>] (spi_add_device) from [<c03444a4>] (spi_register_master+0x598/0x768) [<c03444a4>] (spi_register_master) from [<c03446b4>] (devm_spi_register_master+0x40/0x80) [<c03446b4>] (devm_spi_register_master) from [<c0346214>] (dw_spi_add_host+0x1a8/0x258) [<c0346214>] (dw_spi_add_host) from [<c0346920>] (dw_spi_mmio_probe+0x1d4/0x294) [<c0346920>] (dw_spi_mmio_probe) from [<c0304560>] (platform_drv_probe+0x3c/0x6c) [<c0304560>] (platform_drv_probe) from [<c0302a98>] (driver_probe_device+0xec/0x2f4) [<c0302a98>] (driver_probe_device) from [<c0302d3c>] (__driver_attach+0x9c/0xa0) [<c0302d3c>] (__driver_attach) from [<c0300f0c>] (bus_for_each_dev+0x64/0x98) [<c0300f0c>] (bus_for_each_dev) from [<c0302518>] (driver_attach+0x2c/0x30) [<c0302518>] (driver_attach) from [<c0302134>] (bus_add_driver+0xdc/0x1f4) [<c0302134>] (bus_add_driver) from [<c03035c8>] (driver_register+0x88/0x104) [<c03035c8>] (driver_register) from [<c030445c>] (__platform_driver_register+0x58/0x6c) [<c030445c>] (__platform_driver_register) from [<c0700f00>] (dw_spi_mmio_driver_init+0x18/0x20) [<c0700f00>] (dw_spi_mmio_driver_init) from [<c0008914>] (do_one_initcall+0x90/0x1d4) [<c0008914>] (do_one_initcall) from [<c06d7d90>] (kernel_init_freeable+0x178/0x248) [<c06d7d90>] (kernel_init_freeable) from [<c04e687c>] (kernel_init+0x18/0xfc) [<c04e687c>] (kernel_init) from [<c000ecd8>] (ret_from_fork+0x14/0x20) Reported-by: Thor Thayer <tthayer@opensource.altera.com> Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2014-08-31 12:47:06 +08:00
static void dw_spi_cleanup(struct spi_device *spi)
{
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
struct dw_spi_chip_data *chip = spi_get_ctldata(spi);
spi: dw: Don't use devm_kzalloc in master->setup callback device_add() expects that any memory allocated via devm_* API is only done in the device's probe function. Fix below boot warning: WARNING: CPU: 1 PID: 1 at drivers/base/dd.c:286 driver_probe_device+0x2b4/0x2f4() Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.16.0-10474-g835c90b-dirty #160 [<c0016364>] (unwind_backtrace) from [<c001251c>] (show_stack+0x20/0x24) [<c001251c>] (show_stack) from [<c04eaefc>] (dump_stack+0x7c/0x98) [<c04eaefc>] (dump_stack) from [<c0023d4c>] (warn_slowpath_common+0x78/0x9c) [<c0023d4c>] (warn_slowpath_common) from [<c0023d9c>] (warn_slowpath_null+0x2c/0x34) [<c0023d9c>] (warn_slowpath_null) from [<c0302c60>] (driver_probe_device+0x2b4/0x2f4) [<c0302c60>] (driver_probe_device) from [<c0302d90>] (__device_attach+0x50/0x54) [<c0302d90>] (__device_attach) from [<c0300e60>] (bus_for_each_drv+0x54/0x9c) [<c0300e60>] (bus_for_each_drv) from [<c0302958>] (device_attach+0x84/0x90) [<c0302958>] (device_attach) from [<c0301f10>] (bus_probe_device+0x94/0xb8) [<c0301f10>] (bus_probe_device) from [<c03000c0>] (device_add+0x434/0x4fc) [<c03000c0>] (device_add) from [<c0342dd4>] (spi_add_device+0x98/0x164) [<c0342dd4>] (spi_add_device) from [<c03444a4>] (spi_register_master+0x598/0x768) [<c03444a4>] (spi_register_master) from [<c03446b4>] (devm_spi_register_master+0x40/0x80) [<c03446b4>] (devm_spi_register_master) from [<c0346214>] (dw_spi_add_host+0x1a8/0x258) [<c0346214>] (dw_spi_add_host) from [<c0346920>] (dw_spi_mmio_probe+0x1d4/0x294) [<c0346920>] (dw_spi_mmio_probe) from [<c0304560>] (platform_drv_probe+0x3c/0x6c) [<c0304560>] (platform_drv_probe) from [<c0302a98>] (driver_probe_device+0xec/0x2f4) [<c0302a98>] (driver_probe_device) from [<c0302d3c>] (__driver_attach+0x9c/0xa0) [<c0302d3c>] (__driver_attach) from [<c0300f0c>] (bus_for_each_dev+0x64/0x98) [<c0300f0c>] (bus_for_each_dev) from [<c0302518>] (driver_attach+0x2c/0x30) [<c0302518>] (driver_attach) from [<c0302134>] (bus_add_driver+0xdc/0x1f4) [<c0302134>] (bus_add_driver) from [<c03035c8>] (driver_register+0x88/0x104) [<c03035c8>] (driver_register) from [<c030445c>] (__platform_driver_register+0x58/0x6c) [<c030445c>] (__platform_driver_register) from [<c0700f00>] (dw_spi_mmio_driver_init+0x18/0x20) [<c0700f00>] (dw_spi_mmio_driver_init) from [<c0008914>] (do_one_initcall+0x90/0x1d4) [<c0008914>] (do_one_initcall) from [<c06d7d90>] (kernel_init_freeable+0x178/0x248) [<c06d7d90>] (kernel_init_freeable) from [<c04e687c>] (kernel_init+0x18/0xfc) [<c04e687c>] (kernel_init) from [<c000ecd8>] (ret_from_fork+0x14/0x20) Reported-by: Thor Thayer <tthayer@opensource.altera.com> Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2014-08-31 12:47:06 +08:00
kfree(chip);
spi_set_ctldata(spi, NULL);
}
/* Restart the controller, disable all interrupts, clean rx fifo */
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
static void dw_spi_hw_init(struct device *dev, struct dw_spi *dws)
{
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_reset_chip(dws);
spi: dw: Introduce Synopsys IP-core versions interface The driver currently supports two IP-core versions. It's DW APB SSI which is older version of the controller with APB system bus interface, and DW SSI controller with AHB bus interface. The later one is supposed to be a new generation high-speed SSI. Even though both of these IP-cores have got an almost identical registers space there are some differences. The driver differentiates these distinctions by the DW_SPI_CAP_DWC_HSSI capability flag. In addition to that each DW SSI IP-core is equipped with a Synopsys Component version register, which encodes the IP-core release ID the has been synthesized from. Seeing we are going to need the later one to differentiate some controller peculiarities it would be better to have a unified interface for both IP-core line and release versions instead of using each of them separately. Introduced here IP-core versioning interface consists of two parts: 1) IDs of the IP-core (virtual) and component versions. 2) a set of macro helpers to identify current IP-core and component versions. So the platform code is supposed to assign a proper IP-core version based on it's platform -knowledge. The main driver initialization method reads the IP-core release ID from the SSI component version register. That data is used by the helpers to distinguish one IP-core release from another. Thus the rest of the driver can use these macros to implement the conditional code execution based on the specified IP-core and version IDs. Collect the IP-core versions interface and the defined capabilities at the top of the header file since they represent a common device description data and so to immediately available for the driver hackers. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-6-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:15 +08:00
/*
* Retrieve the Synopsys component version if it hasn't been specified
* by the platform. CoreKit version ID is encoded as a 3-chars ASCII
* code enclosed with '*' (typical for the most of Synopsys IP-cores).
*/
if (!dws->ver) {
dws->ver = dw_readl(dws, DW_SPI_VERSION);
dev_dbg(dev, "Synopsys DWC%sSSI v%c.%c%c\n",
dw_spi_ip_is(dws, PSSI) ? " APB " : " ",
spi: dw: Introduce Synopsys IP-core versions interface The driver currently supports two IP-core versions. It's DW APB SSI which is older version of the controller with APB system bus interface, and DW SSI controller with AHB bus interface. The later one is supposed to be a new generation high-speed SSI. Even though both of these IP-cores have got an almost identical registers space there are some differences. The driver differentiates these distinctions by the DW_SPI_CAP_DWC_HSSI capability flag. In addition to that each DW SSI IP-core is equipped with a Synopsys Component version register, which encodes the IP-core release ID the has been synthesized from. Seeing we are going to need the later one to differentiate some controller peculiarities it would be better to have a unified interface for both IP-core line and release versions instead of using each of them separately. Introduced here IP-core versioning interface consists of two parts: 1) IDs of the IP-core (virtual) and component versions. 2) a set of macro helpers to identify current IP-core and component versions. So the platform code is supposed to assign a proper IP-core version based on it's platform -knowledge. The main driver initialization method reads the IP-core release ID from the SSI component version register. That data is used by the helpers to distinguish one IP-core release from another. Thus the rest of the driver can use these macros to implement the conditional code execution based on the specified IP-core and version IDs. Collect the IP-core versions interface and the defined capabilities at the top of the header file since they represent a common device description data and so to immediately available for the driver hackers. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-6-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:15 +08:00
DW_SPI_GET_BYTE(dws->ver, 3), DW_SPI_GET_BYTE(dws->ver, 2),
DW_SPI_GET_BYTE(dws->ver, 1));
}
/*
* Try to detect the FIFO depth if not set by interface driver,
* the depth could be from 2 to 256 from HW spec
*/
if (!dws->fifo_len) {
u32 fifo;
for (fifo = 1; fifo < 256; fifo++) {
dw_writel(dws, DW_SPI_TXFTLR, fifo);
if (fifo != dw_readl(dws, DW_SPI_TXFTLR))
break;
}
dw_writel(dws, DW_SPI_TXFTLR, 0);
dws->fifo_len = (fifo == 1) ? 0 : fifo;
dev_dbg(dev, "Detected FIFO size: %u bytes\n", dws->fifo_len);
}
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
/*
* Detect CTRLR0.DFS field size and offset by testing the lowest bits
* writability. Note DWC SSI controller also has the extended DFS, but
* with zero offset.
*/
if (dw_spi_ip_is(dws, PSSI)) {
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
u32 cr0, tmp = dw_readl(dws, DW_SPI_CTRLR0);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_enable_chip(dws, 0);
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
dw_writel(dws, DW_SPI_CTRLR0, 0xffffffff);
cr0 = dw_readl(dws, DW_SPI_CTRLR0);
dw_writel(dws, DW_SPI_CTRLR0, tmp);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_enable_chip(dws, 1);
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
if (!(cr0 & DW_PSSI_CTRLR0_DFS_MASK)) {
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
dws->caps |= DW_SPI_CAP_DFS32;
dws->dfs_offset = __bf_shf(DW_PSSI_CTRLR0_DFS32_MASK);
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
dev_dbg(dev, "Detected 32-bits max data frame size\n");
}
} else {
dws->caps |= DW_SPI_CAP_DFS32;
}
/* enable HW fixup for explicit CS deselect for Amazon's alpine chip */
if (dws->caps & DW_SPI_CAP_CS_OVERRIDE)
dw_writel(dws, DW_SPI_CS_OVERRIDE, 0xF);
}
int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
{
struct spi_controller *master;
int ret;
if (!dws)
return -EINVAL;
master = spi_alloc_master(dev, 0);
if (!master)
return -ENOMEM;
device_set_node(&master->dev, dev_fwnode(dev));
dws->master = master;
dws->dma_addr = (dma_addr_t)(dws->paddr + DW_SPI_DR);
spi_controller_set_devdata(master, dws);
/* Basic HW init */
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_hw_init(dev, dws);
ret = request_irq(dws->irq, dw_spi_irq, IRQF_SHARED, dev_name(dev),
master);
if (ret < 0 && ret != -ENOTCONN) {
dev_err(dev, "can not get IRQ\n");
goto err_free_master;
}
spi: dw: Add memory operations support Aside from the synchronous Tx-Rx mode, which has been utilized to create the normal SPI transfers in the framework of the DW SSI driver, DW SPI controller supports Tx-only and EEPROM-read modes. The former one just enables the controller to transmit all the data from the Tx FIFO ignoring anything retrieved from the MISO lane. The later mode is so called write-then-read operation: DW SPI controller first pushes out all the data from the Tx FIFO, after that it'll automatically receive as much data as has been specified by means of the CTRLR1 register. Both of those modes can be used to implement the memory operations supported by the SPI-memory subsystem. The memory operation implementation is pretty much straightforward, except a few peculiarities we have had to take into account to make things working. Since DW SPI controller doesn't provide a way to directly set and clear the native CS lane level, but instead automatically de-asserts it when a transfer going on, we have to make sure the Tx FIFO isn't empty during entire Tx procedure. In addition we also need to read data from the Rx FIFO as fast as possible to prevent it' overflow with automatically fetched incoming traffic. The denoted peculiarities get to cause even more problems if DW SSI controller is equipped with relatively small FIFO and is connected to a relatively slow system bus (APB) (with respect to the SPI bus speed). In order to workaround the problems for as much as it's possible, the memory operation execution procedure collects all the Tx data into a single buffer and disables the local IRQs to speed the write-then-optionally-read method up. Note the provided memory operations are utilized by default only if a glue driver hasn't provided a custom version of ones and this is not a DW APB SSI controller with fixed automatic CS toggle functionality. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-18-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-08 07:55:06 +08:00
dw_spi_init_mem_ops(dws);
master->use_gpio_descriptors = true;
master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LOOP;
spi: dw: Add support for 32-bits max xfer size The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-06 09:18:16 +08:00
if (dws->caps & DW_SPI_CAP_DFS32)
master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
else
master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 16);
master->bus_num = dws->bus_num;
master->num_chipselect = dws->num_cs;
master->setup = dw_spi_setup;
spi: dw: Don't use devm_kzalloc in master->setup callback device_add() expects that any memory allocated via devm_* API is only done in the device's probe function. Fix below boot warning: WARNING: CPU: 1 PID: 1 at drivers/base/dd.c:286 driver_probe_device+0x2b4/0x2f4() Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.16.0-10474-g835c90b-dirty #160 [<c0016364>] (unwind_backtrace) from [<c001251c>] (show_stack+0x20/0x24) [<c001251c>] (show_stack) from [<c04eaefc>] (dump_stack+0x7c/0x98) [<c04eaefc>] (dump_stack) from [<c0023d4c>] (warn_slowpath_common+0x78/0x9c) [<c0023d4c>] (warn_slowpath_common) from [<c0023d9c>] (warn_slowpath_null+0x2c/0x34) [<c0023d9c>] (warn_slowpath_null) from [<c0302c60>] (driver_probe_device+0x2b4/0x2f4) [<c0302c60>] (driver_probe_device) from [<c0302d90>] (__device_attach+0x50/0x54) [<c0302d90>] (__device_attach) from [<c0300e60>] (bus_for_each_drv+0x54/0x9c) [<c0300e60>] (bus_for_each_drv) from [<c0302958>] (device_attach+0x84/0x90) [<c0302958>] (device_attach) from [<c0301f10>] (bus_probe_device+0x94/0xb8) [<c0301f10>] (bus_probe_device) from [<c03000c0>] (device_add+0x434/0x4fc) [<c03000c0>] (device_add) from [<c0342dd4>] (spi_add_device+0x98/0x164) [<c0342dd4>] (spi_add_device) from [<c03444a4>] (spi_register_master+0x598/0x768) [<c03444a4>] (spi_register_master) from [<c03446b4>] (devm_spi_register_master+0x40/0x80) [<c03446b4>] (devm_spi_register_master) from [<c0346214>] (dw_spi_add_host+0x1a8/0x258) [<c0346214>] (dw_spi_add_host) from [<c0346920>] (dw_spi_mmio_probe+0x1d4/0x294) [<c0346920>] (dw_spi_mmio_probe) from [<c0304560>] (platform_drv_probe+0x3c/0x6c) [<c0304560>] (platform_drv_probe) from [<c0302a98>] (driver_probe_device+0xec/0x2f4) [<c0302a98>] (driver_probe_device) from [<c0302d3c>] (__driver_attach+0x9c/0xa0) [<c0302d3c>] (__driver_attach) from [<c0300f0c>] (bus_for_each_dev+0x64/0x98) [<c0300f0c>] (bus_for_each_dev) from [<c0302518>] (driver_attach+0x2c/0x30) [<c0302518>] (driver_attach) from [<c0302134>] (bus_add_driver+0xdc/0x1f4) [<c0302134>] (bus_add_driver) from [<c03035c8>] (driver_register+0x88/0x104) [<c03035c8>] (driver_register) from [<c030445c>] (__platform_driver_register+0x58/0x6c) [<c030445c>] (__platform_driver_register) from [<c0700f00>] (dw_spi_mmio_driver_init+0x18/0x20) [<c0700f00>] (dw_spi_mmio_driver_init) from [<c0008914>] (do_one_initcall+0x90/0x1d4) [<c0008914>] (do_one_initcall) from [<c06d7d90>] (kernel_init_freeable+0x178/0x248) [<c06d7d90>] (kernel_init_freeable) from [<c04e687c>] (kernel_init+0x18/0xfc) [<c04e687c>] (kernel_init) from [<c000ecd8>] (ret_from_fork+0x14/0x20) Reported-by: Thor Thayer <tthayer@opensource.altera.com> Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2014-08-31 12:47:06 +08:00
master->cleanup = dw_spi_cleanup;
if (dws->set_cs)
master->set_cs = dws->set_cs;
else
master->set_cs = dw_spi_set_cs;
master->transfer_one = dw_spi_transfer_one;
master->handle_err = dw_spi_handle_err;
if (dws->mem_ops.exec_op)
master->mem_ops = &dws->mem_ops;
master->max_speed_hz = dws->max_freq;
master->flags = SPI_MASTER_GPIO_SS;
master->auto_runtime_pm = true;
/* Get default rx sample delay */
device_property_read_u32(dev, "rx-sample-delay-ns",
&dws->def_rx_sample_dly_ns);
if (dws->dma_ops && dws->dma_ops->dma_init) {
ret = dws->dma_ops->dma_init(dev, dws);
if (ret == -EPROBE_DEFER) {
goto err_free_irq;
} else if (ret) {
dev_warn(dev, "DMA init failed\n");
} else {
master->can_dma = dws->dma_ops->can_dma;
master->flags |= SPI_CONTROLLER_MUST_TX;
}
}
spi: dw: Fix controller unregister order The Designware SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes dw_spi_remove_host() before unregistering the SPI controller via devres_release_all(). This order is incorrect: dw_spi_remove_host() shuts down the chip, rendering the SPI bus inaccessible even though the SPI controller is still registered. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. Because their drivers cannot access the SPI bus, e.g. to quiesce interrupts, the slave devices may be left in an improper state. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unregistering the controller and specifically after unbinding of slaves. Fix by reverting to the non-devm variant of spi_register_controller(). An alternative approach would be to use device-managed functions for all steps in dw_spi_remove_host(), e.g. by calling devm_add_action_or_reset() on probe. However that approach would add more LoC to the driver and it wouldn't lend itself as well to backporting to stable. Fixes: 04f421e7b0b1 ("spi: dw: use managed resources") Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable@vger.kernel.org # v3.14+ Cc: Baruch Siach <baruch@tkos.co.il> Link: https://lore.kernel.org/r/3fff8cb8ae44a9893840d0688be15bb88c090a14.1590408496.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-25 20:25:01 +08:00
ret = spi_register_controller(master);
if (ret) {
dev_err_probe(dev, ret, "problem registering spi master\n");
goto err_dma_exit;
}
dw_spi_debugfs_init(dws);
return 0;
err_dma_exit:
if (dws->dma_ops && dws->dma_ops->dma_exit)
dws->dma_ops->dma_exit(dws);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_enable_chip(dws, 0);
err_free_irq:
spi: dw: explicitly free IRQ handler in dw_spi_remove_host() The following warning occurs when DW SPI is compiled as a module and it's a PCI device. On the removal stage pcibios_free_irq() is called earlier than free_irq() due to the latter is called at managed resources free strage. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1003 at /home/andy/prj/linux/fs/proc/generic.c:575 remove_proc_entry+0x118/0x150() remove_proc_entry: removing non-empty directory 'irq/38', leaking at least 'dw_spi1' Modules linked in: spi_dw_midpci(-) spi_dw [last unloaded: dw_dmac_core] CPU: 1 PID: 1003 Comm: modprobe Not tainted 4.3.0-rc5-next-20151013+ #32 00000000 00000000 f5535d70 c12dc220 f5535db0 f5535da0 c104e912 c198a6bc f5535dcc 000003eb c198a638 0000023f c11b4098 c11b4098 f54f1ec8 f54f1ea0 f642ba20 f5535db8 c104e96e 00000009 f5535db0 c198a6bc f5535dcc f5535df0 Call Trace: [<c12dc220>] dump_stack+0x41/0x61 [<c104e912>] warn_slowpath_common+0x82/0xb0 [<c11b4098>] ? remove_proc_entry+0x118/0x150 [<c11b4098>] ? remove_proc_entry+0x118/0x150 [<c104e96e>] warn_slowpath_fmt+0x2e/0x30 [<c11b4098>] remove_proc_entry+0x118/0x150 [<c109b96a>] unregister_irq_proc+0xaa/0xc0 [<c109575e>] free_desc+0x1e/0x60 [<c10957d2>] irq_free_descs+0x32/0x70 [<c109b1a0>] irq_domain_free_irqs+0x120/0x150 [<c1039e8c>] mp_unmap_irq+0x5c/0x60 [<c16277b0>] intel_mid_pci_irq_disable+0x20/0x40 [<c1627c7f>] pcibios_free_irq+0xf/0x20 [<c13189f2>] pci_device_remove+0x52/0xb0 [<c13f6367>] __device_release_driver+0x77/0x100 [<c13f6da7>] driver_detach+0x87/0x90 [<c13f5eaa>] bus_remove_driver+0x4a/0xc0 [<c128bf0d>] ? selinux_capable+0xd/0x10 [<c13f7483>] driver_unregister+0x23/0x60 [<c10bad8a>] ? find_module_all+0x5a/0x80 [<c1317413>] pci_unregister_driver+0x13/0x60 [<f80ac654>] dw_spi_driver_exit+0xd/0xf [spi_dw_midpci] [<c10bce9a>] SyS_delete_module+0x17a/0x210 Explicitly call free_irq() at removal stage of the DW SPI driver. Fixes: 04f421e7b0b1 (spi: dw: use managed resources) Cc: stable@vger.kernel.org Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-20 17:11:40 +08:00
free_irq(dws->irq, master);
err_free_master:
spi_controller_put(master);
return ret;
}
EXPORT_SYMBOL_NS_GPL(dw_spi_add_host, SPI_DW_CORE);
void dw_spi_remove_host(struct dw_spi *dws)
{
dw_spi_debugfs_remove(dws);
spi: dw: Fix controller unregister order The Designware SPI driver uses devm_spi_register_controller() on bind. As a consequence, on unbind, __device_release_driver() first invokes dw_spi_remove_host() before unregistering the SPI controller via devres_release_all(). This order is incorrect: dw_spi_remove_host() shuts down the chip, rendering the SPI bus inaccessible even though the SPI controller is still registered. When the SPI controller is subsequently unregistered, it unbinds all its slave devices. Because their drivers cannot access the SPI bus, e.g. to quiesce interrupts, the slave devices may be left in an improper state. As a rule, devm_spi_register_controller() must not be used if the ->remove() hook performs teardown steps which shall be performed after unregistering the controller and specifically after unbinding of slaves. Fix by reverting to the non-devm variant of spi_register_controller(). An alternative approach would be to use device-managed functions for all steps in dw_spi_remove_host(), e.g. by calling devm_add_action_or_reset() on probe. However that approach would add more LoC to the driver and it wouldn't lend itself as well to backporting to stable. Fixes: 04f421e7b0b1 ("spi: dw: use managed resources") Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: stable@vger.kernel.org # v3.14+ Cc: Baruch Siach <baruch@tkos.co.il> Link: https://lore.kernel.org/r/3fff8cb8ae44a9893840d0688be15bb88c090a14.1590408496.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-25 20:25:01 +08:00
spi_unregister_controller(dws->master);
if (dws->dma_ops && dws->dma_ops->dma_exit)
dws->dma_ops->dma_exit(dws);
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_shutdown_chip(dws);
spi: dw: explicitly free IRQ handler in dw_spi_remove_host() The following warning occurs when DW SPI is compiled as a module and it's a PCI device. On the removal stage pcibios_free_irq() is called earlier than free_irq() due to the latter is called at managed resources free strage. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1003 at /home/andy/prj/linux/fs/proc/generic.c:575 remove_proc_entry+0x118/0x150() remove_proc_entry: removing non-empty directory 'irq/38', leaking at least 'dw_spi1' Modules linked in: spi_dw_midpci(-) spi_dw [last unloaded: dw_dmac_core] CPU: 1 PID: 1003 Comm: modprobe Not tainted 4.3.0-rc5-next-20151013+ #32 00000000 00000000 f5535d70 c12dc220 f5535db0 f5535da0 c104e912 c198a6bc f5535dcc 000003eb c198a638 0000023f c11b4098 c11b4098 f54f1ec8 f54f1ea0 f642ba20 f5535db8 c104e96e 00000009 f5535db0 c198a6bc f5535dcc f5535df0 Call Trace: [<c12dc220>] dump_stack+0x41/0x61 [<c104e912>] warn_slowpath_common+0x82/0xb0 [<c11b4098>] ? remove_proc_entry+0x118/0x150 [<c11b4098>] ? remove_proc_entry+0x118/0x150 [<c104e96e>] warn_slowpath_fmt+0x2e/0x30 [<c11b4098>] remove_proc_entry+0x118/0x150 [<c109b96a>] unregister_irq_proc+0xaa/0xc0 [<c109575e>] free_desc+0x1e/0x60 [<c10957d2>] irq_free_descs+0x32/0x70 [<c109b1a0>] irq_domain_free_irqs+0x120/0x150 [<c1039e8c>] mp_unmap_irq+0x5c/0x60 [<c16277b0>] intel_mid_pci_irq_disable+0x20/0x40 [<c1627c7f>] pcibios_free_irq+0xf/0x20 [<c13189f2>] pci_device_remove+0x52/0xb0 [<c13f6367>] __device_release_driver+0x77/0x100 [<c13f6da7>] driver_detach+0x87/0x90 [<c13f5eaa>] bus_remove_driver+0x4a/0xc0 [<c128bf0d>] ? selinux_capable+0xd/0x10 [<c13f7483>] driver_unregister+0x23/0x60 [<c10bad8a>] ? find_module_all+0x5a/0x80 [<c1317413>] pci_unregister_driver+0x13/0x60 [<f80ac654>] dw_spi_driver_exit+0xd/0xf [spi_dw_midpci] [<c10bce9a>] SyS_delete_module+0x17a/0x210 Explicitly call free_irq() at removal stage of the DW SPI driver. Fixes: 04f421e7b0b1 (spi: dw: use managed resources) Cc: stable@vger.kernel.org Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-20 17:11:40 +08:00
free_irq(dws->irq, dws->master);
}
EXPORT_SYMBOL_NS_GPL(dw_spi_remove_host, SPI_DW_CORE);
int dw_spi_suspend_host(struct dw_spi *dws)
{
int ret;
ret = spi_controller_suspend(dws->master);
if (ret)
return ret;
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_shutdown_chip(dws);
return 0;
}
EXPORT_SYMBOL_NS_GPL(dw_spi_suspend_host, SPI_DW_CORE);
int dw_spi_resume_host(struct dw_spi *dws)
{
spi: dw: Put the driver entities naming in order Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16 02:19:13 +08:00
dw_spi_hw_init(&dws->master->dev, dws);
return spi_controller_resume(dws->master);
}
EXPORT_SYMBOL_NS_GPL(dw_spi_resume_host, SPI_DW_CORE);
MODULE_AUTHOR("Feng Tang <feng.tang@intel.com>");
MODULE_DESCRIPTION("Driver for DesignWare SPI controller core");
MODULE_LICENSE("GPL v2");