* [PATCH v6 11/16] spi: dw: Remove DW DMA code dependency from DW_DMAC_PCI
From: Serge Semin @ 2020-05-29 13:12 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Andy Shevchenko, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Feng Tang, Rob Herring, linux-mips, devicetree,
linux-spi, linux-kernel
In-Reply-To: <20200529131205.31838-1-Sergey.Semin@baikalelectronics.ru>
Since there is a generic method available to initialize the DW SPI DMA
interface on any DT and ACPI-based platforms, which in general can be
designed with not only DW DMAC but with any DMA engine on board, we can
freely remove the CONFIG_DW_DMAC_PCI config from dependency list of
CONFIG_SPI_DW_DMA. Especially seeing that we don't use anything DW DMAC
specific in the new driver.
Co-developed-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Signed-off-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
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>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
drivers/spi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 03b061975f70..6a84f3dad35c 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -228,7 +228,7 @@ config SPI_DESIGNWARE
config SPI_DW_DMA
bool "DMA support for DW SPI controller"
- depends on SPI_DESIGNWARE && DW_DMAC_PCI
+ depends on SPI_DESIGNWARE
config SPI_DW_PCI
tristate "PCI interface driver for DW SPI core"
--
2.26.2
^ permalink raw reply related
* [PATCH v6 01/16] spi: dw: Set xfer effective_speed_hz
From: Serge Semin @ 2020-05-29 13:11 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Feng Tang,
Andy Shevchenko, Rob Herring, linux-mips, devicetree, linux-spi,
linux-kernel
In-Reply-To: <20200529131205.31838-1-Sergey.Semin@baikalelectronics.ru>
Seeing DW APB SSI controller doesn't support setting the exactly
requested SPI bus frequency, but only a rounded frequency determined
by means of the odd-numbered half-worded reference clock divider,
it would be good to tune the SPI core up and initialize the current
transfer effective_speed_hz. By doing so the core will be able to
execute the xfer-related delays with better accuracy.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
drivers/spi/spi-dw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index 9d6904d30104..050cb2ea0812 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -352,6 +352,7 @@ static int dw_spi_transfer_one(struct spi_controller *master,
spi_set_clk(dws, chip->clk_div);
}
+ transfer->effective_speed_hz = dws->max_freq / chip->clk_div;
dws->n_bytes = DIV_ROUND_UP(transfer->bits_per_word, BITS_PER_BYTE);
cr0 = dws->update_cr0(master, spi, transfer);
--
2.26.2
^ permalink raw reply related
* [PATCH v6 04/16] spi: dw: Add SPI Tx-done wait method to DMA-based transfer
From: Serge Semin @ 2020-05-29 13:11 UTC (permalink / raw)
To: Mark Brown, Grant Likely, Linus Walleij, Alan Cox, Vinod Koul,
Feng Tang
Cc: Serge Semin, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann,
Andy Shevchenko, Rob Herring, linux-mips, devicetree, linux-spi,
linux-kernel
In-Reply-To: <20200529131205.31838-1-Sergey.Semin@baikalelectronics.ru>
Since DMA transfers are performed asynchronously with actual SPI bus
transfers, then even if DMA transactions are finished it doesn't mean
all data is actually pushed to the SPI bus. Some data might still be
in the controller FIFO. This is specifically true for Tx-only transfers.
In this case if the next SPI transfer is recharged while a tail of the
previous one is still in FIFO, we'll loose that tail data. In order to
fix that problem let's add the wait procedure of the Tx SPI transfer
completion after the DMA transactions are finished.
Fixes: 7063c0d942a1 ("spi/dw_spi: add DMA support")
Co-developed-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Signed-off-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- Use conditional statement instead of the ternary operator in the ref
clock getter.
- Move the patch to the head of the series so one could be picked up to
the stable kernels as a fix.
Changelog v3:
- Use spi_delay_exec() method to wait for the current operation completion.
Changelog v4:
- Get back ndelay() method to wait for an SPI transfer completion.
spi_delay_exec() isn't suitable for the atomic context.
Changelog v5:
- Add more detailed description of the problems the patch fixes.
- Wait for the SPI Tx transfer finish in the mid_spi_dma_transfer() method
executed in the task context.
- Use spi_delay_exec() to wait for the SPI Tx completion, since now the
driver does in the kernel thread context.
- Use SPI_DELAY_UNIT_SCK spi_delay unit, since SPI xfer's are now have the
effective_speed_hz initialized.
---
drivers/spi/spi-dw-mid.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index 355b641c4483..846e3db91329 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -19,6 +19,7 @@
#include <linux/pci.h>
#include <linux/platform_data/dma-dw.h>
+#define WAIT_RETRIES 5
#define RX_BUSY 0
#define TX_BUSY 1
@@ -171,6 +172,33 @@ static int dw_spi_dma_wait(struct dw_spi *dws, struct spi_transfer *xfer)
return 0;
}
+static inline bool dw_spi_dma_tx_busy(struct dw_spi *dws)
+{
+ return !(dw_readl(dws, DW_SPI_SR) & SR_TF_EMPT);
+}
+
+static int dw_spi_dma_wait_tx_done(struct dw_spi *dws,
+ struct spi_transfer *xfer)
+{
+ int retry = WAIT_RETRIES;
+ struct spi_delay delay;
+ u32 nents;
+
+ nents = dw_readl(dws, DW_SPI_TXFLR);
+ delay.unit = SPI_DELAY_UNIT_SCK;
+ delay.value = nents * dws->n_bytes * BITS_PER_BYTE;
+
+ while (dw_spi_dma_tx_busy(dws) && retry--)
+ spi_delay_exec(&delay, xfer);
+
+ if (retry < 0) {
+ dev_err(&dws->master->dev, "Tx hanged up\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
/*
* dws->dma_chan_busy is set before the dma transfer starts, callback for tx
* channel will clear a corresponding bit.
@@ -324,6 +352,12 @@ static int mid_spi_dma_transfer(struct dw_spi *dws, struct spi_transfer *xfer)
if (ret)
return ret;
+ if (txdesc && dws->master->cur_msg->status == -EINPROGRESS) {
+ ret = dw_spi_dma_wait_tx_done(dws, xfer);
+ if (ret)
+ return ret;
+ }
+
return 0;
}
--
2.26.2
^ permalink raw reply related
* [PATCH v6 06/16] spi: dw: Parameterize the DMA Rx/Tx burst length
From: Serge Semin @ 2020-05-29 13:11 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Andy Shevchenko, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Feng Tang, Rob Herring, linux-mips, devicetree,
linux-spi, linux-kernel
In-Reply-To: <20200529131205.31838-1-Sergey.Semin@baikalelectronics.ru>
It isn't good to have numeric literals in the code especially if there
are multiple of them and they are related. Let's replace the Tx and Rx
burst level literals with the corresponding constants.
Co-developed-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Signed-off-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
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>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- Discard the dws->fifo_len utilization in the Tx FIFO DMA threshold
setting.
---
drivers/spi/spi-dw-mid.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index abd6955ad1f7..189b517f77fc 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -21,7 +21,9 @@
#define WAIT_RETRIES 5
#define RX_BUSY 0
+#define RX_BURST_LEVEL 16
#define TX_BUSY 1
+#define TX_BURST_LEVEL 16
static bool mid_spi_dma_chan_filter(struct dma_chan *chan, void *param)
{
@@ -227,7 +229,7 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_tx(struct dw_spi *dws,
memset(&txconf, 0, sizeof(txconf));
txconf.direction = DMA_MEM_TO_DEV;
txconf.dst_addr = dws->dma_addr;
- txconf.dst_maxburst = 16;
+ txconf.dst_maxburst = TX_BURST_LEVEL;
txconf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
txconf.dst_addr_width = convert_dma_width(dws->n_bytes);
txconf.device_fc = false;
@@ -319,7 +321,7 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_rx(struct dw_spi *dws,
memset(&rxconf, 0, sizeof(rxconf));
rxconf.direction = DMA_DEV_TO_MEM;
rxconf.src_addr = dws->dma_addr;
- rxconf.src_maxburst = 16;
+ rxconf.src_maxburst = RX_BURST_LEVEL;
rxconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
rxconf.src_addr_width = convert_dma_width(dws->n_bytes);
rxconf.device_fc = false;
@@ -344,8 +346,8 @@ static int mid_spi_dma_setup(struct dw_spi *dws, struct spi_transfer *xfer)
{
u16 imr = 0, dma_ctrl = 0;
- dw_writel(dws, DW_SPI_DMARDLR, 0xf);
- dw_writel(dws, DW_SPI_DMATDLR, 0x10);
+ dw_writel(dws, DW_SPI_DMARDLR, RX_BURST_LEVEL - 1);
+ dw_writel(dws, DW_SPI_DMATDLR, TX_BURST_LEVEL);
if (xfer->tx_buf) {
dma_ctrl |= SPI_DMA_TDMAE;
--
2.26.2
^ permalink raw reply related
* [PATCH v6 07/16] spi: dw: Use DMA max burst to set the request thresholds
From: Serge Semin @ 2020-05-29 13:11 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Serge Semin, Andy Shevchenko, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, Feng Tang, Rob Herring,
linux-mips, devicetree, linux-spi, linux-kernel
In-Reply-To: <20200529131205.31838-1-Sergey.Semin@baikalelectronics.ru>
Each channel of DMA controller may have a limited length of burst
transaction (number of IO operations performed at ones in a single
DMA client request). This parameter can be used to setup the most
optimal DMA Tx/Rx data level values. In order to avoid the Tx buffer
overrun we can set the DMA Tx level to be of FIFO depth minus the
maximum burst transactions length. To prevent the Rx buffer underflow
the DMA Rx level should be set to the maximum burst transactions length.
This commit setups the DMA channels and the DW SPI DMA Tx/Rx levels
in accordance with these rules.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v3:
- Use min() method to calculate the optimal burst values.
---
drivers/spi/spi-dw-mid.c | 37 +++++++++++++++++++++++++++++++++----
drivers/spi/spi-dw.h | 2 ++
2 files changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-dw-mid.c b/drivers/spi/spi-dw-mid.c
index 189b517f77fc..1cf9e3ffe07b 100644
--- a/drivers/spi/spi-dw-mid.c
+++ b/drivers/spi/spi-dw-mid.c
@@ -36,6 +36,31 @@ static bool mid_spi_dma_chan_filter(struct dma_chan *chan, void *param)
return true;
}
+static void mid_spi_maxburst_init(struct dw_spi *dws)
+{
+ struct dma_slave_caps caps;
+ u32 max_burst, def_burst;
+ int ret;
+
+ def_burst = dws->fifo_len / 2;
+
+ ret = dma_get_slave_caps(dws->rxchan, &caps);
+ if (!ret && caps.max_burst)
+ max_burst = caps.max_burst;
+ else
+ max_burst = RX_BURST_LEVEL;
+
+ dws->rxburst = min(max_burst, def_burst);
+
+ ret = dma_get_slave_caps(dws->txchan, &caps);
+ if (!ret && caps.max_burst)
+ max_burst = caps.max_burst;
+ else
+ max_burst = TX_BURST_LEVEL;
+
+ dws->txburst = min(max_burst, def_burst);
+}
+
static int mid_spi_dma_init_mfld(struct device *dev, struct dw_spi *dws)
{
struct dw_dma_slave slave = {
@@ -73,6 +98,8 @@ static int mid_spi_dma_init_mfld(struct device *dev, struct dw_spi *dws)
init_completion(&dws->dma_completion);
+ mid_spi_maxburst_init(dws);
+
return 0;
free_rxchan:
@@ -100,6 +127,8 @@ static int mid_spi_dma_init_generic(struct device *dev, struct dw_spi *dws)
init_completion(&dws->dma_completion);
+ mid_spi_maxburst_init(dws);
+
return 0;
}
@@ -229,7 +258,7 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_tx(struct dw_spi *dws,
memset(&txconf, 0, sizeof(txconf));
txconf.direction = DMA_MEM_TO_DEV;
txconf.dst_addr = dws->dma_addr;
- txconf.dst_maxburst = TX_BURST_LEVEL;
+ txconf.dst_maxburst = dws->txburst;
txconf.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
txconf.dst_addr_width = convert_dma_width(dws->n_bytes);
txconf.device_fc = false;
@@ -321,7 +350,7 @@ static struct dma_async_tx_descriptor *dw_spi_dma_prepare_rx(struct dw_spi *dws,
memset(&rxconf, 0, sizeof(rxconf));
rxconf.direction = DMA_DEV_TO_MEM;
rxconf.src_addr = dws->dma_addr;
- rxconf.src_maxburst = RX_BURST_LEVEL;
+ rxconf.src_maxburst = dws->rxburst;
rxconf.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
rxconf.src_addr_width = convert_dma_width(dws->n_bytes);
rxconf.device_fc = false;
@@ -346,8 +375,8 @@ static int mid_spi_dma_setup(struct dw_spi *dws, struct spi_transfer *xfer)
{
u16 imr = 0, dma_ctrl = 0;
- dw_writel(dws, DW_SPI_DMARDLR, RX_BURST_LEVEL - 1);
- dw_writel(dws, DW_SPI_DMATDLR, TX_BURST_LEVEL);
+ dw_writel(dws, DW_SPI_DMARDLR, dws->rxburst - 1);
+ dw_writel(dws, DW_SPI_DMATDLR, dws->fifo_len - dws->txburst);
if (xfer->tx_buf) {
dma_ctrl |= SPI_DMA_TDMAE;
diff --git a/drivers/spi/spi-dw.h b/drivers/spi/spi-dw.h
index 9585d0c83a6d..9247670fcdfb 100644
--- a/drivers/spi/spi-dw.h
+++ b/drivers/spi/spi-dw.h
@@ -142,7 +142,9 @@ struct dw_spi {
/* DMA info */
struct dma_chan *txchan;
+ u32 txburst;
struct dma_chan *rxchan;
+ u32 rxburst;
unsigned long dma_chan_busy;
dma_addr_t dma_addr; /* phy address of the Data register */
const struct dw_spi_dma_ops *dma_ops;
--
2.26.2
^ permalink raw reply related
* [PATCH v6 08/16] spi: dw: Fix Rx-only DMA transfers
From: Serge Semin @ 2020-05-29 13:11 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Serge Semin, Andy Shevchenko, Georgy Vlasov,
Ramil Zaripov, Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann,
Feng Tang, Rob Herring, linux-mips, devicetree, linux-spi,
linux-kernel
In-Reply-To: <20200529131205.31838-1-Sergey.Semin@baikalelectronics.ru>
Tx-only DMA transfers are working perfectly fine since in this case
the code just ignores the Rx FIFO overflow interrupts. But it turns
out the SPI Rx-only transfers are broken since nothing pushing any
data to the shift registers, so the Rx FIFO is left empty and the
SPI core subsystems just returns a timeout error. Since DW DMAC
driver doesn't support something like cyclic write operations of
a single byte to a device register, the only way to support the
Rx-only SPI transfers is to fake it by using a dummy Tx-buffer.
This is what we intend to fix in this commit by setting the
SPI_CONTROLLER_MUST_TX flag for DMA-capable platform.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
drivers/spi/spi-dw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-dw.c b/drivers/spi/spi-dw.c
index 6939e003e3e9..4d1849699a12 100644
--- a/drivers/spi/spi-dw.c
+++ b/drivers/spi/spi-dw.c
@@ -515,6 +515,7 @@ int dw_spi_add_host(struct device *dev, struct dw_spi *dws)
dev_warn(dev, "DMA init failed\n");
} else {
master->can_dma = dws->dma_ops->can_dma;
+ master->flags |= SPI_CONTROLLER_MUST_TX;
}
}
--
2.26.2
^ permalink raw reply related
* [PATCH v6 00/16] spi: dw: Add generic DW DMA controller support
From: Serge Semin @ 2020-05-29 13:11 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Maxim Kaurkin, Pavel Parkhomenko,
Ekaterina Skachko, Vadim Vlasov, Alexey Kolotnikov,
Thomas Bogendoerfer, Arnd Bergmann, Andy Shevchenko, Feng Tang,
Rob Herring, linux-mips, linux-spi, devicetree, linux-kernel
Baikal-T1 SoC provides a DW DMA controller to perform low-speed peripherals
Mem-to-Dev and Dev-to-Mem transaction. This is also applicable to the DW
APB SSI devices embedded into the SoC. Currently the DMA-based transfers
are supported by the DW APB SPI driver only as a middle layer code for
Intel MID/Elkhart PCI devices. Seeing the same code can be used for normal
platform DMAC device we introduced a set of patches to fix it within this
series.
First of all we need to add the Tx and Rx DMA channels support into the DW
APB SSI binding. Then there are several fixes and cleanups provided as a
initial preparation for the Generic DMA support integration: add Tx/Rx
finish wait methods, clear DMAC register when done or stopped, Fix native
CS being unset, enable interrupts in accordance with DMA xfer mode,
discard static DW DMA slave structures, discard unused void priv pointer
and dma_width member of the dw_spi structure, provide the DMA Tx/Rx burst
length parametrisation and make sure it's optionally set in accordance
with the DMA max-burst capability.
In order to have the DW APB SSI MMIO driver working with DMA we need to
initialize the paddr field with the physical base address of the DW APB SSI
registers space. Then we unpin the Intel MID specific code from the
generic DMA one and placed it into the spi-dw-pci.c driver, which is a
better place for it anyway. After that the naming cleanups are performed
since the code is going to be used for a generic DMAC device. Finally the
Generic DMA initialization can be added to the generic version of the
DW APB SSI IP.
Last but not least we traditionally convert the legacy plain text-based
dt-binding file with yaml-based one and as a cherry on a cake replace
the manually written DebugFS registers read method with a ready-to-use
for the same purpose regset32 DebugFS interface usage.
This patchset is rebased and tested on the spi/for-next (5.7-rc5):
base-commit: fe9fce6b2cf3 ("Merge remote-tracking branch 'spi/for-5.8' into spi-next")
Link: https://lore.kernel.org/linux-spi/20200508132943.9826-1-Sergey.Semin@baikalelectronics.ru/
Changelog v2:
- Rebase on top of the spi repository for-next branch.
- Move bindings conversion patch to the tail of the series.
- Move fixes to the head of the series.
- Apply as many changes as possible to be applied the Generic DMA
functionality support is added and the spi-dw-mid is moved to the
spi-dw-dma driver.
- Discard patch "spi: dw: Fix dma_slave_config used partly uninitialized"
since the problem has already been fixed.
- Add new patch "spi: dw: Discard unused void priv pointer".
- Add new patch "spi: dw: Discard dma_width member of the dw_spi structure".
n_bytes member of the DW SPI data can be used instead.
- Build the DMA functionality into the DW APB SSI core if required instead
of creating a separate kernel module.
- Use conditional statement instead of the ternary operator in the ref
clock getter.
Link: https://lore.kernel.org/linux-spi/20200515104758.6934-1-Sergey.Semin@baikalelectronics.ru/
Changelog v3:
- Use spi_delay_exec() method to wait for the DMA operation completion.
- Explicitly initialize the dw_dma_slave members on stack.
- Discard the dws->fifo_len utilization in the Tx FIFO DMA threshold
setting from the patch where we just add the default burst length
constants.
- Use min() method to calculate the optimal burst values.
- Add new patch which moves the spi-dw.c source file to spi-dw-core.c in
order to preserve the DW APB SSI core driver name.
- Add commas in the debugfs_reg32 structure initializer and after the last
entry of the dw_spi_dbgfs_regs array.
Link: https://lore.kernel.org/linux-spi/20200521012206.14472-1-Sergey.Semin@baikalelectronics.ru
Changelog v4:
- Get back ndelay() method to wait for an SPI transfer completion.
spi_delay_exec() isn't suitable for the atomic context.
Link: https://lore.kernel.org/linux-spi/20200522000806.7381-1-Sergey.Semin@baikalelectronics.ru
Changelog v5:
- Refactor the Tx/Rx DMA-based SPI transfers wait methods.
- Add a new patch "spi: dw: Set xfer effective_speed_hz".
- Add a new patch "spi: dw: Return any value retrieved from the
dma_transfer callback" as a preparation patch before implementing
the local DMA, Tx SPI and Rx SPI transfers wait methods.
- Add a new patch "spi: dw: Locally wait for the DMA transactions
completion", which provides a local DMA transaction complete
method
- Create a dedicated patch which adds the Rx-done wait method:
"spi: dw: Add SPI Rx-done wait method to DMA-based transfer".
- Add more detailed description of the problems the Tx/Rx-wait
methods-related patches fix.
- Wait for the SPI Tx and Rx transfers being finished in the
mid_spi_dma_transfer() method executed in the task context.
- Use spi_delay_exec() to wait for the SPI Tx/Rx completion, since now
the driver calls the wait methods in the kernel thread context.
- Use SPI_DELAY_UNIT_SCK spi_delay unit for Tx-wait delay, since SPI
xfer's are now have the effective_speed_hz initialized.
- Rx-wait for a delay correlated with the APB/SSI synchronous clock
rate instead of using the SPI bus clock rate.
Link: https://lore.kernel.org/linux-spi/20200529035915.20790-1-Sergey.Semin@baikalelectronics.ru
Changelog v6:
- Provide a more detailed description of the patch:
2901db35bea1 ("spi: dw: Locally wait for the DMA transfers completion")
- Calculate the Rx delay with better accuracy by moving 4-multiplication
to the head of the formulae:
ns = 4U * NSEC_PER_SEC / dws->max_freq * nents.
Co-developed-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Signed-off-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
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>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (16):
spi: dw: Set xfer effective_speed_hz
spi: dw: Return any value retrieved from the dma_transfer callback
spi: dw: Locally wait for the DMA transfers completion
spi: dw: Add SPI Tx-done wait method to DMA-based transfer
spi: dw: Add SPI Rx-done wait method to DMA-based transfer
spi: dw: Parameterize the DMA Rx/Tx burst length
spi: dw: Use DMA max burst to set the request thresholds
spi: dw: Fix Rx-only DMA transfers
spi: dw: Add core suffix to the DW APB SSI core source file
spi: dw: Move Non-DMA code to the DW PCIe-SPI driver
spi: dw: Remove DW DMA code dependency from DW_DMAC_PCI
spi: dw: Add DW SPI DMA/PCI/MMIO dependency on the DW SPI core
spi: dw: Cleanup generic DW DMA code namings
spi: dw: Add DMA support to the DW SPI MMIO driver
spi: dw: Use regset32 DebugFS method to create regdump file
dt-bindings: spi: Convert DW SPI binding to DT schema
.../bindings/spi/snps,dw-apb-ssi.txt | 44 --
.../bindings/spi/snps,dw-apb-ssi.yaml | 127 +++++
.../devicetree/bindings/spi/spi-dw.txt | 24 -
drivers/spi/Kconfig | 15 +-
drivers/spi/Makefile | 5 +-
drivers/spi/{spi-dw.c => spi-dw-core.c} | 95 ++--
drivers/spi/spi-dw-dma.c | 482 ++++++++++++++++++
drivers/spi/spi-dw-mid.c | 382 --------------
drivers/spi/spi-dw-mmio.c | 4 +
drivers/spi/spi-dw-pci.c | 50 +-
drivers/spi/spi-dw.h | 20 +-
11 files changed, 719 insertions(+), 529 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
create mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-dw.txt
rename drivers/spi/{spi-dw.c => spi-dw-core.c} (82%)
create mode 100644 drivers/spi/spi-dw-dma.c
delete mode 100644 drivers/spi/spi-dw-mid.c
--
2.26.2
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: r8a7742: Add thermal device to DT
From: Geert Uytterhoeven @ 2020-05-29 13:15 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590614320-30160-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Wed, May 27, 2020 at 11:19 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> This patch instantiates the thermal sensor module with thermal-zone
> support.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v8 0/5] Preparation to the generic ECC engine abstraction
From: Miquel Raynal @ 2020-05-29 13:15 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Boris Brezillon, Thomas Petazzoni, Paul Cercueil, Chuanhong Guo,
Weijie Gao, linux-arm-kernel, Mason Yang, Julien Su,
Miquel Raynal
This is a respin of the end of my previous series, just the patches which needed to be fixed.
Changes in v8:
* Split "Convert generic NAND bits to ECC framework" into several peaces:
> added two helpers
> converted SPI-NAND then raw-NAND.
* Fixed a comment.
* Used the _ooblayout suffix instead of _layout.
Miquel Raynal (5):
mtd: nand: Convert generic NAND bits to use the ECC framework
mtd: rawnand: Hide the generic OOB layout objects behind helpers
mtd: rawnand: Write a compatibility layer
mtd: rawnand: Move generic OOB layouts to the ECC framework
mtd: rawnand: Move the user input parsing bits to the ECC framework
drivers/mtd/nand/ecc.c | 314 +++++++++++++++
drivers/mtd/nand/raw/Kconfig | 1 +
drivers/mtd/nand/raw/arasan-nand-controller.c | 2 +-
drivers/mtd/nand/raw/atmel/nand-controller.c | 5 +-
drivers/mtd/nand/raw/davinci_nand.c | 3 +-
drivers/mtd/nand/raw/denali.c | 3 +
.../mtd/nand/raw/ingenic/ingenic_nand_drv.c | 6 +-
drivers/mtd/nand/raw/nand_base.c | 380 ++++--------------
drivers/mtd/nand/raw/nand_toshiba.c | 2 +-
drivers/mtd/nand/raw/sunxi_nand.c | 3 +-
drivers/mtd/nand/raw/tegra_nand.c | 5 +-
drivers/mtd/nand/raw/vf610_nfc.c | 2 +-
include/linux/mtd/nand.h | 23 +-
include/linux/mtd/rawnand.h | 17 +-
14 files changed, 428 insertions(+), 338 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH v8 1/5] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Miquel Raynal @ 2020-05-29 13:15 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Boris Brezillon, Thomas Petazzoni, Paul Cercueil, Chuanhong Guo,
Weijie Gao, linux-arm-kernel, Mason Yang, Julien Su,
Miquel Raynal
In-Reply-To: <20200529131602.21532-1-miquel.raynal@bootlin.com>
Embed a generic NAND ECC high-level object in the nand_device
structure to carry all the ECC engine configuration/data.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/raw/nand_base.c | 4 +++-
include/linux/mtd/nand.h | 12 ++++++------
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index e8e22d79f422..ed0f642be993 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5984,7 +5984,9 @@ static int nand_scan_tail(struct nand_chip *chip)
/* ECC sanity check: warn if it's too weak */
if (!nand_ecc_strength_good(chip))
pr_warn("WARNING: %s: the ECC used on your system (%db/%dB) is too weak compared to the one required by the NAND chip (%db/%dB)\n",
- mtd->name, chip->ecc.strength, chip->ecc.size,
+ mtd->name,
+ nanddev_get_ecc_conf(&chip->base)->strength,
+ nanddev_get_ecc_conf(&chip->base)->step_size,
nanddev_get_ecc_requirements(&chip->base)->strength,
nanddev_get_ecc_requirements(&chip->base)->step_size);
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 488d8b14b9ae..f5cc0aee565c 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -290,7 +290,7 @@ struct nand_ecc {
* struct nand_device - NAND device
* @mtd: MTD instance attached to the NAND device
* @memorg: memory layout
- * @eccreq: ECC requirements
+ * @ecc: NAND ECC object attached to the NAND device
* @rowconv: position to row address converter
* @bbt: bad block table info
* @ops: NAND operations attached to the NAND device
@@ -298,8 +298,8 @@ struct nand_ecc {
* Generic NAND object. Specialized NAND layers (raw NAND, SPI NAND, OneNAND)
* should declare their own NAND object embedding a nand_device struct (that's
* how inheritance is done).
- * struct_nand_device->memorg and struct_nand_device->eccreq should be filled
- * at device detection time to reflect the NAND device
+ * struct_nand_device->memorg and struct_nand_device->ecc.requirements should
+ * be filled at device detection time to reflect the NAND device
* capabilities/requirements. Once this is done nanddev_init() can be called.
* It will take care of converting NAND information into MTD ones, which means
* the specialized NAND layers should never manually tweak
@@ -308,7 +308,7 @@ struct nand_ecc {
struct nand_device {
struct mtd_info mtd;
struct nand_memory_organization memorg;
- struct nand_ecc_props eccreq;
+ struct nand_ecc ecc;
struct nand_row_converter rowconv;
struct nand_bbt bbt;
const struct nand_ops *ops;
@@ -519,7 +519,7 @@ nanddev_get_memorg(struct nand_device *nand)
const struct nand_ecc_props *
nanddev_get_ecc_conf(struct nand_device *nand)
{
- return &nand->eccreq;
+ return &nand->ecc.ctx.conf;
}
/**
@@ -530,7 +530,7 @@ nanddev_get_ecc_conf(struct nand_device *nand)
const struct nand_ecc_props *
nanddev_get_ecc_requirements(struct nand_device *nand)
{
- return &nand->eccreq;
+ return &nand->ecc.requirements;
}
int nanddev_init(struct nand_device *nand, const struct nand_ops *ops,
--
2.20.1
^ permalink raw reply related
* [PATCH v8 2/5] mtd: rawnand: Hide the generic OOB layout objects behind helpers
From: Miquel Raynal @ 2020-05-29 13:15 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Boris Brezillon, Thomas Petazzoni, Paul Cercueil, Chuanhong Guo,
Weijie Gao, linux-arm-kernel, Mason Yang, Julien Su,
Miquel Raynal
In-Reply-To: <20200529131602.21532-1-miquel.raynal@bootlin.com>
Stop exposing these objects, create helpers to retrieve them instead.
Also export an helper for the Hamming large page ops for later use.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/raw/arasan-nand-controller.c | 2 +-
drivers/mtd/nand/raw/atmel/nand-controller.c | 2 +-
drivers/mtd/nand/raw/davinci_nand.c | 3 +-
.../mtd/nand/raw/ingenic/ingenic_nand_drv.c | 6 ++--
drivers/mtd/nand/raw/nand_base.c | 35 ++++++++++++++-----
drivers/mtd/nand/raw/nand_toshiba.c | 2 +-
drivers/mtd/nand/raw/vf610_nfc.c | 2 +-
include/linux/mtd/rawnand.h | 5 +--
8 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/mtd/nand/raw/arasan-nand-controller.c b/drivers/mtd/nand/raw/arasan-nand-controller.c
index a0b5c539ca73..6fe61393bd26 100644
--- a/drivers/mtd/nand/raw/arasan-nand-controller.c
+++ b/drivers/mtd/nand/raw/arasan-nand-controller.c
@@ -980,7 +980,7 @@ static int anfc_init_hw_ecc_controller(struct arasan_nfc *nfc,
return -EINVAL;
}
- mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
+ mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
ecc->steps = mtd->writesize / ecc->size;
ecc->algo = NAND_ECC_ALGO_BCH;
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
index 3fba91d7991a..08df7f23b859 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -1108,7 +1108,7 @@ static int atmel_nand_pmecc_init(struct nand_chip *chip)
chip->options |= NAND_NO_SUBPAGE_WRITE;
- mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
+ mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
return 0;
}
diff --git a/drivers/mtd/nand/raw/davinci_nand.c b/drivers/mtd/nand/raw/davinci_nand.c
index 58966a9706b1..427f320fb79b 100644
--- a/drivers/mtd/nand/raw/davinci_nand.c
+++ b/drivers/mtd/nand/raw/davinci_nand.c
@@ -645,7 +645,8 @@ static int davinci_nand_attach_chip(struct nand_chip *chip)
mtd_set_ooblayout(mtd,
&hwecc4_small_ooblayout_ops);
} else if (chunks == 4 || chunks == 8) {
- mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
+ mtd_set_ooblayout(mtd,
+ nand_get_large_page_ooblayout());
info->chip.ecc.read_page = nand_davinci_read_page_hwecc_oob_first;
} else {
return -EIO;
diff --git a/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c b/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
index 70309f18124c..0e9d426fe4f2 100644
--- a/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
+++ b/drivers/mtd/nand/raw/ingenic/ingenic_nand_drv.c
@@ -243,8 +243,10 @@ static int ingenic_nand_attach_chip(struct nand_chip *chip)
/* For legacy reasons we use a different layout on the qi,lb60 board. */
if (of_machine_is_compatible("qi,lb60"))
mtd_set_ooblayout(mtd, &qi_lb60_ooblayout_ops);
- else
+ else if (nfc->soc_info->oob_layout)
mtd_set_ooblayout(mtd, nfc->soc_info->oob_layout);
+ else
+ mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
return 0;
}
@@ -532,7 +534,6 @@ static const struct jz_soc_info jz4740_soc_info = {
.data_offset = 0x00000000,
.cmd_offset = 0x00008000,
.addr_offset = 0x00010000,
- .oob_layout = &nand_ooblayout_lp_ops,
};
static const struct jz_soc_info jz4725b_soc_info = {
@@ -546,7 +547,6 @@ static const struct jz_soc_info jz4780_soc_info = {
.data_offset = 0x00000000,
.cmd_offset = 0x00400000,
.addr_offset = 0x00800000,
- .oob_layout = &nand_ooblayout_lp_ops,
};
static const struct of_device_id ingenic_nand_dt_match[] = {
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index ed0f642be993..f120b0b4f591 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -95,11 +95,16 @@ static int nand_ooblayout_free_sp(struct mtd_info *mtd, int section,
return 0;
}
-const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
+static const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
.ecc = nand_ooblayout_ecc_sp,
.free = nand_ooblayout_free_sp,
};
-EXPORT_SYMBOL_GPL(nand_ooblayout_sp_ops);
+
+const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void)
+{
+ return &nand_ooblayout_sp_ops;
+}
+EXPORT_SYMBOL_GPL(nand_get_small_page_ooblayout);
static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
struct mtd_oob_region *oobregion)
@@ -131,11 +136,16 @@ static int nand_ooblayout_free_lp(struct mtd_info *mtd, int section,
return 0;
}
-const struct mtd_ooblayout_ops nand_ooblayout_lp_ops = {
+static const struct mtd_ooblayout_ops nand_ooblayout_lp_ops = {
.ecc = nand_ooblayout_ecc_lp,
.free = nand_ooblayout_free_lp,
};
-EXPORT_SYMBOL_GPL(nand_ooblayout_lp_ops);
+
+const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void)
+{
+ return &nand_ooblayout_lp_ops;
+}
+EXPORT_SYMBOL_GPL(nand_get_large_page_ooblayout);
/*
* Support the old "large page" layout used for 1-bit Hamming ECC where ECC
@@ -205,6 +215,12 @@ static const struct mtd_ooblayout_ops nand_ooblayout_lp_hamming_ops = {
.free = nand_ooblayout_free_lp_hamming,
};
+const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void)
+{
+ return &nand_ooblayout_lp_hamming_ops;
+}
+EXPORT_SYMBOL_GPL(nand_get_large_page_hamming_ooblayout);
+
static int nand_pairing_dist3_get_info(struct mtd_info *mtd, int page,
struct mtd_pairing_info *info)
{
@@ -5382,7 +5398,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
return -EINVAL;
}
- mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
+ mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
}
@@ -5391,7 +5407,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
* used, otherwise we don't know how many bytes can really be
* used.
*/
- if (mtd->ooblayout == &nand_ooblayout_lp_ops &&
+ if (mtd->ooblayout == nand_get_large_page_ooblayout() &&
ecc->options & NAND_ECC_MAXIMIZE) {
int steps, bytes;
@@ -5793,11 +5809,12 @@ static int nand_scan_tail(struct nand_chip *chip)
switch (mtd->oobsize) {
case 8:
case 16:
- mtd_set_ooblayout(mtd, &nand_ooblayout_sp_ops);
+ mtd_set_ooblayout(mtd, nand_get_small_page_ooblayout());
break;
case 64:
case 128:
- mtd_set_ooblayout(mtd, &nand_ooblayout_lp_hamming_ops);
+ mtd_set_ooblayout(mtd,
+ nand_get_large_page_hamming_ooblayout());
break;
default:
/*
@@ -5809,7 +5826,7 @@ static int nand_scan_tail(struct nand_chip *chip)
*/
if (ecc->engine_type == NAND_ECC_ENGINE_TYPE_NONE) {
mtd_set_ooblayout(mtd,
- &nand_ooblayout_lp_ops);
+ nand_get_large_page_ooblayout());
break;
}
diff --git a/drivers/mtd/nand/raw/nand_toshiba.c b/drivers/mtd/nand/raw/nand_toshiba.c
index 8fcf40d0ba0a..3174914e33e0 100644
--- a/drivers/mtd/nand/raw/nand_toshiba.c
+++ b/drivers/mtd/nand/raw/nand_toshiba.c
@@ -140,7 +140,7 @@ static void toshiba_nand_benand_init(struct nand_chip *chip)
chip->options |= NAND_SUBPAGE_READ;
- mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
+ mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
}
static void toshiba_nand_decode_id(struct nand_chip *chip)
diff --git a/drivers/mtd/nand/raw/vf610_nfc.c b/drivers/mtd/nand/raw/vf610_nfc.c
index 8ee2c1f539c4..50dc0c93140c 100644
--- a/drivers/mtd/nand/raw/vf610_nfc.c
+++ b/drivers/mtd/nand/raw/vf610_nfc.c
@@ -779,7 +779,7 @@ static int vf610_nfc_attach_chip(struct nand_chip *chip)
mtd->oobsize = 64;
/* Use default large page ECC layout defined in NAND core */
- mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
+ mtd_set_ooblayout(mtd, nand_get_large_page_ooblayout());
if (chip->ecc.strength == 32) {
nfc->ecc_mode = ECC_60_BYTE;
chip->ecc.bytes = 60;
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 8f7f1cce3b4b..f3eb47c09e57 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -1159,8 +1159,9 @@ struct nand_chip {
int (*unlock_area)(struct nand_chip *chip, loff_t ofs, uint64_t len);
};
-extern const struct mtd_ooblayout_ops nand_ooblayout_sp_ops;
-extern const struct mtd_ooblayout_ops nand_ooblayout_lp_ops;
+const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void);
+const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void);
+const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void);
static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
{
--
2.20.1
^ permalink raw reply related
* [PATCH v8 3/5] mtd: rawnand: Write a compatibility layer
From: Miquel Raynal @ 2020-05-29 13:16 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Boris Brezillon, Thomas Petazzoni, Paul Cercueil, Chuanhong Guo,
Weijie Gao, linux-arm-kernel, Mason Yang, Julien Su,
Miquel Raynal
In-Reply-To: <20200529131602.21532-1-miquel.raynal@bootlin.com>
Before moving generic bits from the raw NAND core to the generic NAND
core, let's disociate clearly what is a rawnand legacy property, and
what should be made public to other NAND users.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/raw/nand_base.c | 158 +++++++++++++++++++++----------
include/linux/mtd/rawnand.h | 12 ---
2 files changed, 107 insertions(+), 63 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index f120b0b4f591..8dc230892b90 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5029,14 +5029,6 @@ static int nand_detect(struct nand_chip *chip, struct nand_flash_dev *type)
return ret;
}
-static const char * const nand_ecc_modes[] = {
- [NAND_ECC_NONE] = "none",
- [NAND_ECC_SOFT] = "soft",
- [NAND_ECC_HW] = "hw",
- [NAND_ECC_HW_SYNDROME] = "hw_syndrome",
- [NAND_ECC_ON_DIE] = "on-die",
-};
-
static const char * const nand_ecc_placement[] = {
[NAND_ECC_PLACEMENT_OOB] = "oob",
[NAND_ECC_PLACEMENT_INTERLEAVED] = "interleaved",
@@ -5045,7 +5037,30 @@ static const char * const nand_ecc_placement[] = {
static enum nand_ecc_engine_type
of_get_nand_ecc_engine_type(struct device_node *np)
{
- enum nand_ecc_mode eng_type;
+ return NAND_ECC_ENGINE_TYPE_INVALID;
+}
+
+static enum nand_ecc_engine_type
+of_get_rawnand_ecc_engine_type_legacy(struct device_node *np)
+{
+ enum nand_ecc_legacy_mode {
+ NAND_ECC_INVALID,
+ NAND_ECC_NONE,
+ NAND_ECC_SOFT,
+ NAND_ECC_SOFT_BCH,
+ NAND_ECC_HW,
+ NAND_ECC_HW_SYNDROME,
+ NAND_ECC_ON_DIE,
+ };
+ const char * const nand_ecc_legacy_modes[] = {
+ [NAND_ECC_NONE] = "none",
+ [NAND_ECC_SOFT] = "soft",
+ [NAND_ECC_SOFT_BCH] = "soft_bch",
+ [NAND_ECC_HW] = "hw",
+ [NAND_ECC_HW_SYNDROME] = "hw_syndrome",
+ [NAND_ECC_ON_DIE] = "on-die",
+ };
+ enum nand_ecc_legacy_mode eng_type;
const char *pm;
int err;
@@ -5054,12 +5069,13 @@ of_get_nand_ecc_engine_type(struct device_node *np)
return NAND_ECC_ENGINE_TYPE_INVALID;
for (eng_type = NAND_ECC_NONE;
- eng_type < ARRAY_SIZE(nand_ecc_modes); eng_type++) {
- if (!strcasecmp(pm, nand_ecc_modes[eng_type])) {
+ eng_type < ARRAY_SIZE(nand_ecc_legacy_modes); eng_type++) {
+ if (!strcasecmp(pm, nand_ecc_legacy_modes[eng_type])) {
switch (eng_type) {
case NAND_ECC_NONE:
return NAND_ECC_ENGINE_TYPE_NONE;
case NAND_ECC_SOFT:
+ case NAND_ECC_SOFT_BCH:
return NAND_ECC_ENGINE_TYPE_SOFT;
case NAND_ECC_HW:
case NAND_ECC_HW_SYNDROME:
@@ -5072,14 +5088,6 @@ of_get_nand_ecc_engine_type(struct device_node *np)
}
}
- /*
- * For backward compatibility we support few obsoleted values that don't
- * have their mappings into the nand_ecc_engine_providers enum anymore
- * (they were merged with other enums).
- */
- if (!strcasecmp(pm, "soft_bch"))
- return NAND_ECC_ENGINE_TYPE_SOFT;
-
return NAND_ECC_ENGINE_TYPE_INVALID;
}
@@ -5091,17 +5099,22 @@ enum nand_ecc_placement of_get_nand_ecc_placement(struct device_node *np)
err = of_property_read_string(np, "nand-ecc-placement", &pm);
if (!err) {
- for (placement = NAND_ECC_PLACEMENT_INTERLEAVED;
+ for (placement = NAND_ECC_PLACEMENT_OOB;
placement < ARRAY_SIZE(nand_ecc_placement); placement++) {
if (!strcasecmp(pm, nand_ecc_placement[placement]))
return placement;
}
}
- /*
- * For backward compatibility we support few obsoleted values that don't
- * have their mappings into the nand_ecc_placement enum anymore.
- */
+ return NAND_ECC_PLACEMENT_UNKNOWN;
+}
+
+enum nand_ecc_placement
+of_get_rawnand_ecc_placement_legacy(struct device_node *np)
+{
+ const char *pm;
+ int err;
+
err = of_property_read_string(np, "nand-ecc-mode", &pm);
if (!err) {
if (!strcasecmp(pm, "hw_syndrome"))
@@ -5133,10 +5146,14 @@ static enum nand_ecc_algo of_get_nand_ecc_algo(struct device_node *np)
}
}
- /*
- * For backward compatibility we also read "nand-ecc-mode" checking
- * for some obsoleted values that were specifying ECC algorithm.
- */
+ return NAND_ECC_ALGO_UNKNOWN;
+}
+
+static enum nand_ecc_algo of_get_rawnand_ecc_algo_legacy(struct device_node *np)
+{
+ const char *pm;
+ int err;
+
err = of_property_read_string(np, "nand-ecc-mode", &pm);
if (!err) {
if (!strcasecmp(pm, "soft"))
@@ -5166,6 +5183,41 @@ static int of_get_nand_ecc_strength(struct device_node *np)
return ret ? ret : val;
}
+static void nand_ecc_read_user_conf(struct nand_chip *chip)
+{
+ struct device_node *dn = nand_get_flash_node(chip);
+ struct nand_device *nand = &chip->base;
+ int strength, size;
+
+ nand->ecc.user_conf.engine_type = of_get_nand_ecc_engine_type(dn);
+ nand->ecc.user_conf.algo = of_get_nand_ecc_algo(dn);
+ nand->ecc.user_conf.placement = of_get_nand_ecc_placement(dn);
+
+ strength = of_get_nand_ecc_strength(dn);
+ if (strength >= 0)
+ nand->ecc.user_conf.strength = strength;
+
+ size = of_get_nand_ecc_step_size(dn);
+ if (size >= 0)
+ nand->ecc.user_conf.step_size = size;
+}
+
+static void rawnand_ecc_read_legacy_user_conf(struct nand_chip *chip)
+{
+ struct device_node *dn = nand_get_flash_node(chip);
+ struct nand_device *nand = &chip->base;
+ struct nand_ecc_props *user_conf = &nand->ecc.user_conf;
+
+ if (user_conf->engine_type != NAND_ECC_ENGINE_TYPE_INVALID)
+ user_conf->engine_type = of_get_rawnand_ecc_engine_type_legacy(dn);
+
+ if (user_conf->algo != NAND_ECC_ALGO_UNKNOWN)
+ user_conf->algo = of_get_rawnand_ecc_algo_legacy(dn);
+
+ if (user_conf->placement != NAND_ECC_PLACEMENT_UNKNOWN)
+ user_conf->placement = of_get_rawnand_ecc_placement_legacy(dn);
+}
+
static int of_get_nand_bus_width(struct device_node *np)
{
u32 val;
@@ -5187,12 +5239,10 @@ static bool of_get_nand_on_flash_bbt(struct device_node *np)
return of_property_read_bool(np, "nand-on-flash-bbt");
}
-static int nand_dt_init(struct nand_chip *chip)
+static int rawnand_dt_init(struct nand_chip *chip)
{
+ struct nand_device *nand = mtd_to_nanddev(nand_to_mtd(chip));
struct device_node *dn = nand_get_flash_node(chip);
- enum nand_ecc_engine_type ecc_type;
- enum nand_ecc_algo ecc_algo;
- int ecc_strength, ecc_step;
if (!dn)
return 0;
@@ -5206,27 +5256,33 @@ static int nand_dt_init(struct nand_chip *chip)
if (of_get_nand_on_flash_bbt(dn))
chip->bbt_options |= NAND_BBT_USE_FLASH;
- ecc_type = of_get_nand_ecc_engine_type(dn);
- ecc_algo = of_get_nand_ecc_algo(dn);
- chip->ecc.placement = of_get_nand_ecc_placement(dn);
- ecc_strength = of_get_nand_ecc_strength(dn);
- ecc_step = of_get_nand_ecc_step_size(dn);
-
- if (ecc_type != NAND_ECC_ENGINE_TYPE_INVALID)
- chip->ecc.engine_type = ecc_type;
-
- if (ecc_algo != NAND_ECC_ALGO_UNKNOWN)
- chip->ecc.algo = ecc_algo;
-
- if (ecc_strength >= 0)
- chip->ecc.strength = ecc_strength;
-
- if (ecc_step > 0)
- chip->ecc.size = ecc_step;
-
if (of_property_read_bool(dn, "nand-ecc-maximize"))
chip->ecc.options |= NAND_ECC_MAXIMIZE;
+ nand_ecc_read_user_conf(chip);
+ rawnand_ecc_read_legacy_user_conf(chip);
+
+ /*
+ * If neither the user nor the NAND controller have requested a specific
+ * ECC engine type, we will default to NAND_ECC_ENGINE_TYPE_ON_HOST.
+ */
+ nand->ecc.defaults.engine_type = NAND_ECC_ENGINE_TYPE_ON_HOST;
+
+ /*
+ * Use the user requested engine type, unless there is none, in this
+ * case default to the NAND controller choice, otherwise fallback to
+ * the raw NAND default one.
+ */
+ if (nand->ecc.user_conf.engine_type != NAND_ECC_ENGINE_TYPE_INVALID)
+ chip->ecc.engine_type = nand->ecc.user_conf.engine_type;
+ if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_INVALID)
+ chip->ecc.engine_type = nand->ecc.defaults.engine_type;
+
+ chip->ecc.placement = nand->ecc.user_conf.placement;
+ chip->ecc.algo = nand->ecc.user_conf.algo;
+ chip->ecc.strength = nand->ecc.user_conf.strength;
+ chip->ecc.size = nand->ecc.user_conf.step_size;
+
return 0;
}
@@ -5263,7 +5319,7 @@ static int nand_scan_ident(struct nand_chip *chip, unsigned int maxchips,
/* Enforce the right timings for reset/detection */
onfi_fill_data_interface(chip, NAND_SDR_IFACE, 0);
- ret = nand_dt_init(chip);
+ ret = rawnand_dt_init(chip);
if (ret)
return ret;
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index f3eb47c09e57..b455cb22168f 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -80,18 +80,6 @@ struct nand_chip;
#define NAND_DATA_IFACE_CHECK_ONLY -1
-/*
- * Constants for ECC_MODES
- */
-enum nand_ecc_mode {
- NAND_ECC_INVALID,
- NAND_ECC_NONE,
- NAND_ECC_SOFT,
- NAND_ECC_HW,
- NAND_ECC_HW_SYNDROME,
- NAND_ECC_ON_DIE,
-};
-
/*
* Constants for Hardware ECC
*/
--
2.20.1
^ permalink raw reply related
* [PATCH v8 4/5] mtd: rawnand: Move generic OOB layouts to the ECC framework
From: Miquel Raynal @ 2020-05-29 13:16 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Boris Brezillon, Thomas Petazzoni, Paul Cercueil, Chuanhong Guo,
Weijie Gao, linux-arm-kernel, Mason Yang, Julien Su,
Miquel Raynal
In-Reply-To: <20200529131602.21532-1-miquel.raynal@bootlin.com>
These layouts can be used by any driver, move them to the ECC core.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc.c | 176 ++++++++++++++++++++++++++++++
drivers/mtd/nand/raw/Kconfig | 1 +
drivers/mtd/nand/raw/nand_base.c | 177 +------------------------------
include/linux/mtd/nand.h | 4 +
include/linux/mtd/rawnand.h | 5 +-
5 files changed, 183 insertions(+), 180 deletions(-)
diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
index f7300ba37167..ad08a047dfc5 100644
--- a/drivers/mtd/nand/ecc.c
+++ b/drivers/mtd/nand/ecc.c
@@ -152,6 +152,182 @@ int nand_ecc_finish_io_req(struct nand_device *nand,
}
EXPORT_SYMBOL(nand_ecc_finish_io_req);
+/* Define default oob placement schemes for large and small page devices */
+static int nand_ooblayout_ecc_sp(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ struct nand_device *nand = mtd_to_nanddev(mtd);
+ unsigned int total_ecc_bytes = nand->ecc.ctx.total;
+
+ if (section > 1)
+ return -ERANGE;
+
+ if (!section) {
+ oobregion->offset = 0;
+ if (mtd->oobsize == 16)
+ oobregion->length = 4;
+ else
+ oobregion->length = 3;
+ } else {
+ if (mtd->oobsize == 8)
+ return -ERANGE;
+
+ oobregion->offset = 6;
+ oobregion->length = total_ecc_bytes - 4;
+ }
+
+ return 0;
+}
+
+static int nand_ooblayout_free_sp(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ if (section > 1)
+ return -ERANGE;
+
+ if (mtd->oobsize == 16) {
+ if (section)
+ return -ERANGE;
+
+ oobregion->length = 8;
+ oobregion->offset = 8;
+ } else {
+ oobregion->length = 2;
+ if (!section)
+ oobregion->offset = 3;
+ else
+ oobregion->offset = 6;
+ }
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
+ .ecc = nand_ooblayout_ecc_sp,
+ .free = nand_ooblayout_free_sp,
+};
+
+const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void)
+{
+ return &nand_ooblayout_sp_ops;
+}
+EXPORT_SYMBOL_GPL(nand_get_small_page_ooblayout);
+
+static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ struct nand_device *nand = mtd_to_nanddev(mtd);
+ unsigned int total_ecc_bytes = nand->ecc.ctx.total;
+
+ if (section || !total_ecc_bytes)
+ return -ERANGE;
+
+ oobregion->length = total_ecc_bytes;
+ oobregion->offset = mtd->oobsize - oobregion->length;
+
+ return 0;
+}
+
+static int nand_ooblayout_free_lp(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ struct nand_device *nand = mtd_to_nanddev(mtd);
+ unsigned int total_ecc_bytes = nand->ecc.ctx.total;
+
+ if (section)
+ return -ERANGE;
+
+ oobregion->length = mtd->oobsize - total_ecc_bytes - 2;
+ oobregion->offset = 2;
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops nand_ooblayout_lp_ops = {
+ .ecc = nand_ooblayout_ecc_lp,
+ .free = nand_ooblayout_free_lp,
+};
+
+const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void)
+{
+ return &nand_ooblayout_lp_ops;
+}
+EXPORT_SYMBOL_GPL(nand_get_large_page_ooblayout);
+
+/*
+ * Support the old "large page" layout used for 1-bit Hamming ECC where ECC
+ * are placed at a fixed offset.
+ */
+static int nand_ooblayout_ecc_lp_hamming(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ struct nand_device *nand = mtd_to_nanddev(mtd);
+ unsigned int total_ecc_bytes = nand->ecc.ctx.total;
+
+ if (section)
+ return -ERANGE;
+
+ switch (mtd->oobsize) {
+ case 64:
+ oobregion->offset = 40;
+ break;
+ case 128:
+ oobregion->offset = 80;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ oobregion->length = total_ecc_bytes;
+ if (oobregion->offset + oobregion->length > mtd->oobsize)
+ return -ERANGE;
+
+ return 0;
+}
+
+static int nand_ooblayout_free_lp_hamming(struct mtd_info *mtd, int section,
+ struct mtd_oob_region *oobregion)
+{
+ struct nand_device *nand = mtd_to_nanddev(mtd);
+ unsigned int total_ecc_bytes = nand->ecc.ctx.total;
+ int ecc_offset = 0;
+
+ if (section < 0 || section > 1)
+ return -ERANGE;
+
+ switch (mtd->oobsize) {
+ case 64:
+ ecc_offset = 40;
+ break;
+ case 128:
+ ecc_offset = 80;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (section == 0) {
+ oobregion->offset = 2;
+ oobregion->length = ecc_offset - 2;
+ } else {
+ oobregion->offset = ecc_offset + total_ecc_bytes;
+ oobregion->length = mtd->oobsize - oobregion->offset;
+ }
+
+ return 0;
+}
+
+static const struct mtd_ooblayout_ops nand_ooblayout_lp_hamming_ops = {
+ .ecc = nand_ooblayout_ecc_lp_hamming,
+ .free = nand_ooblayout_free_lp_hamming,
+};
+
+const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void)
+{
+ return &nand_ooblayout_lp_hamming_ops;
+}
+EXPORT_SYMBOL_GPL(nand_get_large_page_hamming_ooblayout);
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 85280e327bfe..6ab3184ca8eb 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -13,6 +13,7 @@ config MTD_NAND_ECC_SW_HAMMING_SMC
menuconfig MTD_RAW_NAND
tristate "Raw/Parallel NAND Device Support"
select MTD_NAND_CORE
+ select MTD_NAND_ECC
select MTD_NAND_ECC_SW_HAMMING
help
This enables support for accessing all type of raw/parallel
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 8dc230892b90..afc3506468ba 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -34,6 +34,7 @@
#include <linux/mm.h>
#include <linux/types.h>
#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
#include <linux/mtd/nand_ecc.h>
#include <linux/mtd/nand_bch.h>
#include <linux/interrupt.h>
@@ -45,182 +46,6 @@
#include "internals.h"
-/* Define default oob placement schemes for large and small page devices */
-static int nand_ooblayout_ecc_sp(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
-
- if (section > 1)
- return -ERANGE;
-
- if (!section) {
- oobregion->offset = 0;
- if (mtd->oobsize == 16)
- oobregion->length = 4;
- else
- oobregion->length = 3;
- } else {
- if (mtd->oobsize == 8)
- return -ERANGE;
-
- oobregion->offset = 6;
- oobregion->length = ecc->total - 4;
- }
-
- return 0;
-}
-
-static int nand_ooblayout_free_sp(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- if (section > 1)
- return -ERANGE;
-
- if (mtd->oobsize == 16) {
- if (section)
- return -ERANGE;
-
- oobregion->length = 8;
- oobregion->offset = 8;
- } else {
- oobregion->length = 2;
- if (!section)
- oobregion->offset = 3;
- else
- oobregion->offset = 6;
- }
-
- return 0;
-}
-
-static const struct mtd_ooblayout_ops nand_ooblayout_sp_ops = {
- .ecc = nand_ooblayout_ecc_sp,
- .free = nand_ooblayout_free_sp,
-};
-
-const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void)
-{
- return &nand_ooblayout_sp_ops;
-}
-EXPORT_SYMBOL_GPL(nand_get_small_page_ooblayout);
-
-static int nand_ooblayout_ecc_lp(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
-
- if (section || !ecc->total)
- return -ERANGE;
-
- oobregion->length = ecc->total;
- oobregion->offset = mtd->oobsize - oobregion->length;
-
- return 0;
-}
-
-static int nand_ooblayout_free_lp(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
-
- if (section)
- return -ERANGE;
-
- oobregion->length = mtd->oobsize - ecc->total - 2;
- oobregion->offset = 2;
-
- return 0;
-}
-
-static const struct mtd_ooblayout_ops nand_ooblayout_lp_ops = {
- .ecc = nand_ooblayout_ecc_lp,
- .free = nand_ooblayout_free_lp,
-};
-
-const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void)
-{
- return &nand_ooblayout_lp_ops;
-}
-EXPORT_SYMBOL_GPL(nand_get_large_page_ooblayout);
-
-/*
- * Support the old "large page" layout used for 1-bit Hamming ECC where ECC
- * are placed at a fixed offset.
- */
-static int nand_ooblayout_ecc_lp_hamming(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
-
- if (section)
- return -ERANGE;
-
- switch (mtd->oobsize) {
- case 64:
- oobregion->offset = 40;
- break;
- case 128:
- oobregion->offset = 80;
- break;
- default:
- return -EINVAL;
- }
-
- oobregion->length = ecc->total;
- if (oobregion->offset + oobregion->length > mtd->oobsize)
- return -ERANGE;
-
- return 0;
-}
-
-static int nand_ooblayout_free_lp_hamming(struct mtd_info *mtd, int section,
- struct mtd_oob_region *oobregion)
-{
- struct nand_chip *chip = mtd_to_nand(mtd);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
- int ecc_offset = 0;
-
- if (section < 0 || section > 1)
- return -ERANGE;
-
- switch (mtd->oobsize) {
- case 64:
- ecc_offset = 40;
- break;
- case 128:
- ecc_offset = 80;
- break;
- default:
- return -EINVAL;
- }
-
- if (section == 0) {
- oobregion->offset = 2;
- oobregion->length = ecc_offset - 2;
- } else {
- oobregion->offset = ecc_offset + ecc->total;
- oobregion->length = mtd->oobsize - oobregion->offset;
- }
-
- return 0;
-}
-
-static const struct mtd_ooblayout_ops nand_ooblayout_lp_hamming_ops = {
- .ecc = nand_ooblayout_ecc_lp_hamming,
- .free = nand_ooblayout_free_lp_hamming,
-};
-
-const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void)
-{
- return &nand_ooblayout_lp_hamming_ops;
-}
-EXPORT_SYMBOL_GPL(nand_get_large_page_hamming_ooblayout);
-
static int nand_pairing_dist3_get_info(struct mtd_info *mtd, int page,
struct mtd_pairing_info *info)
{
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index f5cc0aee565c..77757aabeba2 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -127,6 +127,10 @@ struct nand_page_io_req {
int mode;
};
+const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void);
+const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void);
+const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void);
+
/**
* enum nand_ecc_engine_type - NAND ECC engine type
* @NAND_ECC_ENGINE_TYPE_INVALID: Invalid value
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index b455cb22168f..66f69a1d27a5 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -14,6 +14,7 @@
#define __LINUX_MTD_RAWNAND_H
#include <linux/mtd/mtd.h>
+#include <linux/mtd/nand.h>
#include <linux/mtd/flashchip.h>
#include <linux/mtd/bbm.h>
#include <linux/mtd/jedec.h>
@@ -1147,10 +1148,6 @@ struct nand_chip {
int (*unlock_area)(struct nand_chip *chip, loff_t ofs, uint64_t len);
};
-const struct mtd_ooblayout_ops *nand_get_small_page_ooblayout(void);
-const struct mtd_ooblayout_ops *nand_get_large_page_ooblayout(void);
-const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void);
-
static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
{
return container_of(mtd, struct nand_chip, base.mtd);
--
2.20.1
^ permalink raw reply related
* [PATCH v8 5/5] mtd: rawnand: Move the user input parsing bits to the ECC framework
From: Miquel Raynal @ 2020-05-29 13:16 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree
Cc: Boris Brezillon, Thomas Petazzoni, Paul Cercueil, Chuanhong Guo,
Weijie Gao, linux-arm-kernel, Mason Yang, Julien Su,
Miquel Raynal
In-Reply-To: <20200529131602.21532-1-miquel.raynal@bootlin.com>
Many helpers are generic to all NAND chips, they should not be
restricted to be only used by raw NAND controller drivers. They might
later be used by generic ECC engines and SPI-NAND devices as well so
move them into a more generic place.
To avoid moving all the raw NAND core "history" into the generic NAND
layer, we already moved certain bits into legacy helpers in the raw
NAND core to ensure backward compatibility.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/mtd/nand/ecc.c | 138 +++++++++++++++++
drivers/mtd/nand/raw/atmel/nand-controller.c | 3 +-
drivers/mtd/nand/raw/denali.c | 3 +
drivers/mtd/nand/raw/nand_base.c | 150 ++-----------------
drivers/mtd/nand/raw/sunxi_nand.c | 3 +-
drivers/mtd/nand/raw/tegra_nand.c | 5 +-
include/linux/mtd/nand.h | 7 +
include/linux/mtd/rawnand.h | 1 -
8 files changed, 166 insertions(+), 144 deletions(-)
diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
index ad08a047dfc5..1ac7aaa6c6c2 100644
--- a/drivers/mtd/nand/ecc.c
+++ b/drivers/mtd/nand/ecc.c
@@ -328,6 +328,144 @@ const struct mtd_ooblayout_ops *nand_get_large_page_hamming_ooblayout(void)
}
EXPORT_SYMBOL_GPL(nand_get_large_page_hamming_ooblayout);
+static enum nand_ecc_engine_type
+of_get_nand_ecc_engine_type(struct device_node *np)
+{
+ return NAND_ECC_ENGINE_TYPE_INVALID;
+}
+
+static const char * const nand_ecc_placement[] = {
+ [NAND_ECC_PLACEMENT_OOB] = "oob",
+ [NAND_ECC_PLACEMENT_INTERLEAVED] = "interleaved",
+};
+
+enum nand_ecc_placement of_get_nand_ecc_placement(struct device_node *np)
+{
+ enum nand_ecc_placement placement;
+ const char *pm;
+ int err;
+
+ err = of_property_read_string(np, "nand-ecc-placement", &pm);
+ if (!err) {
+ for (placement = NAND_ECC_PLACEMENT_OOB;
+ placement < ARRAY_SIZE(nand_ecc_placement); placement++) {
+ if (!strcasecmp(pm, nand_ecc_placement[placement]))
+ return placement;
+ }
+ }
+
+ return NAND_ECC_PLACEMENT_UNKNOWN;
+}
+
+static const char * const nand_ecc_algos[] = {
+ [NAND_ECC_ALGO_HAMMING] = "hamming",
+ [NAND_ECC_ALGO_BCH] = "bch",
+ [NAND_ECC_ALGO_RS] = "rs",
+};
+
+static enum nand_ecc_algo of_get_nand_ecc_algo(struct device_node *np)
+{
+ enum nand_ecc_algo ecc_algo;
+ const char *pm;
+ int err;
+
+ err = of_property_read_string(np, "nand-ecc-algo", &pm);
+ if (!err) {
+ for (ecc_algo = NAND_ECC_ALGO_HAMMING;
+ ecc_algo < ARRAY_SIZE(nand_ecc_algos);
+ ecc_algo++) {
+ if (!strcasecmp(pm, nand_ecc_algos[ecc_algo]))
+ return ecc_algo;
+ }
+ }
+
+ return NAND_ECC_ALGO_UNKNOWN;
+}
+
+static int of_get_nand_ecc_step_size(struct device_node *np)
+{
+ int ret;
+ u32 val;
+
+ ret = of_property_read_u32(np, "nand-ecc-step-size", &val);
+ return ret ? ret : val;
+}
+
+static int of_get_nand_ecc_strength(struct device_node *np)
+{
+ int ret;
+ u32 val;
+
+ ret = of_property_read_u32(np, "nand-ecc-strength", &val);
+ return ret ? ret : val;
+}
+
+static inline bool of_get_nand_ecc_maximize(struct device_node *np)
+{
+ return of_property_read_bool(np, "nand-ecc-maximize");
+}
+
+void nand_ecc_read_user_conf(struct nand_device *nand)
+{
+ struct device_node *dn = nanddev_get_of_node(nand);
+ int strength, size;
+
+ nand->ecc.user_conf.engine_type = of_get_nand_ecc_engine_type(dn);
+ nand->ecc.user_conf.algo = of_get_nand_ecc_algo(dn);
+ nand->ecc.user_conf.placement = of_get_nand_ecc_placement(dn);
+
+ strength = of_get_nand_ecc_strength(dn);
+ if (strength >= 0)
+ nand->ecc.user_conf.strength = strength;
+
+ size = of_get_nand_ecc_step_size(dn);
+ if (size >= 0)
+ nand->ecc.user_conf.step_size = size;
+
+ if (of_get_nand_ecc_maximize(dn))
+ nand->ecc.user_conf.flags |= NAND_ECC_MAXIMIZE;
+}
+EXPORT_SYMBOL(nand_ecc_read_user_conf);
+
+/**
+ * nand_ecc_correction_is_enough - Check if the chip configuration meets the
+ * datasheet requirements.
+ *
+ * @nand: Device to check
+ *
+ * If our configuration corrects A bits per B bytes and the minimum
+ * required correction level is X bits per Y bytes, then we must ensure
+ * both of the following are true:
+ *
+ * (1) A / B >= X / Y
+ * (2) A >= X
+ *
+ * Requirement (1) ensures we can correct for the required bitflip density.
+ * Requirement (2) ensures we can correct even when all bitflips are clumped
+ * in the same sector.
+ */
+bool nand_ecc_correction_is_enough(struct nand_device *nand)
+{
+ const struct nand_ecc_props *reqs = nanddev_get_ecc_requirements(nand);
+ const struct nand_ecc_props *conf = nanddev_get_ecc_conf(nand);
+ struct mtd_info *mtd = nanddev_to_mtd(nand);
+ int corr, ds_corr;
+
+ if (conf->step_size == 0 || reqs->step_size == 0)
+ /* Not enough information */
+ return true;
+
+ /*
+ * We get the number of corrected bits per page to compare
+ * the correction density.
+ */
+ corr = (mtd->writesize * conf->strength) / conf->step_size;
+ ds_corr = (mtd->writesize * reqs->strength) / reqs->step_size;
+
+ return corr >= ds_corr && conf->strength >= reqs->strength;
+}
+EXPORT_SYMBOL(nand_ecc_correction_is_enough);
+
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
index 08df7f23b859..39d8fe15b8ab 100644
--- a/drivers/mtd/nand/raw/atmel/nand-controller.c
+++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
@@ -1046,6 +1046,7 @@ static int atmel_nand_pmecc_init(struct nand_chip *chip)
const struct nand_ecc_props *requirements =
nanddev_get_ecc_requirements(&chip->base);
struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct atmel_nand *nand = to_atmel_nand(chip);
struct atmel_nand_controller *nc;
struct atmel_pmecc_user_req req;
@@ -1070,7 +1071,7 @@ static int atmel_nand_pmecc_init(struct nand_chip *chip)
chip->ecc.size = val;
}
- if (chip->ecc.options & NAND_ECC_MAXIMIZE)
+ if (nanddev->ecc.user_conf.flags & NAND_ECC_MAXIMIZE)
req.ecc.strength = ATMEL_PMECC_MAXIMIZE_ECC_STRENGTH;
else if (chip->ecc.strength)
req.ecc.strength = chip->ecc.strength;
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index a6a6464974ec..51bc014ebc0a 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1181,6 +1181,7 @@ int denali_chip_init(struct denali_controller *denali,
{
struct nand_chip *chip = &dchip->chip;
struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct denali_chip *dchip2;
int i, j, ret;
@@ -1248,6 +1249,8 @@ int denali_chip_init(struct denali_controller *denali,
mtd_set_ooblayout(mtd, &denali_ooblayout_ops);
+ nanddev->ecc.user_conf.flags |= NAND_ECC_MAXIMIZE;
+
ret = nand_scan(chip, dchip->nsels);
if (ret)
return ret;
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index afc3506468ba..036e88cb52a1 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -4854,17 +4854,6 @@ static int nand_detect(struct nand_chip *chip, struct nand_flash_dev *type)
return ret;
}
-static const char * const nand_ecc_placement[] = {
- [NAND_ECC_PLACEMENT_OOB] = "oob",
- [NAND_ECC_PLACEMENT_INTERLEAVED] = "interleaved",
-};
-
-static enum nand_ecc_engine_type
-of_get_nand_ecc_engine_type(struct device_node *np)
-{
- return NAND_ECC_ENGINE_TYPE_INVALID;
-}
-
static enum nand_ecc_engine_type
of_get_rawnand_ecc_engine_type_legacy(struct device_node *np)
{
@@ -4916,24 +4905,6 @@ of_get_rawnand_ecc_engine_type_legacy(struct device_node *np)
return NAND_ECC_ENGINE_TYPE_INVALID;
}
-enum nand_ecc_placement of_get_nand_ecc_placement(struct device_node *np)
-{
- enum nand_ecc_placement placement;
- const char *pm;
- int err;
-
- err = of_property_read_string(np, "nand-ecc-placement", &pm);
- if (!err) {
- for (placement = NAND_ECC_PLACEMENT_OOB;
- placement < ARRAY_SIZE(nand_ecc_placement); placement++) {
- if (!strcasecmp(pm, nand_ecc_placement[placement]))
- return placement;
- }
- }
-
- return NAND_ECC_PLACEMENT_UNKNOWN;
-}
-
enum nand_ecc_placement
of_get_rawnand_ecc_placement_legacy(struct device_node *np)
{
@@ -4949,31 +4920,6 @@ of_get_rawnand_ecc_placement_legacy(struct device_node *np)
return NAND_ECC_PLACEMENT_UNKNOWN;
}
-static const char * const nand_ecc_algos[] = {
- [NAND_ECC_ALGO_HAMMING] = "hamming",
- [NAND_ECC_ALGO_BCH] = "bch",
- [NAND_ECC_ALGO_RS] = "rs",
-};
-
-static enum nand_ecc_algo of_get_nand_ecc_algo(struct device_node *np)
-{
- enum nand_ecc_algo ecc_algo;
- const char *pm;
- int err;
-
- err = of_property_read_string(np, "nand-ecc-algo", &pm);
- if (!err) {
- for (ecc_algo = NAND_ECC_ALGO_HAMMING;
- ecc_algo < ARRAY_SIZE(nand_ecc_algos);
- ecc_algo++) {
- if (!strcasecmp(pm, nand_ecc_algos[ecc_algo]))
- return ecc_algo;
- }
- }
-
- return NAND_ECC_ALGO_UNKNOWN;
-}
-
static enum nand_ecc_algo of_get_rawnand_ecc_algo_legacy(struct device_node *np)
{
const char *pm;
@@ -4990,48 +4936,10 @@ static enum nand_ecc_algo of_get_rawnand_ecc_algo_legacy(struct device_node *np)
return NAND_ECC_ALGO_UNKNOWN;
}
-static int of_get_nand_ecc_step_size(struct device_node *np)
-{
- int ret;
- u32 val;
-
- ret = of_property_read_u32(np, "nand-ecc-step-size", &val);
- return ret ? ret : val;
-}
-
-static int of_get_nand_ecc_strength(struct device_node *np)
-{
- int ret;
- u32 val;
-
- ret = of_property_read_u32(np, "nand-ecc-strength", &val);
- return ret ? ret : val;
-}
-
-static void nand_ecc_read_user_conf(struct nand_chip *chip)
-{
- struct device_node *dn = nand_get_flash_node(chip);
- struct nand_device *nand = &chip->base;
- int strength, size;
-
- nand->ecc.user_conf.engine_type = of_get_nand_ecc_engine_type(dn);
- nand->ecc.user_conf.algo = of_get_nand_ecc_algo(dn);
- nand->ecc.user_conf.placement = of_get_nand_ecc_placement(dn);
-
- strength = of_get_nand_ecc_strength(dn);
- if (strength >= 0)
- nand->ecc.user_conf.strength = strength;
-
- size = of_get_nand_ecc_step_size(dn);
- if (size >= 0)
- nand->ecc.user_conf.step_size = size;
-}
-
static void rawnand_ecc_read_legacy_user_conf(struct nand_chip *chip)
{
struct device_node *dn = nand_get_flash_node(chip);
- struct nand_device *nand = &chip->base;
- struct nand_ecc_props *user_conf = &nand->ecc.user_conf;
+ struct nand_ecc_props *user_conf = &chip->base.ecc.user_conf;
if (user_conf->engine_type != NAND_ECC_ENGINE_TYPE_INVALID)
user_conf->engine_type = of_get_rawnand_ecc_engine_type_legacy(dn);
@@ -5081,10 +4989,7 @@ static int rawnand_dt_init(struct nand_chip *chip)
if (of_get_nand_on_flash_bbt(dn))
chip->bbt_options |= NAND_BBT_USE_FLASH;
- if (of_property_read_bool(dn, "nand-ecc-maximize"))
- chip->ecc.options |= NAND_ECC_MAXIMIZE;
-
- nand_ecc_read_user_conf(chip);
+ nand_ecc_read_user_conf(nand);
rawnand_ecc_read_legacy_user_conf(chip);
/*
@@ -5214,6 +5119,7 @@ static void nand_scan_ident_cleanup(struct nand_chip *chip)
static int nand_set_ecc_soft_ops(struct nand_chip *chip)
{
struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct nand_ecc_ctrl *ecc = &chip->ecc;
if (WARN_ON(ecc->engine_type != NAND_ECC_ENGINE_TYPE_SOFT))
@@ -5289,7 +5195,7 @@ static int nand_set_ecc_soft_ops(struct nand_chip *chip)
* used.
*/
if (mtd->ooblayout == nand_get_large_page_ooblayout() &&
- ecc->options & NAND_ECC_MAXIMIZE) {
+ nanddev->ecc.user_conf.flags & NAND_ECC_MAXIMIZE) {
int steps, bytes;
/* Always prefer 1k blocks over 512bytes ones */
@@ -5529,11 +5435,12 @@ nand_maximize_ecc(struct nand_chip *chip,
* @caps: ECC engine caps info structure
* @oobavail: OOB size that the ECC engine can use
*
- * Choose the ECC configuration according to following logic
+ * Choose the ECC configuration according to following logic.
*
* 1. If both ECC step size and ECC strength are already set (usually by DT)
* then check if it is supported by this controller.
- * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
+ * 2. If the user provided the nand-ecc-maximize property, then select maximum
+ * ECC strength.
* 3. Otherwise, try to match the ECC step size and ECC strength closest
* to the chip's requirement. If available OOB size can't fit the chip
* requirement then fallback to the maximum ECC step size and ECC strength.
@@ -5544,6 +5451,7 @@ int nand_ecc_choose_conf(struct nand_chip *chip,
const struct nand_ecc_caps *caps, int oobavail)
{
struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
if (WARN_ON(oobavail < 0 || oobavail > mtd->oobsize))
return -EINVAL;
@@ -5551,7 +5459,7 @@ int nand_ecc_choose_conf(struct nand_chip *chip,
if (chip->ecc.size && chip->ecc.strength)
return nand_check_ecc_caps(chip, caps, oobavail);
- if (chip->ecc.options & NAND_ECC_MAXIMIZE)
+ if (nanddev->ecc.user_conf.flags & NAND_ECC_MAXIMIZE)
return nand_maximize_ecc(chip, caps, oobavail);
if (!nand_match_ecc_req(chip, caps, oobavail))
@@ -5561,43 +5469,6 @@ int nand_ecc_choose_conf(struct nand_chip *chip,
}
EXPORT_SYMBOL_GPL(nand_ecc_choose_conf);
-/*
- * Check if the chip configuration meet the datasheet requirements.
-
- * If our configuration corrects A bits per B bytes and the minimum
- * required correction level is X bits per Y bytes, then we must ensure
- * both of the following are true:
- *
- * (1) A / B >= X / Y
- * (2) A >= X
- *
- * Requirement (1) ensures we can correct for the required bitflip density.
- * Requirement (2) ensures we can correct even when all bitflips are clumped
- * in the same sector.
- */
-static bool nand_ecc_strength_good(struct nand_chip *chip)
-{
- struct mtd_info *mtd = nand_to_mtd(chip);
- struct nand_ecc_ctrl *ecc = &chip->ecc;
- const struct nand_ecc_props *requirements =
- nanddev_get_ecc_requirements(&chip->base);
- int corr, ds_corr;
-
- if (ecc->size == 0 || requirements->step_size == 0)
- /* Not enough information */
- return true;
-
- /*
- * We get the number of corrected bits per page to compare
- * the correction density.
- */
- corr = (mtd->writesize * ecc->strength) / ecc->size;
- ds_corr = (mtd->writesize * requirements->strength) /
- requirements->step_size;
-
- return corr >= ds_corr && ecc->strength >= requirements->strength;
-}
-
static int rawnand_erase(struct nand_device *nand, const struct nand_pos *pos)
{
struct nand_chip *chip = container_of(nand, struct nand_chip,
@@ -5653,6 +5524,7 @@ static const struct nand_ops rawnand_ops = {
static int nand_scan_tail(struct nand_chip *chip)
{
struct mtd_info *mtd = nand_to_mtd(chip);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct nand_ecc_ctrl *ecc = &chip->ecc;
int ret, i;
@@ -5880,7 +5752,7 @@ static int nand_scan_tail(struct nand_chip *chip)
mtd->oobavail = ret;
/* ECC sanity check: warn if it's too weak */
- if (!nand_ecc_strength_good(chip))
+ if (!nand_ecc_correction_is_enough(nanddev))
pr_warn("WARNING: %s: the ECC used on your system (%db/%dB) is too weak compared to the one required by the NAND chip (%db/%dB)\n",
mtd->name,
nanddev_get_ecc_conf(&chip->base)->strength,
diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
index 490ba485e939..f863fabb8610 100644
--- a/drivers/mtd/nand/raw/sunxi_nand.c
+++ b/drivers/mtd/nand/raw/sunxi_nand.c
@@ -1609,12 +1609,13 @@ static int sunxi_nand_hw_ecc_ctrl_init(struct nand_chip *nand,
static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
struct mtd_info *mtd = nand_to_mtd(nand);
+ struct nand_device *nanddev = mtd_to_nanddev(mtd);
struct sunxi_nand_hw_ecc *data;
int nsectors;
int ret;
int i;
- if (ecc->options & NAND_ECC_MAXIMIZE) {
+ if (nanddev->ecc.user_conf.flags & NAND_ECC_MAXIMIZE) {
int bytes;
ecc->size = 1024;
diff --git a/drivers/mtd/nand/raw/tegra_nand.c b/drivers/mtd/nand/raw/tegra_nand.c
index fecdb7e8f9e8..1267e7529ca2 100644
--- a/drivers/mtd/nand/raw/tegra_nand.c
+++ b/drivers/mtd/nand/raw/tegra_nand.c
@@ -840,9 +840,10 @@ static int tegra_nand_get_strength(struct nand_chip *chip, const int *strength,
int strength_len, int bits_per_step,
int oobsize)
{
+ struct nand_device *base = mtd_to_nanddev(nand_to_mtd(chip));
const struct nand_ecc_props *requirements =
- nanddev_get_ecc_requirements(&chip->base);
- bool maximize = chip->ecc.options & NAND_ECC_MAXIMIZE;
+ nanddev_get_ecc_requirements(base);
+ bool maximize = base->ecc.user_conf.flags & NAND_ECC_MAXIMIZE;
int i;
/*
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 77757aabeba2..3484374fb0cd 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -182,6 +182,7 @@ enum nand_ecc_algo {
* @algo: ECC algorithm (if relevant)
* @strength: ECC strength
* @step_size: Number of bytes per step
+ * @flags: Misc properties
*/
struct nand_ecc_props {
enum nand_ecc_engine_type engine_type;
@@ -189,10 +190,14 @@ struct nand_ecc_props {
enum nand_ecc_algo algo;
unsigned int strength;
unsigned int step_size;
+ unsigned int flags;
};
#define NAND_ECCREQ(str, stp) { .strength = (str), .step_size = (stp) }
+/* NAND ECC misc flags */
+#define NAND_ECC_MAXIMIZE BIT(0)
+
/**
* struct nand_bbt - bad block table object
* @cache: in memory BBT cache
@@ -264,12 +269,14 @@ struct nand_ecc_engine {
struct nand_ecc_engine_ops *ops;
};
+void nand_ecc_read_user_conf(struct nand_device *nand);
int nand_ecc_init_ctx(struct nand_device *nand);
void nand_ecc_cleanup_ctx(struct nand_device *nand);
int nand_ecc_prepare_io_req(struct nand_device *nand,
struct nand_page_io_req *req);
int nand_ecc_finish_io_req(struct nand_device *nand,
struct nand_page_io_req *req);
+bool nand_ecc_correction_is_enough(struct nand_device *nand);
/**
* struct nand_ecc - Information relative to the ECC
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 66f69a1d27a5..9d69fa6608ae 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -98,7 +98,6 @@ struct nand_chip;
* pages and you want to rely on the default implementation.
*/
#define NAND_ECC_GENERIC_ERASED_CHECK BIT(0)
-#define NAND_ECC_MAXIMIZE BIT(1)
/*
* Option constants for bizarre disfunctionality and real
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v3 1/9] dt-bindings: atmel-tcb: convert bindings to json-schema
From: Alexandre Belloni @ 2020-05-29 13:21 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Rob Herring, devicetree, Daniel Lezcano, Thomas Gleixner,
Nicolas Ferre, kamel.bouhara, linux-arm-kernel, linux-kernel
In-Reply-To: <20200529101314.2ueuhgnrqq3a764f@linutronix.de>
Hi,
On 29/05/2020 12:13:14+0200, Sebastian Andrzej Siewior wrote:
> Rob, could you please bless the DT parts of this series? Daniel Lezcano
> asked for the blessing in:
> https://lkml.kernel.org/r/f0feb409-11fb-08de-cc06-216a16de994a@linaro.org
>
There is actually one comment I need to address that Rob made on another
series that was also including this patch. I'll send a new version
today.
> On 2020-05-06 10:05:46 [+0200], Alexandre Belloni wrote:
> > Convert Atmel Timer Counter Blocks bindings to DT schema format using
> > json-schema.
> >
> > Also move it out of mfd as it is not and has never been related to mfd.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> > ---
> > Cc: Rob Herring <robh+dt@kernel.org>
> >
> > Changes in v3:
> > - Moved the child node documentation to the parent documentation
> >
> > Changes in v2:
> > - Rebased on v5.7-rc1
> > - Moved the binding documentation to its proper place
> > - Added back the atmel,tcb-timer child node documentation
> >
> >
> > .../devicetree/bindings/mfd/atmel-tcb.txt | 56 --------
> > .../soc/microchip/atmel,at91rm9200-tcb.yaml | 126 ++++++++++++++++++
>
> Sebastian
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v6 00/16] spi: dw: Add generic DW DMA controller support
From: Andy Shevchenko @ 2020-05-29 13:27 UTC (permalink / raw)
To: Serge Semin
Cc: Mark Brown, Serge Semin, Georgy Vlasov, Ramil Zaripov,
Alexey Malahov, Maxim Kaurkin, Pavel Parkhomenko,
Ekaterina Skachko, Vadim Vlasov, Alexey Kolotnikov,
Thomas Bogendoerfer, Arnd Bergmann, Feng Tang, Rob Herring,
linux-mips, linux-spi, devicetree, linux-kernel
In-Reply-To: <20200529131205.31838-1-Sergey.Semin@baikalelectronics.ru>
On Fri, May 29, 2020 at 04:11:49PM +0300, Serge Semin wrote:
> Baikal-T1 SoC provides a DW DMA controller to perform low-speed peripherals
> Mem-to-Dev and Dev-to-Mem transaction. This is also applicable to the DW
> APB SSI devices embedded into the SoC. Currently the DMA-based transfers
> are supported by the DW APB SPI driver only as a middle layer code for
> Intel MID/Elkhart PCI devices. Seeing the same code can be used for normal
> platform DMAC device we introduced a set of patches to fix it within this
> series.
>
> First of all we need to add the Tx and Rx DMA channels support into the DW
> APB SSI binding. Then there are several fixes and cleanups provided as a
> initial preparation for the Generic DMA support integration: add Tx/Rx
> finish wait methods, clear DMAC register when done or stopped, Fix native
> CS being unset, enable interrupts in accordance with DMA xfer mode,
> discard static DW DMA slave structures, discard unused void priv pointer
> and dma_width member of the dw_spi structure, provide the DMA Tx/Rx burst
> length parametrisation and make sure it's optionally set in accordance
> with the DMA max-burst capability.
>
> In order to have the DW APB SSI MMIO driver working with DMA we need to
> initialize the paddr field with the physical base address of the DW APB SSI
> registers space. Then we unpin the Intel MID specific code from the
> generic DMA one and placed it into the spi-dw-pci.c driver, which is a
> better place for it anyway. After that the naming cleanups are performed
> since the code is going to be used for a generic DMAC device. Finally the
> Generic DMA initialization can be added to the generic version of the
> DW APB SSI IP.
>
> Last but not least we traditionally convert the legacy plain text-based
> dt-binding file with yaml-based one and as a cherry on a cake replace
> the manually written DebugFS registers read method with a ready-to-use
> for the same purpose regset32 DebugFS interface usage.
>
> This patchset is rebased and tested on the spi/for-next (5.7-rc5):
> base-commit: fe9fce6b2cf3 ("Merge remote-tracking branch 'spi/for-5.8' into spi-next")
Mark, I leave few first patches for you to decide if it's right thing to do.
So, if you are okay, I'm not against them, thanks!
> Link: https://lore.kernel.org/linux-spi/20200508132943.9826-1-Sergey.Semin@baikalelectronics.ru/
> Changelog v2:
> - Rebase on top of the spi repository for-next branch.
> - Move bindings conversion patch to the tail of the series.
> - Move fixes to the head of the series.
> - Apply as many changes as possible to be applied the Generic DMA
> functionality support is added and the spi-dw-mid is moved to the
> spi-dw-dma driver.
> - Discard patch "spi: dw: Fix dma_slave_config used partly uninitialized"
> since the problem has already been fixed.
> - Add new patch "spi: dw: Discard unused void priv pointer".
> - Add new patch "spi: dw: Discard dma_width member of the dw_spi structure".
> n_bytes member of the DW SPI data can be used instead.
> - Build the DMA functionality into the DW APB SSI core if required instead
> of creating a separate kernel module.
> - Use conditional statement instead of the ternary operator in the ref
> clock getter.
>
> Link: https://lore.kernel.org/linux-spi/20200515104758.6934-1-Sergey.Semin@baikalelectronics.ru/
> Changelog v3:
> - Use spi_delay_exec() method to wait for the DMA operation completion.
> - Explicitly initialize the dw_dma_slave members on stack.
> - Discard the dws->fifo_len utilization in the Tx FIFO DMA threshold
> setting from the patch where we just add the default burst length
> constants.
> - Use min() method to calculate the optimal burst values.
> - Add new patch which moves the spi-dw.c source file to spi-dw-core.c in
> order to preserve the DW APB SSI core driver name.
> - Add commas in the debugfs_reg32 structure initializer and after the last
> entry of the dw_spi_dbgfs_regs array.
>
> Link: https://lore.kernel.org/linux-spi/20200521012206.14472-1-Sergey.Semin@baikalelectronics.ru
> Changelog v4:
> - Get back ndelay() method to wait for an SPI transfer completion.
> spi_delay_exec() isn't suitable for the atomic context.
>
> Link: https://lore.kernel.org/linux-spi/20200522000806.7381-1-Sergey.Semin@baikalelectronics.ru
> Changelog v5:
> - Refactor the Tx/Rx DMA-based SPI transfers wait methods.
> - Add a new patch "spi: dw: Set xfer effective_speed_hz".
> - Add a new patch "spi: dw: Return any value retrieved from the
> dma_transfer callback" as a preparation patch before implementing
> the local DMA, Tx SPI and Rx SPI transfers wait methods.
> - Add a new patch "spi: dw: Locally wait for the DMA transactions
> completion", which provides a local DMA transaction complete
> method
> - Create a dedicated patch which adds the Rx-done wait method:
> "spi: dw: Add SPI Rx-done wait method to DMA-based transfer".
> - Add more detailed description of the problems the Tx/Rx-wait
> methods-related patches fix.
> - Wait for the SPI Tx and Rx transfers being finished in the
> mid_spi_dma_transfer() method executed in the task context.
> - Use spi_delay_exec() to wait for the SPI Tx/Rx completion, since now
> the driver calls the wait methods in the kernel thread context.
> - Use SPI_DELAY_UNIT_SCK spi_delay unit for Tx-wait delay, since SPI
> xfer's are now have the effective_speed_hz initialized.
> - Rx-wait for a delay correlated with the APB/SSI synchronous clock
> rate instead of using the SPI bus clock rate.
>
> Link: https://lore.kernel.org/linux-spi/20200529035915.20790-1-Sergey.Semin@baikalelectronics.ru
> Changelog v6:
> - Provide a more detailed description of the patch:
> 2901db35bea1 ("spi: dw: Locally wait for the DMA transfers completion")
> - Calculate the Rx delay with better accuracy by moving 4-multiplication
> to the head of the formulae:
> ns = 4U * NSEC_PER_SEC / dws->max_freq * nents.
>
> Co-developed-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
> Signed-off-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
> 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>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
> Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
> Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
> Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
> Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Feng Tang <feng.tang@intel.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-mips@vger.kernel.org
> Cc: linux-spi@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
>
> Serge Semin (16):
> spi: dw: Set xfer effective_speed_hz
> spi: dw: Return any value retrieved from the dma_transfer callback
> spi: dw: Locally wait for the DMA transfers completion
> spi: dw: Add SPI Tx-done wait method to DMA-based transfer
> spi: dw: Add SPI Rx-done wait method to DMA-based transfer
> spi: dw: Parameterize the DMA Rx/Tx burst length
> spi: dw: Use DMA max burst to set the request thresholds
> spi: dw: Fix Rx-only DMA transfers
> spi: dw: Add core suffix to the DW APB SSI core source file
> spi: dw: Move Non-DMA code to the DW PCIe-SPI driver
> spi: dw: Remove DW DMA code dependency from DW_DMAC_PCI
> spi: dw: Add DW SPI DMA/PCI/MMIO dependency on the DW SPI core
> spi: dw: Cleanup generic DW DMA code namings
> spi: dw: Add DMA support to the DW SPI MMIO driver
> spi: dw: Use regset32 DebugFS method to create regdump file
> dt-bindings: spi: Convert DW SPI binding to DT schema
>
> .../bindings/spi/snps,dw-apb-ssi.txt | 44 --
> .../bindings/spi/snps,dw-apb-ssi.yaml | 127 +++++
> .../devicetree/bindings/spi/spi-dw.txt | 24 -
> drivers/spi/Kconfig | 15 +-
> drivers/spi/Makefile | 5 +-
> drivers/spi/{spi-dw.c => spi-dw-core.c} | 95 ++--
> drivers/spi/spi-dw-dma.c | 482 ++++++++++++++++++
> drivers/spi/spi-dw-mid.c | 382 --------------
> drivers/spi/spi-dw-mmio.c | 4 +
> drivers/spi/spi-dw-pci.c | 50 +-
> drivers/spi/spi-dw.h | 20 +-
> 11 files changed, 719 insertions(+), 529 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
> create mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
> delete mode 100644 Documentation/devicetree/bindings/spi/spi-dw.txt
> rename drivers/spi/{spi-dw.c => spi-dw-core.c} (82%)
> create mode 100644 drivers/spi/spi-dw-dma.c
> delete mode 100644 drivers/spi/spi-dw-mid.c
>
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 3/3] iio: magnetometer: ak8975: Add gpio reset support
From: Pavel Machek @ 2020-05-29 13:33 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jonathan Cameron,
Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Jonathan Cameron
In-Reply-To: <20200518133645.19127-4-jonathan.albrieux@gmail.com>
Hi!
> AK09911 has a reset gpio to handle register's reset. If reset gpio is
> set to low it will trigger the reset. AK09911 datasheed says that if not
> used reset pin should be connected to VID and this patch emulates this
> situation
>
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
> ---
> drivers/iio/magnetometer/ak8975.c | 21 +++++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> /*
> - * According to the datasheet the power supply rise time i 200us
> + * According to the datasheet the power supply rise time is 200us
> * and the minimum wait time before mode setting is 100us, in
> - * total 300 us. Add some margin and say minimum 500us here.
> + * total 300us. Add some margin and say minimum 500us here.
> */
> usleep_range(500, 1000);
I'd assume that datasheet added some safety margin too, and there's another one in usleep...
So I believe usleep..(300) should be okay..
Best regards,
Pavel
^ permalink raw reply
* Re: [PATCH v3 1/9] dt-bindings: atmel-tcb: convert bindings to json-schema
From: Sebastian Andrzej Siewior @ 2020-05-29 13:34 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Rob Herring, devicetree, Daniel Lezcano, Thomas Gleixner,
Nicolas Ferre, kamel.bouhara, linux-arm-kernel, linux-kernel
In-Reply-To: <20200529132118.GF3972@piout.net>
On 2020-05-29 15:21:18 [+0200], Alexandre Belloni wrote:
> There is actually one comment I need to address that Rob made on another
> series that was also including this patch. I'll send a new version
> today.
Ah, okay. Thanks for the info, that thread looked dead.
Sebastian
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: r8a7742: Add CMT SoC specific support
From: Geert Uytterhoeven @ 2020-05-29 13:39 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590614320-30160-5-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Wed, May 27, 2020 at 11:19 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add CMT[01] support to r8a7742 SoC DT.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Tomasz Figa @ 2020-05-29 13:43 UTC (permalink / raw)
To: Dongchun Zhu
Cc: Sakari Ailus, Rob Herring, Linus Walleij, Bartosz Golaszewski,
Mauro Carvalho Chehab, Andy Shevchenko, Mark Rutland,
Nicolas Boichat, Matthias Brugger, Cao Bing Bu, srv_heupstream,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Sj Huang,
Linux Media Mailing List, linux-devicetree, Louis Kuo,
Shengnan Wang (王圣男)
In-Reply-To: <1590653082.8804.517.camel@mhfsdcap03>
On Thu, May 28, 2020 at 10:06 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
>
> Hi Sakari,
>
> On Thu, 2020-05-28 at 10:23 +0300, Sakari Ailus wrote:
> > Hi Dongchun,
> >
> > On Thu, May 28, 2020 at 11:34:42AM +0800, Dongchun Zhu wrote:
> > > Hi Sakari, Rob,
> > >
> > > On Thu, 2020-05-28 at 00:16 +0300, Sakari Ailus wrote:
> > > > Hi Rob, Dongchun,
> > > >
> > > > On Wed, May 27, 2020 at 09:27:22AM -0600, Rob Herring wrote:
> > > > > > > > + properties:
> > > > > > > > + endpoint:
> > > > > > > > + type: object
> > > > > > > > + additionalProperties: false
> > > > > > > > +
> > > > > > > > + properties:
> > > > > >
> > > > > > Actually I wonder whether we need to declare 'clock-lanes' here?
> > > > >
> > > > > Yes, if you are using it.
> > > >
> > > > Dongchun, can you confirm the chip has a single data and a single clock
> > > > lane and that it does not support lane reordering?
> > > >
> > >
> > > From the datasheet, 'MIPI inside the OV02A10 provides one single
> > > uni-directional clock lane and one bi-directional data lane solution for
> > > communication links between components inside a mobile device.
> > > The data lane has full support for HS(uni-directional) and
> > > LP(bi-directional) data transfer mode.'
> > >
> > > The sensor doesn't support lane reordering, so 'clock-lanes' property
> > > would not be added in next release.
> > >
> > > > So if there's nothing to convey to the driver, also the data-lanes should
> > > > be removed IMO.
> > > >
> > >
> > > However, 'data-lanes' property may still be required.
> > > It is known that either data-lanes or clock-lanes is an array of
> > > physical data lane indexes. Position of an entry determines the logical
> > > lane number, while the value of an entry indicates physical lane, e.g.,
> > > for 1-lane MIPI CSI-2 bus we could have "data-lanes = <1>;", assuming
> > > the clock lane is on hardware lane 0.
> > >
> > > As mentioned earlier, the OV02A10 sensor supports only 1C1D and does not
> > > support lane reordering, so here we shall use 'data-lanes = <1>' as
> > > there is only a clock lane for OV02A10.
> > >
> > > Reminder:
> > > If 'data-lanes' property is not present, the driver would assume
> > > four-lane operation. This means for one-lane or two-lane operation, this
> > > property must be present and set to the right physical lane indexes.
> > > If the hardware does not support lane reordering, monotonically
> > > incremented values shall be used from 0 or 1 onwards, depending on
> > > whether or not there is also a clock lane.
> >
> > How can the driver use four lanes, considering the device only supports a
> > single lane??
> >
>
> I understood your meaning.
> If we omit the property 'data-lanes', the sensor should work still.
> But then what's the meaning of the existence of 'data-lanes'?
> If this property 'data-lanes' is always optional, then why dt-bindings
> provide the interface?
>
> In the meantime, if omitting 'data-lanes' for one sensor(transmitter)
> that has only one physical data lane, MIPI receiver(e.g., MIPI CSI-2)
> shall enable four-lane configuration, which may increase consumption of
> both power and resource in the process of IIC communication.
Wouldn't the receiver still have the data-lanes property under its
endpoint node, telling it how many lanes and in which order should be
used?
Best regards,
Tomasz
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: r8a7742-iwg21d-q7: Enable HSUSB, USB2.0 and XHCI
From: Geert Uytterhoeven @ 2020-05-29 14:03 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Magnus Damm, Rob Herring, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590611013-26029-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
On Wed, May 27, 2020 at 10:24 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Enable support for HSUB, USB2.0 and xhci on iWave RZ/G1H carrier board.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Thanks for your patch!
> --- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> +++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> @@ -88,6 +114,21 @@
> function = "sdhi2";
> power-source = <1800>;
> };
> +
> + usb0_pins: usb0 {
> + groups = "usb0";
> + function = "usb0";
> + };
> +
> + usb1_pins: usb1 {
> + groups = "usb1";
> + function = "usb1";
> + };
> +
> + usb2_pins: usb2 {
> + groups = "usb2";
> + function = "usb2";
> + };
> };
Looking at the schematics[*], I'm having a hard time making some sense
out of this.
GP5_21 (USB1_OVC) seems to be GPIO_AVB_SEL, and
GP5_22 (USB2_PWEN) is GPIO_SD1_LED?
I must be missing something?
[*] *RZ_G1H_SOM.pdf, *RZ_G1M_G1N_G1H_Q7 carrierBoard.pdf
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 10/14] dt-bindings: clock: sparx5: Add Sparx5 SoC DPLL clock
From: Lars Povlsen @ 2020-05-29 14:04 UTC (permalink / raw)
To: Stephen Boyd
Cc: Arnd Bergmann, Linus Walleij, Rob Herring, SoC Team, Lars Povlsen,
Steen Hegelund, Microchip Linux Driver Support, Olof Johansson,
Michael Turquette, devicetree, linux-clk, linux-gpio,
linux-arm-kernel, linux-kernel, Alexandre Belloni
In-Reply-To: <159054759981.88029.2630901114208720574@swboyd.mtv.corp.google.com>
Stephen Boyd writes:
> Quoting Lars Povlsen (2020-05-13 05:55:28)
>> diff --git a/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
>> new file mode 100644
>> index 0000000000000..594007d8fc59a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
>> @@ -0,0 +1,46 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/microchip,sparx5-dpll.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip Sparx5 DPLL Clock
>> +
>> +maintainers:
>> + - Lars Povlsen <lars.povlsen@microchip.com>
>> +
>> +description: |
>> + The Sparx5 DPLL clock controller generates and supplies clock to
>> + various peripherals within the SoC.
>> +
>> + This binding uses common clock bindings
>> + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>
> I don't think we need this sentence. Please drop it.
OK. (Assuming the "This binding ..." part).
>
>> +
>> +properties:
>> + compatible:
>> + const: microchip,sparx5-dpll
>> +
>> + reg:
>> + items:
>> + - description: dpll registers
>> +
>> + '#clock-cells':
>> + const: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - '#clock-cells'
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + # Clock provider for eMMC:
>> + - |
>> + clks: clks@61110000c {
>
> Node name should be clock-controller@61110000c
Ok.
>
>> + compatible = "microchip,sparx5-dpll";
>> + #clock-cells = <1>;
>> + reg = <0x1110000c 0x24>;
>
> Does it consume any clks itself? I'd expect to see some sort of 'clocks'
> property in this node.
>
>> + };
I changed the driver to use a fixed-rate input clock, replacing the
BASE_CLOCK define(s). Additionally, I made the ahb_clock into
fixed-factor clock using the A53 cpu clock as a base.
So I updated the example and added 'clocks' to the schema.
I will send you a new series shortly.
Thank you for the comments.
--
Lars Povlsen,
Microchip
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface
From: Sebastian Reichel @ 2020-05-29 14:05 UTC (permalink / raw)
To: Pavel Machek
Cc: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Rob Herring, devicetree, linux-kernel, kernel,
Ian Ray, Samu Nuutamo
In-Reply-To: <20200424124423.jo25ai5oifvalgpr@earth.universe>
[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]
Hi,
ping?
-- Sebastian
On Fri, Apr 24, 2020 at 02:44:23PM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Fri, Apr 24, 2020 at 11:32:26AM +0200, Pavel Machek wrote:
> > On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> > > From: Ian Ray <ian.ray@ge.com>
> > >
> > > Use kernel LED interface for the alarm LEDs.
> >
> > Could we get these changes cced to LED maintainers?
>
> Sorry, you are not turning up via get_maintainer.pl and usually
> subsystem maintainers are not CC'd for every DT device instance.
> E.g. I do not want to be always CC'd for DT board file containing
> a battery/charger. I'm quite surprised you want to be CC'd for
> them, just looking at ARM DT files there are over 1000 instances
> of leds.
>
> > > + alarm1 {
> > > + label = "alarm:red";
> > > + gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> > > + };
> >
> > So... What is function of these leds, and can we get naming more
> > consistent with rest of the kernel?
>
> The device is a medical patient monitor and these are alarm LEDs
> informing about critical device or patient status. They are
> referenced by their color (those are discrete LEDs, not a
> multi-color one) basically everywhere. The only exception is
> "silenced", which means that audible alarm is surpressed. I
> don't think we have something comparable for any of those LEDs
> in the mainline tree.
>
> -- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 05/11] dmaengine: Introduce DMA-device device_caps callback
From: Serge Semin @ 2020-05-29 14:07 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Vinod Koul, Viresh Kumar, Dan Williams,
Alexey Malahov, Thomas Bogendoerfer, Arnd Bergmann, Rob Herring,
linux-mips, devicetree, dmaengine, linux-kernel
In-Reply-To: <20200529121203.GK1634618@smile.fi.intel.com>
On Fri, May 29, 2020 at 03:12:03PM +0300, Andy Shevchenko wrote:
> On Fri, May 29, 2020 at 01:23:55AM +0300, Serge Semin wrote:
> > There are DMA devices (like ours version of Synopsys DW DMAC) which have
> > DMA capabilities non-uniformly redistributed amongst the device channels.
> > In order to provide a way of exposing the channel-specific parameters to
> > the DMA engine consumers, we introduce a new DMA-device callback. In case
> > if provided it gets called from the dma_get_slave_caps() method and is
> > able to override the generic DMA-device capabilities.
>
> I thought there is a pattern to return something, but it seems none.
> So, I have nothing against it to return void.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> But consider one comment below.
>
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: linux-mips@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> >
> > ---
> >
> > Changelog v3:
> > - This is a new patch created as a result of the discussion with Vinod and
> > Andy in the framework of DW DMA burst and LLP capabilities.
> > ---
> > drivers/dma/dmaengine.c | 3 +++
> > include/linux/dmaengine.h | 2 ++
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> > index ad56ad58932c..edbb11d56cde 100644
> > --- a/drivers/dma/dmaengine.c
> > +++ b/drivers/dma/dmaengine.c
> > @@ -599,6 +599,9 @@ int dma_get_slave_caps(struct dma_chan *chan, struct dma_slave_caps *caps)
> > caps->cmd_resume = !!device->device_resume;
> > caps->cmd_terminate = !!device->device_terminate_all;
> >
>
> Perhaps a comment to explain that this is channel specific correction /
> override / you name it on top of device level capabilities?
>
> > + if (device->device_caps)
> > + device->device_caps(chan, caps);
> > +
Agreed. I also forgot to add a doc-comment above the struct dma_device
definition.
-Sergey
> > return 0;
> > }
> > EXPORT_SYMBOL_GPL(dma_get_slave_caps);
> > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> > index a7e4d8dfdd19..b303e59929e5 100644
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -899,6 +899,8 @@ struct dma_device {
> > struct dma_chan *chan, dma_addr_t dst, u64 data,
> > unsigned long flags);
> >
> > + void (*device_caps)(struct dma_chan *chan,
> > + struct dma_slave_caps *caps);
> > int (*device_config)(struct dma_chan *chan,
> > struct dma_slave_config *config);
> > int (*device_pause)(struct dma_chan *chan);
> > --
> > 2.26.2
> >
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH 2/3] sdhci: sparx5: Add Sparx5 SoC eMMC driver
From: Lars Povlsen @ 2020-05-29 14:11 UTC (permalink / raw)
To: Adrian Hunter
Cc: Ulf Hansson, SoC Team, Microchip Linux Driver Support, linux-mmc,
devicetree, linux-arm-kernel, linux-kernel, Alexandre Belloni,
Lars Povlsen
In-Reply-To: <87sgfoozt8.fsf@soft-dev15.microsemi.net>
Lars Povlsen writes:
> Adrian Hunter writes:
>
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 20/05/20 2:14 pm, Lars Povlsen wrote:
>>>
>>> Lars Povlsen writes:
>>>
>>>> Adrian Hunter writes:
>>>>
>>>>> On 13/05/20 4:31 pm, Lars Povlsen wrote:
>>>>>> This adds the eMMC driver for the Sparx5 SoC. It is based upon the
>>>>>> designware IP, but requires some extra initialization and quirks.
>>>>>>
>>>>>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>>>>>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>>>>>> ---
>>> {Snip]
>>>>>> +};
>>>>>> +
>>>>>> +static const struct sdhci_pltfm_data sdhci_sparx5_pdata = {
>>>>>> + .quirks = 0,
>>>>>> + .quirks2 = SDHCI_QUIRK2_HOST_NO_CMD23 | /* Card quirk */
>>>>>
>>>>> If this is a card quirk then it should be in drivers/mmc/core/quirks.h not here.
>>>>
>>>
>>> Adrian, I had a go at changing the controller quirk to a card quirk.
>>>
>>> Unfortunately, SDHCI_QUIRK2_HOST_NO_CMD23 does not directly translate to
>>> MMC_QUIRK_BLK_NO_CMD23, as for 'do_rel_wr' in mmc_blk_rw_rq_prep(), it
>>> will *still* use MMC_SET_BLOCK_COUNT (cmd23), causing the issue.
>>>
>>> We are using a ISSI "IS004G" device, and so I have gone through the
>>> motions of adding it to quirks.h. The comment before the list of devices
>>> using MMC_QUIRK_BLK_NO_CMD23 suggest working around a performance issue,
>>> which is not exactly the issue I'm seeing. I'm seeing combinations of
>>> CMD_TOUT_ERR, DATA_CRC_ERR and DATA_END_BIT_ERR whenever a cmd23 is
>>> issued.
>>>
>>> I have not been able to test the controller with another eMMC device
>>> yet, but I expect its not the controller at fault.
>>>
>>> So, I'm a little bit in doubt of how to proceed - either keep the quirk
>>> as a controller quirk - or make a *new* card quirk (with
>>> SDHCI_QUIRK2_HOST_NO_CMD23 semantics)?
>>>
>>> Anybody else have had experience with ISSI eMMC devices?
>>>
>>> I have also tried to use DT sdhci-caps-mask, but MMC_CAP_CMD23 is not
>>> read from the controller just (unconditionally) set in sdhci.c - so that
>>> doesn't fly either.
>>>
>>> Any suggestions?
>>
>> It is up to you. In the future, you may want to distinguish devices that
>> have this problem from ones that do not.
>>
>> If you are not sure it is the ISSI eMMC, and maybe not the host controller,
>> then might it be the board? Perhaps make SDHCI_QUIRK2_HOST_NO_CMD23
>> conditional on the particular compatibility string?
>>
>> At a minimum, change the "/* Card quirk */" comment to a fuller explanation.
>>
>
> Adrian, I'm getting a board ready with another eMMC device, and we're
> also trying to contact ISSI for info.
>
> My hope is to at least verify whether this is a controller or a card
> issue one way or the other. Then, I'll choose an appropriate solution
> for it.
>
> Thank you for your advice so far.
>
I was able to try on a board with another eMMC card (panasonic), so that
clearly casts the suspicion on the controller, and ISSI is in the clear.
I reintroduced the original SDHCI_QUIRK2_HOST_NO_CMD23 quirk, with a
"Controller issue" comment.
I will refresh the series shortly.
Cheers,
> ---Lars
>
>>>
>>>> Yes, its supposedly a card quirk. I'll see to use the card quirks
>>>> methods in place.
>>>>
>>>
--
Lars Povlsen,
Microchip
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox