[PATCH v2 0/6] NXP DSPI bugfixes and support for LS1028A

[PATCH v2 0/6] NXP DSPI bugfixes and support for LS1028A

[Vladimir Oltean]

This series addresses a few issues that were missed during the previous
series "[PATCH 00/12] TCFQ to XSPI migration for NXP DSPI driver", on
SoCs other than LS1021A and LS1043A. DMA mode has been completely broken
by that series, and XSPI mode never worked on little-endian controllers.

Then it introduces support for the LS1028A chip, whose compatible has
recently been documented here:

https://lore.kernel.org/linux-devicetree/20200218171418.18297-1-michael-QKn5cuLxLXY@public.gmane.org/

The device tree for the LS1028A SoC is extended with DMA channels
definition, such that even though the default operating mode is XSPI,
one can simply change DSPI_XSPI_MODE to DSPI_DMA_MODE in the
devtype_data structure of the driver and use that instead.

For testing, benchmarking and debugging, the mikroBUS connector on the
LS1028A-RDB is made available via spidev.

Vladimir Oltean (6):
  spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR
  spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
  spi: spi-fsl-dspi: Fix oper_word_size of zero for DMA mode
  spi: spi-fsl-dspi: Add support for LS1028A
  arm64: dts: ls1028a: Specify the DMA channels for the DSPI controllers
  arm64: dts: ls1028a-rdb: Add a spidev node for the mikroBUS

 .../boot/dts/freescale/fsl-ls1028a-rdb.dts    | 14 ++++++
 .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi |  6 +++
 drivers/spi/spi-fsl-dspi.c                    | 50 +++++++++++++++----
 3 files changed, 60 insertions(+), 10 deletions(-)

-- 
2.17.1

[PATCH v2 1/6] spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR

[Vladimir Oltean]

From: Vladimir Oltean <vladimir.oltean-3arQi8VN3Tc@public.gmane.org>

The SPI_MCR_PCSIS macro assumes that the controller has a number of chip
select signals equal to 6. That is not always the case, but actually is
described through the driver-specific "spi-num-chipselects" device tree
binding. LS1028A for example only has 4 chip selects.

Don't write to the upper bits of the PCSIS field, which are reserved in
the reference manual.

Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
Signed-off-by: Vladimir Oltean <vladimir.oltean-3arQi8VN3Tc@public.gmane.org>
---
Changes in v2:
Remove duplicate phrase in commit message.

 drivers/spi/spi-fsl-dspi.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 0683a3fbd48c..0ce26c1cbf62 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -22,7 +22,7 @@
 
 #define SPI_MCR				0x00
 #define SPI_MCR_MASTER			BIT(31)
-#define SPI_MCR_PCSIS			(0x3F << 16)
+#define SPI_MCR_PCSIS(x)		((x) << 16)
 #define SPI_MCR_CLR_TXF			BIT(11)
 #define SPI_MCR_CLR_RXF			BIT(10)
 #define SPI_MCR_XSPI			BIT(3)
@@ -1197,7 +1197,10 @@ static const struct regmap_config dspi_xspi_regmap_config[] = {
 
 static void dspi_init(struct fsl_dspi *dspi)
 {
-	unsigned int mcr = SPI_MCR_PCSIS;
+	unsigned int mcr;
+
+	/* Set idle states for all chip select signals to high */
+	mcr = SPI_MCR_PCSIS(GENMASK(dspi->ctlr->num_chipselect - 1, 0));
 
 	if (dspi->devtype_data->trans_mode == DSPI_XSPI_MODE)
 		mcr |= SPI_MCR_XSPI;
-- 
2.17.1

[PATCH v2 2/6] spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA

[Vladimir Oltean]

From: Vladimir Oltean <vladimir.oltean-3arQi8VN3Tc@public.gmane.org>

In XSPI mode, the 32-bit PUSHR register can be written to separately:
the higher 16 bits are for commands and the lower 16 bits are for data.

This has nicely been hacked around, by defining a second regmap with a
width of 16 bits, and effectively splitting a 32-bit register into 2
16-bit ones, from the perspective of this regmap_pushr.

The problem is the assumption about the controller's endianness. If the
controller is little endian (such as anything post-LS1046A), then the
first 2 bytes, in the order imposed by memory layout, will actually hold
the TXDATA, and the last 2 bytes will hold the CMD.

So take the controller's endianness into account when performing split
writes to PUSHR. The obvious and simple solution would have been to call
regmap_get_val_endian(), but that is an internal regmap function and we
don't want to change regmap just for this. Therefore, we just re-read
the "big-endian" device tree property.

Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
Signed-off-by: Vladimir Oltean <vladimir.oltean-3arQi8VN3Tc@public.gmane.org>
---
Changes in v2:
Parse "big-endian" device tree bindings instead of taking the decision
based on compatible SoC.

 drivers/spi/spi-fsl-dspi.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 0ce26c1cbf62..0483abd403a4 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -103,10 +103,6 @@
 #define SPI_FRAME_BITS(bits)		SPI_CTAR_FMSZ((bits) - 1)
 #define SPI_FRAME_EBITS(bits)		SPI_CTARE_FMSZE(((bits) - 1) >> 4)
 
-/* Register offsets for regmap_pushr */
-#define PUSHR_CMD			0x0
-#define PUSHR_TX			0x2
-
 #define DMA_COMPLETION_TIMEOUT		msecs_to_jiffies(3000)
 
 struct chip_data {
@@ -240,6 +236,13 @@ struct fsl_dspi {
 
 	int					words_in_flight;
 
+	/*
+	 * Offsets for CMD and TXDATA within SPI_PUSHR when accessed
+	 * individually (in XSPI mode)
+	 */
+	int					pushr_cmd;
+	int					pushr_tx;
+
 	void (*host_to_dev)(struct fsl_dspi *dspi, u32 *txdata);
 	void (*dev_to_host)(struct fsl_dspi *dspi, u32 rxdata);
 };
@@ -670,12 +673,12 @@ static void dspi_pushr_cmd_write(struct fsl_dspi *dspi, u16 cmd)
 	 */
 	if (dspi->len > dspi->oper_word_size)
 		cmd |= SPI_PUSHR_CMD_CONT;
-	regmap_write(dspi->regmap_pushr, PUSHR_CMD, cmd);
+	regmap_write(dspi->regmap_pushr, dspi->pushr_cmd, cmd);
 }
 
 static void dspi_pushr_txdata_write(struct fsl_dspi *dspi, u16 txdata)
 {
-	regmap_write(dspi->regmap_pushr, PUSHR_TX, txdata);
+	regmap_write(dspi->regmap_pushr, dspi->pushr_tx, txdata);
 }
 
 static void dspi_xspi_write(struct fsl_dspi *dspi, int cnt, bool eoq)
@@ -1256,6 +1259,7 @@ static int dspi_probe(struct platform_device *pdev)
 	struct fsl_dspi *dspi;
 	struct resource *res;
 	void __iomem *base;
+	bool big_endian;
 
 	ctlr = spi_alloc_master(&pdev->dev, sizeof(struct fsl_dspi));
 	if (!ctlr)
@@ -1281,6 +1285,7 @@ static int dspi_probe(struct platform_device *pdev)
 
 		/* Only Coldfire uses platform data */
 		dspi->devtype_data = &devtype_data[MCF5441X];
+		big_endian = true;
 	} else {
 
 		ret = of_property_read_u32(np, "spi-num-chipselects", &cs_num);
@@ -1302,6 +1307,15 @@ static int dspi_probe(struct platform_device *pdev)
 			ret = -EFAULT;
 			goto out_ctlr_put;
 		}
+
+		big_endian = of_device_is_big_endian(np);
+	}
+	if (big_endian) {
+		dspi->pushr_cmd = 0;
+		dspi->pushr_tx = 2;
+	} else {
+		dspi->pushr_cmd = 2;
+		dspi->pushr_tx = 0;
 	}
 
 	if (dspi->devtype_data->trans_mode == DSPI_XSPI_MODE)
-- 
2.17.1

[PATCH v2 3/6] spi: spi-fsl-dspi: Fix oper_word_size of zero for DMA mode

[Vladimir Oltean]

From: Vladimir Oltean <vladimir.oltean-3arQi8VN3Tc@public.gmane.org>

In DMA mode, dspi_setup_accel does not get called, which results in the
dspi->oper_word_size variable (which is used by dspi_dma_xfer) to not be
initialized properly.

Because oper_word_size is zero, a few calculations end up being
incorrect, and the DMA transfer eventually times out instead of sending
anything on the wire.

Set up native transfers (or 8-on-16 acceleration) using dspi_setup_accel
for DMA mode too.

Fixes: 6c1c26ecd9a3 ("spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible")
Signed-off-by: Vladimir Oltean <vladimir.oltean-3arQi8VN3Tc@public.gmane.org>
---
Changes in v2:
None.

 drivers/spi/spi-fsl-dspi.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 0483abd403a4..43d2d9fc8b92 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -359,6 +359,8 @@ static void dspi_rx_dma_callback(void *arg)
 	complete(&dma->cmd_rx_complete);
 }
 
+static void dspi_setup_accel(struct fsl_dspi *dspi);
+
 static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
 {
 	struct device *dev = &dspi->pdev->dev;
@@ -446,9 +448,10 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
 	int bytes_per_buffer;
 	int ret = 0;
 
+	dspi_setup_accel(dspi);
+
 	curr_remaining_bytes = dspi->len;
-	bytes_per_buffer = dspi->devtype_data->dma_bufsize /
-			   dspi->devtype_data->fifo_size;
+	bytes_per_buffer = dspi->devtype_data->dma_bufsize;
 	while (curr_remaining_bytes) {
 		/* Check if current transfer fits the DMA buffer */
 		dma->curr_xfer_len = curr_remaining_bytes /
-- 
2.17.1

[PATCH v2 4/6] spi: spi-fsl-dspi: Add support for LS1028A

[Vladimir Oltean]

From: Vladimir Oltean <vladimir.oltean@nxp.com>

This is similar to the DSPI instantiation on LS1028A, except that:
 - The A-011218 erratum has been fixed, so DMA works
 - The endianness is different, which has implications on XSPI mode

Some benchmarking with the following command:

spidev_test --device /dev/spidev2.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000

shows that in DMA mode, it can achieve around 2400 kbps, and in XSPI
mode, the same command goes up to 4700 kbps. This is somewhat to be
expected, since the DMA buffer size is extremely small at 8 bytes, the
winner becomes whomever can prepare the buffers for transmission
quicker, and DMA mode has higher overhead there. So XSPI FIFO mode has
been chosen as the operating mode for this chip.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Changes in v2:
Switch to DSPI_XSPI_MODE.

 drivers/spi/spi-fsl-dspi.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 43d2d9fc8b92..cf8a141bbaf2 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -125,6 +125,7 @@ struct fsl_dspi_devtype_data {
 enum {
 	LS1021A,
 	LS1012A,
+	LS1028A,
 	LS1043A,
 	LS1046A,
 	LS2080A,
@@ -153,6 +154,12 @@ static const struct fsl_dspi_devtype_data devtype_data[] = {
 		.max_clock_factor	= 8,
 		.fifo_size		= 16,
 	},
+	[LS1028A] = {
+		.trans_mode		= DSPI_XSPI_MODE,
+		.dma_bufsize		= 8,
+		.max_clock_factor	= 8,
+		.fifo_size		= 4,
+	},
 	[LS1043A] = {
 		/* Has A-011218 DMA erratum */
 		.trans_mode		= DSPI_XSPI_MODE,
@@ -1100,6 +1107,9 @@ static const struct of_device_id fsl_dspi_dt_ids[] = {
 	}, {
 		.compatible = "fsl,ls1012a-dspi",
 		.data = &devtype_data[LS1012A],
+	}, {
+		.compatible = "fsl,ls1028a-dspi",
+		.data = &devtype_data[LS1028A],
 	}, {
 		.compatible = "fsl,ls1043a-dspi",
 		.data = &devtype_data[LS1043A],
-- 
2.17.1

[PATCH v2 5/6] arm64: dts: ls1028a: Specify the DMA channels for the DSPI controllers

[Vladimir Oltean]

From: Vladimir Oltean <vladimir.oltean-3arQi8VN3Tc@public.gmane.org>

LS1028A has a functional connection to the eDMA module. Even if the
spi-fsl-dspi.c driver is not using DMA for LS1028A now, define the slots
in the DMAMUX for connecting the eDMA channels to the 3 DSPI
controllers.

Signed-off-by: Vladimir Oltean <vladimir.oltean-3arQi8VN3Tc@public.gmane.org>
---
Changes in v2:
None.

 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 515e0a1b934f..18155273a46e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -298,6 +298,8 @@
 			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
 			clock-names = "dspi";
 			clocks = <&clockgen 4 1>;
+			dmas = <&edma0 0 62>, <&edma0 0 60>;
+			dma-names = "tx", "rx";
 			spi-num-chipselects = <4>;
 			little-endian;
 			status = "disabled";
@@ -311,6 +313,8 @@
 			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
 			clock-names = "dspi";
 			clocks = <&clockgen 4 1>;
+			dmas = <&edma0 0 58>, <&edma0 0 56>;
+			dma-names = "tx", "rx";
 			spi-num-chipselects = <4>;
 			little-endian;
 			status = "disabled";
@@ -324,6 +328,8 @@
 			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
 			clock-names = "dspi";
 			clocks = <&clockgen 4 1>;
+			dmas = <&edma0 0 54>, <&edma0 0 2>;
+			dma-names = "tx", "rx";
 			spi-num-chipselects = <3>;
 			little-endian;
 			status = "disabled";
-- 
2.17.1

[PATCH v2 6/6] arm64: dts: ls1028a-rdb: Add a spidev node for the mikroBUS

[Vladimir Oltean]

From: Vladimir Oltean <vladimir.oltean-3arQi8VN3Tc@public.gmane.org>

For debugging, it is useful to have access to the DSPI controller
signals. On the reference design board, these are exported to either the
mikroBUS1 or mikroBUS2 connector (according to the CPLD register
BRDCFG3[SPI3]).

Signed-off-by: Vladimir Oltean <vladimir.oltean-3arQi8VN3Tc@public.gmane.org>
---
Changes in v2:
Change compatible string for spidev node.

 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index bb7ba3bcbe56..13555ed52b89 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -83,6 +83,20 @@
 	};
 };
 
+&dspi2 {
+	bus-num = <2>;
+	status = "okay";
+
+	/* mikroBUS1 */
+	spidev@0 {
+		compatible = "rohm,dh2228fv";
+		spi-max-frequency = <20000000>;
+		fsl,spi-cs-sck-delay = <100>;
+		fsl,spi-sck-cs-delay = <100>;
+		reg = <0>;
+	};
+};
+
 &esdhc {
 	sd-uhs-sdr104;
 	sd-uhs-sdr50;
-- 
2.17.1

Re: [PATCH v2 0/6] NXP DSPI bugfixes and support for LS1028A

[Michael Walle]

Am 2020-03-09 22:07, schrieb Vladimir Oltean:
> This series addresses a few issues that were missed during the previous
> series "[PATCH 00/12] TCFQ to XSPI migration for NXP DSPI driver", on
> SoCs other than LS1021A and LS1043A. DMA mode has been completely 
> broken
> by that series, and XSPI mode never worked on little-endian 
> controllers.
> 
> Then it introduces support for the LS1028A chip, whose compatible has
> recently been documented here:
> 
> https://lore.kernel.org/linux-devicetree/20200218171418.18297-1-michael-QKn5cuLxLXY@public.gmane.org/
> 
> The device tree for the LS1028A SoC is extended with DMA channels
> definition, such that even though the default operating mode is XSPI,
> one can simply change DSPI_XSPI_MODE to DSPI_DMA_MODE in the
> devtype_data structure of the driver and use that instead.
> 
> For testing, benchmarking and debugging, the mikroBUS connector on the
> LS1028A-RDB is made available via spidev.



Let me start with the positive things... something is working, both in
XSPI mode and DMA mode ;) At least the SPI flash is detected.

And please note, that I have my patch applied:
   https://lore.kernel.org/lkml/20200310073313.21277-1-michael-QKn5cuLxLXY@public.gmane.org/

Further note, that the mtd device is either mtd0 in XSPI mode or mtd10
in DMA mode, because the first probe fails due to EPROBE_DEFER.

So starting with XSPI, if you have a big flash and cancel the readout
strange things happen.

# hexdump -C /dev/mtd0
00000000  00 75 68 75 0a ff ff ff  ff ff ff ff ff ff ff ff  
|.uhu............|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  
|................|
*
^C[   35.487948] fsl-dspi 2120000.spi: Waiting for transfer to complete 
failed!
[   35.495038] spi_master spi2: failed to transfer one message from 
queue

# hexdump -C /dev/mtd0
00000000  00 75 68 75 0a ff ff ff  ff ff ff ff ff ff ff ff  
|.uhu............|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  
|................|
*
^C[   38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete 
failed!
[   38.503097] spi_master spi2: failed to transfer one message from 
queue
[   38.509729] Unable to handle kernel paging request at virtual address 
ffff800095ab3377
[   38.517676] Mem abort info:
[   38.520474]   ESR = 0x96000045
[   38.523533]   EC = 0x25: DABT (current EL), IL = 32 bits
[   38.528861]   SET = 0, FnV = 0
[   38.531921]   EA = 0, S1PTW = 0
[   38.535067] Data abort info:
[   38.537952]   ISV = 0, ISS = 0x00000045
[   38.541797]   CM = 0, WnR = 1
[   38.544771] swapper pgtable: 4k pages, 48-bit VAs, 
pgdp=0000000082621000
[   38.551494] [ffff800095ab3377] pgd=00000020fffff003, 
p4d=00000020fffff003, pud=0000000000000000
[   38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP
[   38.565819] Modules linked in:
[   38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 
5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193
[   38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC 
Eval 2.0 carrier (DT)
[   38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO)
[   38.591941] pc : ktime_get_real_ts64+0x3c/0x110
[   38.596487] lr : spi_take_timestamp_pre+0x40/0x90
[   38.601203] sp : ffff800010003d90
[   38.604525] x29: ffff800010003d90 x28: ffff80001200e000
[   38.609854] x27: ffff800011da9000 x26: ffff002079c40400
[   38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0
[   38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377
[   38.625841] x21: 000000000000146e x20: ffff8000120c3000
[   38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948
[   38.636498] x17: 0000000000000000 x16: 0000000000000000
[   38.641826] x15: ffff800095ab3377 x14: 0720072007200720
[   38.647155] x13: 0720072007200765 x12: 0775076507750771
[   38.652483] x11: 0720076d076f0772 x10: 0000000000000040
[   38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8
[   38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60
[   38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377
[   38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0
[   38.679125] x1 : ffff800011daa000 x0 : 0000000000000026
[   38.684454] Call trace:
[   38.686905]  ktime_get_real_ts64+0x3c/0x110
[   38.691100]  spi_take_timestamp_pre+0x40/0x90
[   38.695470]  dspi_fifo_write+0x58/0x2c0
[   38.699315]  dspi_interrupt+0xbc/0xd0
[   38.702987]  __handle_irq_event_percpu+0x78/0x2c0
[   38.707706]  handle_irq_event_percpu+0x3c/0x90
[   38.712161]  handle_irq_event+0x4c/0xd0
[   38.716008]  handle_fasteoi_irq+0xbc/0x170
[   38.720115]  generic_handle_irq+0x2c/0x40
[   38.724135]  __handle_domain_irq+0x68/0xc0
[   38.728243]  gic_handle_irq+0xc8/0x160
[   38.732000]  el1_irq+0xb8/0x180
[   38.735149]  spi_nor_spimem_read_data+0xe0/0x140
[   38.739779]  spi_nor_read+0xc4/0x120
[   38.743364]  mtd_read_oob+0xa8/0xc0
[   38.746860]  mtd_read+0x4c/0x80
[   38.750007]  mtdchar_read+0x108/0x2a0
[   38.753679]  __vfs_read+0x20/0x50
[   38.757002]  vfs_read+0xa4/0x190
[   38.760237]  ksys_read+0x6c/0xf0
[   38.763471]  __arm64_sys_read+0x20/0x30
[   38.767319]  el0_svc_common.constprop.3+0x90/0x160
[   38.772125]  do_el0_svc+0x28/0x90
[   38.775449]  el0_sync_handler+0x118/0x190
[   38.779468]  el0_sync+0x140/0x180
[   38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0)
[   38.788910] ---[ end trace 55da560db4d6bef7 ]---
[   38.793540] Kernel panic - not syncing: Fatal exception in interrupt
[   38.799914] SMP: stopping secondary CPUs
[   38.803849] Kernel Offset: disabled
[   38.807344] CPU features: 0x10002,20006008
[   38.811451] Memory Limit: none
[   38.814513] ---[ end Kernel panic - not syncing: Fatal exception in 
interrupt ]---



In DMA mode one byte writes seem to work. But at least 5 byte writes do 
not:

# echo -ne '\x00' > /dev/mtd10
# echo 'huhu' > /dev/mtd10
[   34.275383] fsl-dspi 2120000.spi: DMA tx timeout
[   34.280035] fsl-dspi 2120000.spi: DMA transfer failed
[   34.285116] fsl-dspi 2120000.spi: Waiting for transfer to complete 
failed!
[   34.292029] spi_master spi2: failed to transfer one message from 
queue
sh: write error: Connection timed out
#

Vladimir, what kind of SPI device do you have to test?

-michael



> 
> Vladimir Oltean (6):
>   spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR
>   spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
>   spi: spi-fsl-dspi: Fix oper_word_size of zero for DMA mode
>   spi: spi-fsl-dspi: Add support for LS1028A
>   arm64: dts: ls1028a: Specify the DMA channels for the DSPI 
> controllers
>   arm64: dts: ls1028a-rdb: Add a spidev node for the mikroBUS
> 
>  .../boot/dts/freescale/fsl-ls1028a-rdb.dts    | 14 ++++++
>  .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi |  6 +++
>  drivers/spi/spi-fsl-dspi.c                    | 50 +++++++++++++++----
>  3 files changed, 60 insertions(+), 10 deletions(-)

Re: [PATCH v2 0/6] NXP DSPI bugfixes and support for LS1028A

[Vladimir Oltean]

On Tue, 10 Mar 2020 at 10:34, Michael Walle <michael-QKn5cuLxLXY@public.gmane.org> wrote:
>

> So starting with XSPI, if you have a big flash and cancel the readout
> strange things happen.
>
> # hexdump -C /dev/mtd0
> 00000000  00 75 68 75 0a ff ff ff  ff ff ff ff ff ff ff ff
> |.uhu............|
> 00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
> |................|
> *
> ^C[   35.487948] fsl-dspi 2120000.spi: Waiting for transfer to complete
> failed!
> [   35.495038] spi_master spi2: failed to transfer one message from
> queue
>

This, I think, is expected.

> # hexdump -C /dev/mtd0
> 00000000  00 75 68 75 0a ff ff ff  ff ff ff ff ff ff ff ff
> |.uhu............|
> 00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
> |................|
> *
> ^C[   38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete
> failed!
> [   38.503097] spi_master spi2: failed to transfer one message from
> queue
> [   38.509729] Unable to handle kernel paging request at virtual address
> ffff800095ab3377
> [   38.517676] Mem abort info:
> [   38.520474]   ESR = 0x96000045
> [   38.523533]   EC = 0x25: DABT (current EL), IL = 32 bits
> [   38.528861]   SET = 0, FnV = 0
> [   38.531921]   EA = 0, S1PTW = 0
> [   38.535067] Data abort info:
> [   38.537952]   ISV = 0, ISS = 0x00000045
> [   38.541797]   CM = 0, WnR = 1
> [   38.544771] swapper pgtable: 4k pages, 48-bit VAs,
> pgdp=0000000082621000
> [   38.551494] [ffff800095ab3377] pgd=00000020fffff003,
> p4d=00000020fffff003, pud=0000000000000000
> [   38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP
> [   38.565819] Modules linked in:
> [   38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted
> 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193
> [   38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC
> Eval 2.0 carrier (DT)
> [   38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO)
> [   38.591941] pc : ktime_get_real_ts64+0x3c/0x110
> [   38.596487] lr : spi_take_timestamp_pre+0x40/0x90
> [   38.601203] sp : ffff800010003d90
> [   38.604525] x29: ffff800010003d90 x28: ffff80001200e000
> [   38.609854] x27: ffff800011da9000 x26: ffff002079c40400
> [   38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0
> [   38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377
> [   38.625841] x21: 000000000000146e x20: ffff8000120c3000
> [   38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948
> [   38.636498] x17: 0000000000000000 x16: 0000000000000000
> [   38.641826] x15: ffff800095ab3377 x14: 0720072007200720
> [   38.647155] x13: 0720072007200765 x12: 0775076507750771
> [   38.652483] x11: 0720076d076f0772 x10: 0000000000000040
> [   38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8
> [   38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60
> [   38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377
> [   38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0
> [   38.679125] x1 : ffff800011daa000 x0 : 0000000000000026
> [   38.684454] Call trace:
> [   38.686905]  ktime_get_real_ts64+0x3c/0x110
> [   38.691100]  spi_take_timestamp_pre+0x40/0x90
> [   38.695470]  dspi_fifo_write+0x58/0x2c0
> [   38.699315]  dspi_interrupt+0xbc/0xd0
> [   38.702987]  __handle_irq_event_percpu+0x78/0x2c0
> [   38.707706]  handle_irq_event_percpu+0x3c/0x90
> [   38.712161]  handle_irq_event+0x4c/0xd0
> [   38.716008]  handle_fasteoi_irq+0xbc/0x170
> [   38.720115]  generic_handle_irq+0x2c/0x40
> [   38.724135]  __handle_domain_irq+0x68/0xc0
> [   38.728243]  gic_handle_irq+0xc8/0x160
> [   38.732000]  el1_irq+0xb8/0x180
> [   38.735149]  spi_nor_spimem_read_data+0xe0/0x140
> [   38.739779]  spi_nor_read+0xc4/0x120
> [   38.743364]  mtd_read_oob+0xa8/0xc0
> [   38.746860]  mtd_read+0x4c/0x80
> [   38.750007]  mtdchar_read+0x108/0x2a0
> [   38.753679]  __vfs_read+0x20/0x50
> [   38.757002]  vfs_read+0xa4/0x190
> [   38.760237]  ksys_read+0x6c/0xf0
> [   38.763471]  __arm64_sys_read+0x20/0x30
> [   38.767319]  el0_svc_common.constprop.3+0x90/0x160
> [   38.772125]  do_el0_svc+0x28/0x90
> [   38.775449]  el0_sync_handler+0x118/0x190
> [   38.779468]  el0_sync+0x140/0x180
> [   38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0)
> [   38.788910] ---[ end trace 55da560db4d6bef7 ]---
> [   38.793540] Kernel panic - not syncing: Fatal exception in interrupt
> [   38.799914] SMP: stopping secondary CPUs
> [   38.803849] Kernel Offset: disabled
> [   38.807344] CPU features: 0x10002,20006008
> [   38.811451] Memory Limit: none
> [   38.814513] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt ]---
>

And this, I think, isn't. I've sent a new patch that addresses this in
v3, although it's always been like this as far as I can tell.

>
>
> In DMA mode one byte writes seem to work. But at least 5 byte writes do
> not:
>
> # echo -ne '\x00' > /dev/mtd10
> # echo 'huhu' > /dev/mtd10
> [   34.275383] fsl-dspi 2120000.spi: DMA tx timeout
> [   34.280035] fsl-dspi 2120000.spi: DMA transfer failed
> [   34.285116] fsl-dspi 2120000.spi: Waiting for transfer to complete
> failed!
> [   34.292029] spi_master spi2: failed to transfer one message from
> queue
> sh: write error: Connection timed out
> #
>

Correct, thanks for pointing out. Fixed this in v3.

> Vladimir, what kind of SPI device do you have to test?
>
> -michael
>

spidev_test --input <file-generated-with-hex-editor>
and watch the output with a protocol analyzer.

Thanks,
-Vladimir