Issues with i.MX SPI DMA transfers

Issues with i.MX SPI DMA transfers

[Igor Plyatov]

Dear Robin,

>> now I have reverted patch ad0d92d7ba6a.
>> Patches 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch and
>> 0002-spi-spi-imx-fix-ERR009165.patch are applied.
>>
>>
>> Kernel log show messages
>>
>> [   29.202639] imx-sdma 20ec000.sdma: loaded firmware 3.3
>> [   29.238595] spi_imx 2008000.spi: probed
>> [   29.242802] spi_imx 200c000.spi: probed
>> [   29.245217] spi_imx 2018000.spi: probed
>>
>> SPI DMA transfers still not work.
>>
>> If I test 32 byte transfers, then they work fine. But 64 byte transfers
>> fails always and I see error messages
>>
>> root@cr7:~# spidev_test -D /dev/spidev4.1 -s 1200000 -b 8 -S 64 -I 1 -l
>> spi mode: 0x20
>> bits per word: 8
>> max speed: 1200000 Hz (1200 KHz)
>> [  423.686736] spi_master spi4: I/O Error in DMA RX
>> [  423.691392] spidev spi4.1: SPI transfer failed: -110
>> [  423.696382] spi_master spi4: failed to transfer one message from queue
>> can't send spi message: Connection timed out
>> Aborted (core dumped)
>>
>> I suppose, transfers shorter then 64 bytes made with help of PIO.
>>
>> Robin, is there any chance for you to find some time and look at this
>> issue again?
> I have quick test with spidev_test loopback, but didn't meet your error,
> Is your code the almost latest code in linux-next as mine?
>
> root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
>   48:         37       GPC   2 Level     sdma
>   -lt@imx6qpdlsolox:~# ./spidev_test -D /dev/spidev0.0 -s 1200000 -b 8 -S 64 -I 1 -l
> spi mode: 0x20
> bits per word: 8
> max speed: 1200000 Hz (1200 KHz)
> root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
>   48:         43       GPC   2 Level     sdma
> ./spidev_test -D /dev/spidev0.0 -s 1200000 -b 8 -S 512 -I 1 -l
> spi mode: 0x20
> bits per word: 8
> max speed: 1200000 Hz (1200 KHz)
> total: tx 0.5KB, rx 0.5KB


My previous test results based on kernel from "main" branch of 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git.

Now I have tested kernel from "main" branch of 
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git.

Its latest commit is 05d08e2995cbe6efdb993482ee0d38a77040861a.

Additionally, I have reverted patch ad0d92d7ba6a and apply yours patches 
0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch and 
0002-spi-spi-imx-fix-ERR009165.patch.

Difference between 05d08e2995cbe6efdb993482ee0d38a77040861a and current 
state of drivers attached as spi-and-sdma-drivers.diff.

SPI driver still not work. It has same result as from my previous email.

Looks as you use either different GIT branch of kernel or you have 
forget to say me about some patch.

Best wishes.
---

Igor Plyatov

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 5f3c1378b90e..908507fa9526 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -377,7 +377,6 @@ struct sdma_channel {
 	unsigned long			watermark_level;
 	u32				shp_addr, per_addr;
 	enum dma_status			status;
-	bool				context_loaded;
 	struct imx_dma_data		data;
 	struct work_struct		terminate_worker;
 };
@@ -913,6 +912,9 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 		emi_2_per = sdma->script_addrs->mcu_2_ata_addr;
 		break;
 	case IMX_DMATYPE_CSPI:
+		per_2_emi = sdma->script_addrs->app_2_mcu_addr;
+		emi_2_per = sdma->script_addrs->mcu_2_ecspi_addr;
+		break;
 	case IMX_DMATYPE_EXT:
 	case IMX_DMATYPE_SSI:
 	case IMX_DMATYPE_SAI:
@@ -976,9 +978,6 @@ static int sdma_load_context(struct sdma_channel *sdmac)
 	int ret;
 	unsigned long flags;
 
-	if (sdmac->context_loaded)
-		return 0;
-
 	if (sdmac->direction == DMA_DEV_TO_MEM)
 		load_address = sdmac->pc_from_device;
 	else if (sdmac->direction == DMA_DEV_TO_DEV)
@@ -1021,8 +1020,6 @@ static int sdma_load_context(struct sdma_channel *sdmac)
 
 	spin_unlock_irqrestore(&sdma->channel_0_lock, flags);
 
-	sdmac->context_loaded = true;
-
 	return ret;
 }
 
@@ -1062,7 +1059,6 @@ static void sdma_channel_terminate_work(struct work_struct *work)
 	sdmac->desc = NULL;
 	spin_unlock_irqrestore(&sdmac->vc.lock, flags);
 	vchan_dma_desc_free_list(&sdmac->vc, &head);
-	sdmac->context_loaded = false;
 }
 
 static int sdma_disable_channel_async(struct dma_chan *chan)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 09c9a1edb2c6..27578158d922 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -585,8 +585,9 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
 	ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
 	spi_imx->spi_bus_clk = clk;
 
+	/* ERR009165: work in XHC mode as PIO */
 	if (spi_imx->usedma)
-		ctrl |= MX51_ECSPI_CTRL_SMC;
+		ctrl &= ~MX51_ECSPI_CTRL_SMC;
 
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -1265,10 +1266,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 {
 	int ret;
 
-	/* use pio mode for i.mx6dl chip TKT238285 */
-	if (of_machine_is_compatible("fsl,imx6dl"))
-		return 0;
-
 	spi_imx->wml = spi_imx->devtype_data->fifo_size / 2;
 
 	/* Prepare for TX DMA: */
diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
index 6eaa53cef0bd..f794fee8fc0f 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -51,6 +51,7 @@ struct sdma_script_start_addrs {
 	/* End of v2 array */
 	s32 zcanfd_2_mcu_addr;
 	s32 zqspi_2_mcu_addr;
+	s32 mcu_2_ecspi_addr;
 	/* End of v3 array */
 };
 

Issues with i.MX SPI DMA transfers

[Robin Gong]

> -----Original Message-----
> From: Igor Plyatov <plyatov@gmail.com>
> Sent: 2019年4月2日 20:15
> To: Robin Gong <yibin.gong@nxp.com>
> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-spi@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Pengutronix Kernel Team <kernel@pengutronix.de>;
> Sascha Hauer <s.hauer@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Mark Brown <broonie@kernel.org>;
> dmaengine@vger.kernel.org; Vinod Koul <vkoul@kernel.org>; Dan Williams
> <dan.j.williams@intel.com>; Andy Duan <fugang.duan@nxp.com>; Han Xu
> <han.xu@nxp.com>; Clark Wang <xiaoning.wang@nxp.com>
> Subject: Re: Issues with i.MX SPI DMA transfers
> 
> Dear Robin,
> 
> >> now I have reverted patch ad0d92d7ba6a.
> >> Patches 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch and
> >> 0002-spi-spi-imx-fix-ERR009165.patch are applied.
> >>
> >>
> >> Kernel log show messages
> >>
> >> [   29.202639] imx-sdma 20ec000.sdma: loaded firmware 3.3 [
> >> 29.238595] spi_imx 2008000.spi: probed [   29.242802] spi_imx
> >> 200c000.spi: probed [   29.245217] spi_imx 2018000.spi: probed
> >>
> >> SPI DMA transfers still not work.
> >>
> >> If I test 32 byte transfers, then they work fine. But 64 byte
> >> transfers fails always and I see error messages
> >>
> >> root@cr7:~# spidev_test -D /dev/spidev4.1 -s 1200000 -b 8 -S 64 -I 1
> >> -l spi mode: 0x20 bits per word: 8 max speed: 1200000 Hz (1200 KHz) [
> >> 423.686736] spi_master spi4: I/O Error in DMA RX [  423.691392]
> >> spidev spi4.1: SPI transfer failed: -110 [  423.696382] spi_master
> >> spi4: failed to transfer one message from queue can't send spi
> >> message: Connection timed out Aborted (core dumped)
> >>
> >> I suppose, transfers shorter then 64 bytes made with help of PIO.
> >>
> >> Robin, is there any chance for you to find some time and look at this
> >> issue again?
> > I have quick test with spidev_test loopback, but didn't meet your
> > error, Is your code the almost latest code in linux-next as mine?
> >
> > root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
> >   48:         37       GPC   2 Level     sdma
> >   -lt@imx6qpdlsolox:~# ./spidev_test -D /dev/spidev0.0 -s 1200000 -b 8
> > -S 64 -I 1 -l spi mode: 0x20 bits per word: 8 max speed: 1200000 Hz
> > (1200 KHz) root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
> >   48:         43       GPC   2 Level     sdma
> > ./spidev_test -D /dev/spidev0.0 -s 1200000 -b 8 -S 512 -I 1 -l spi
> > mode: 0x20 bits per word: 8 max speed: 1200000 Hz (1200 KHz)
> > total: tx 0.5KB, rx 0.5KB
> 
> 
> My previous test results based on kernel from "main" branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git.
> 
> Now I have tested kernel from "main" branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git.
> 
> Its latest commit is 05d08e2995cbe6efdb993482ee0d38a77040861a.
> 
> Additionally, I have reverted patch ad0d92d7ba6a and apply yours patches
> 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch and
> 0002-spi-spi-imx-fix-ERR009165.patch.
> 
> Difference between 05d08e2995cbe6efdb993482ee0d38a77040861a and
> current state of drivers attached as spi-and-sdma-drivers.diff.
> 
> SPI driver still not work. It has same result as from my previous email.
> 
> Looks as you use either different GIT branch of kernel or you have forget to say
> me about some patch.
The same base as your side commit '05d08e2995cbe6efdb993482ee0d38a77040861a ' and
same diff, but did you revert another sdma patch about "clk_ratio" which broke sdma basic
function on non-i.mx8m chips?

commit 25aaa75df1e659901d77085bcdd25eaabf265688
Author: Angus Ainslie (Purism) <angus@akkea.ca>
Date:   Mon Jan 28 09:03:21 2019 -0700

    dmaengine: imx-sdma: add clock ratio 1:1 check

    On i.mx8 mscale B0 chip, AHB/SDMA clock ratio 2:1 can't be supportted,
    since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach
    to 500Mhz, so use 1:1 instead.
> 
> Best wishes.
> 
> --
> 
> Igor Plyatov

Issues with i.MX SPI DMA transfers

[Igor Plyatov]

Dear Robin,


> Please apply the attached patch which is based on linux-next commit 
> 05d08e2995cbe6efdb993482ee0d38a77040861a.
> Please notice it has already contained two sdma patches revert - "ad0d92d7ba6a" and "25aaa75df1e6"

1) Yours source code is same as mine with exception of SDMA description 
for eCSPI in Device Tree.

I have changed Device Tree for i.MX6Q/DL as in attached patch and 
finally SPI interfaces operate more or less.

My patch revert back patches df07101e1c4a29e820df02f9989a066988b160e6 
and dd4b487b32a3571fdcc66062e661e3a3e360e35b. It is strange, because 
they are merged into mainline while ago. Maybe they are valid for some 
specific variant of i.MX SOC?

"More or less" means I have come to state described in first e-mail of 
this e-mail thread. Byte duplication (ERR009165) happens very often for 
eCSPI5 interface operating through DMA.

Test Conditions:
1.1. Interface under test is eCSPI1 or eCSPI5;
1.2. Four exemplars of "burn-neon" (CPU burn) executes in background to 
have 100% load for all 4 CPU cores (source code taken from 
https://raw.githubusercontent.com/ssvb/cpuburn-arm/dd5c5ba58d2b0b23cfab4a286f9d3f5510000f20/cpuburn-a8.S 
and https://hardwarebug.org/files/burn.S);
1.3. PC has running "ping -f embedded_device" to have network activity 
around 1 MiB/s Rx and Tx;
1.4. One exemplar of "spidev_test -D /dev/spidevX.0 -s FREQUENCY -b 8 -S 
512 -I 1000000 -l" executes at different frequencies;

Test Results for eCSPI1:
21 MHz    - success;
20 MHz    - success;
...
16 MHz    - success;
...
  8 MHz    - success;

Test Results for eCSPI5:
21 MHz    - failed;
20 MHz    - failed;
19 MHz    - failed;
...
12 MHz    - failed;
11 MHz    - failed;
10 MHz    - failed;
  9 MHz    - failed;
  8 MHz    - failed;
  7 MHz    - failed;
  6 MHz    - failed;
  5 MHz    - failed;
  4 MHz    - success.

Maybe it is worth to dump content of registers for eCSPI1 and eCSPI5 to 
compare them? I can do this if you will describe how to make it.

Maybe I'm wrong, but I suppose incorrect clock source for eCSPI5. Looks 
like it is worth to check correctness of driver "clk-imx6q.c" or 
something else responsible for eCSPI5 clock.


2) I want to improve description and replace magic numbers by constants 
in Device Tree for SDMA. I mean strings like "dmas = <&sdma 11 7 1>, 
<&sdma 12 7 2>;"?

So, finally Device Tree will have strings like

dmas = <&sdma SOME_DEF_A IMX_DMATYPE_.. DMA_PRIO_..>, <&sdma SOME_DEF_B 
IMX_DMATYPE_.. DMA_PRIO_..>;

I think, this will stop black magic manipulations for SDMA in Device 
Tree, by various developers.

Does first digit means "DMA request/event ID"? Where to find more info 
about this?

Does second digit means "enum sdma_peripheral_type"?

Does third digit means "enum imx_dma_prio"?

Where can I find description of difference between IMX_DMATYPE_CSPI (MCU 
domain CSPI) and IMX_DMATYPE_CSPI_SP (Shared CSPI)? Googling does not 
help too much.

Best wishes.
---
Igor Plyatov

From 2aa277ff36998b805cec803b23d9c746a2a107b7 Mon Sep 17 00:00:00 2001
From: Igor Plyatov <plyatov@gmail.com>
Date: Wed, 3 Apr 2019 14:51:17 +0300
Subject: [PATCH] Bugfix for incorrect eCSPI SDMA numbers.

* This revert back commits df07101e1c4a29e820df02f9989a066988b160e6 and
  dd4b487b32a3571fdcc66062e661e3a3e360e35b, because they lead to kernel
  errors like
  "spi_master spi4: I/O Error in DMA RX
   spidev spi4.1: SPI transfer failed: -110."
  Tested on i.MX6 Quad/DualLite SOC.

Signed-off-by: Igor Plyatov <plyatov@gmail.com>
---
 arch/arm/boot/dts/imx6q.dtsi   | 2 +-
 arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index d038f4117024..7175898f854e 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -172,7 +172,7 @@
 					clocks = <&clks IMX6Q_CLK_ECSPI5>,
 						 <&clks IMX6Q_CLK_ECSPI5>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 11 8 1>, <&sdma 12 8 2>;
+					dmas = <&sdma 11 7 1>, <&sdma 12 7 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 2eb4c779298b..36c48a18e39a 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -338,7 +338,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI1>,
 						 <&clks IMX6QDL_CLK_ECSPI1>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 3 8 1>, <&sdma 4 8 2>;
+					dmas = <&sdma 3 7 1>, <&sdma 4 7 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
@@ -352,7 +352,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI2>,
 						 <&clks IMX6QDL_CLK_ECSPI2>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 5 8 1>, <&sdma 6 8 2>;
+					dmas = <&sdma 5 7 1>, <&sdma 6 7 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
@@ -366,7 +366,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI3>,
 						 <&clks IMX6QDL_CLK_ECSPI3>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 7 8 1>, <&sdma 8 8 2>;
+					dmas = <&sdma 7 7 1>, <&sdma 8 7 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
@@ -380,7 +380,7 @@
 					clocks = <&clks IMX6QDL_CLK_ECSPI4>,
 						 <&clks IMX6QDL_CLK_ECSPI4>;
 					clock-names = "ipg", "per";
-					dmas = <&sdma 9 8 1>, <&sdma 10 8 2>;
+					dmas = <&sdma 9 7 1>, <&sdma 10 7 2>;
 					dma-names = "rx", "tx";
 					status = "disabled";
 				};
-- 
2.17.1

Issues with i.MX SPI DMA transfers

[Robin Gong]

> -----Original Message-----
> From: Igor Plyatov <plyatov@gmail.com>
> Sent: 2019年4月3日 23:51
> To: Robin Gong <yibin.gong@nxp.com>
> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-spi@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Pengutronix Kernel Team <kernel@pengutronix.de>;
> Sascha Hauer <s.hauer@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Mark Brown <broonie@kernel.org>;
> dmaengine@vger.kernel.org; Vinod Koul <vkoul@kernel.org>; Dan Williams
> <dan.j.williams@intel.com>; Andy Duan <fugang.duan@nxp.com>; Han Xu
> <han.xu@nxp.com>; Clark Wang <xiaoning.wang@nxp.com>
> Subject: Re: Issues with i.MX SPI DMA transfers
> 
> Dear Robin,
> 
> 
> > Please apply the attached patch which is based on linux-next commit
> > 05d08e2995cbe6efdb993482ee0d38a77040861a.
> > Please notice it has already contained two sdma patches revert -
> "ad0d92d7ba6a" and "25aaa75df1e6"
> 
> 1) Yours source code is same as mine with exception of SDMA description for
> eCSPI in Device Tree.
> 
> I have changed Device Tree for i.MX6Q/DL as in attached patch and finally SPI
> interfaces operate more or less.
> 
> My patch revert back patches df07101e1c4a29e820df02f9989a066988b160e6
> and dd4b487b32a3571fdcc66062e661e3a3e360e35b. It is strange, because
> they are merged into mainline while ago. Maybe they are valid for some
> specific variant of i.MX SOC?
Okay, now I can understand why it didn't not work in your side with sdma
from linux-firmware, because the workaround of ERR009165 is only fixed in 
AIPS ram script with simulating PIO in XCH mode instead of SMC mode, but not fixed
In SHP script which used by Sascha's rom patch dd4b487b32a3. 
Sorry, I'm not very clear about Sascha's patch which seems the same as ERR009165. But
at least, ecspi could work with app_2_mcu/mcu_2_app script, not 'must' be used with
shp_2_mcu/mcu_2_shp, because SPBA is also located in AIPS bus, please refer to the
below information from RM. So I am afraid Sascha's patch may not solid.
"A.3.1.6 app_2_mcu
This generic script is used to transfer data from a 8, 16, 24 or 32-bit peripheral connected
to the AIPS accessed through the Periphera DMA of SDMA, to memories accessed by
the BurstDMA (External memories)."


> 
> "More or less" means I have come to state described in first e-mail of this
> e-mail thread. Byte duplication (ERR009165) happens very often for
> eCSPI5 interface operating through DMA.
I could reproduce your issue as below whatever with my patches for ERR009165 or not, so
that's a new issue since it's only exist on ecspi5. Software is the same on all ecspi
port, so it's seems a hardware issue, I will involve design team to look into it. For now,
suggest you using other ecspi port if you can.

./spidev_test -D /dev/spidev4.0 -s 20000000 -b 8 -S 64 -I 100
spi mode: 0x20
bits per word: 8
max speed: 20000000 Hz (20000 KHz)


transfer error !
TX | E1 51 24 E9 F3 DC 3C 99 07 57 62 10 70 53 F5 86 DE 1C 9D 8D CD 7A 6A 46 5A 9A 30 3E 15 B0 53 F6  |.Q$...<..Wb.pS.......zjFZ.0>..S.|
TX | 01 77 DF F4 54 1B 8E 5B 73 F0 6B E3 43 60 69 21 7D 06 AE 4A 80 18 90 DB B3 C0 19 C8 70 6C BE 71  |.w..T..[s.k.C`i!}..J........pl.q|
RX | E1 51 24 E9 F3 F3 DC 3C 99 07 57 62 10 70 53 F5 86 DE 1C 9D 8D CD 7A 6A 46 5A 9A 30 3E 15 B0 53  |.Q$....<..Wb.pS.......zjFZ.0>..S|
RX | F6 01 77 DF F4 54 1B 8E 5B 73 F0 6B E3 43 60 69 21 7D 06 AE 4A 80 18 90 DB B3 C0 19 C8 70 6C BE  |..w..T..[s.k.C`i!}..J........pl.|
> 
> 2) I want to improve description and replace magic numbers by constants in
> Device Tree for SDMA. I mean strings like "dmas = <&sdma 11 7 1>, <&sdma
> 12 7 2>;"?
> 
> So, finally Device Tree will have strings like
> 
> dmas = <&sdma SOME_DEF_A IMX_DMATYPE_.. DMA_PRIO_..>, <&sdma
> SOME_DEF_B IMX_DMATYPE_.. DMA_PRIO_..>;
> 
> I think, this will stop black magic manipulations for SDMA in Device Tree, by
> various developers.
> 
> Does first digit means "DMA request/event ID"? Where to find more info about
> this?
Yes, that's mean dma event ID, you could find in "Table 3-2. SDMA event mapping"
from RM.
> 
> Does second digit means "enum sdma_peripheral_type"?
> 
> Does third digit means "enum imx_dma_prio"?
Yes.
> 
> Where can I find description of difference between IMX_DMATYPE_CSPI (MCU
> domain CSPI) and IMX_DMATYPE_CSPI_SP (Shared CSPI)? Googling does not
> help too much.
IMX_DMATYPE_CSPI use AIPS script, IMX_DMATYPE_CSPI_SP use SPBA script which 
SDMA could access peripherals on SPBA directly, AIPS script could be used by all peripherals
since only few peripherals on SPBA but SPBA script is more efficiency because of short path.

> 
> Best wishes.
> --
> Igor Plyatov

RE: Issues with i.MX SPI DMA transfers

[Robin Gong]

> -----Original Message-----
> From: Igor Plyatov <plyatov@gmail.com>
> Sent: 2019年4月3日 23:51
> To: Robin Gong <yibin.gong@nxp.com>
> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-spi@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Pengutronix Kernel Team <kernel@pengutronix.de>;
> Sascha Hauer <s.hauer@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Mark Brown <broonie@kernel.org>;
> dmaengine@vger.kernel.org; Vinod Koul <vkoul@kernel.org>; Dan Williams
> <dan.j.williams@intel.com>; Andy Duan <fugang.duan@nxp.com>; Han Xu
> <han.xu@nxp.com>; Clark Wang <xiaoning.wang@nxp.com>
> Subject: Re: Issues with i.MX SPI DMA transfers
> 
> Dear Robin,
> 
> 
> > Please apply the attached patch which is based on linux-next commit
> > 05d08e2995cbe6efdb993482ee0d38a77040861a.
> > Please notice it has already contained two sdma patches revert -
> "ad0d92d7ba6a" and "25aaa75df1e6"
> 
> 1) Yours source code is same as mine with exception of SDMA description for
> eCSPI in Device Tree.
> 
> I have changed Device Tree for i.MX6Q/DL as in attached patch and finally SPI
> interfaces operate more or less.
> 
> My patch revert back patches df07101e1c4a29e820df02f9989a066988b160e6
> and dd4b487b32a3571fdcc66062e661e3a3e360e35b. It is strange, because
> they are merged into mainline while ago. Maybe they are valid for some
> specific variant of i.MX SOC?
Okay, now I can understand why it didn't not work in your side with sdma
from linux-firmware, because the workaround of ERR009165 is only fixed in 
AIPS ram script with simulating PIO in XCH mode instead of SMC mode, but not fixed
In SHP script which used by Sascha's rom patch dd4b487b32a3. 
Sorry, I'm not very clear about Sascha's patch which seems the same as ERR009165. But
at least, ecspi could work with app_2_mcu/mcu_2_app script, not 'must' be used with
shp_2_mcu/mcu_2_shp, because SPBA is also located in AIPS bus, please refer to the
below information from RM. So I am afraid Sascha's patch may not solid.
"A.3.1.6 app_2_mcu
This generic script is used to transfer data from a 8, 16, 24 or 32-bit peripheral connected
to the AIPS accessed through the Periphera DMA of SDMA, to memories accessed by
the BurstDMA (External memories)."


> 
> "More or less" means I have come to state described in first e-mail of this
> e-mail thread. Byte duplication (ERR009165) happens very often for
> eCSPI5 interface operating through DMA.
I could reproduce your issue as below whatever with my patches for ERR009165 or not, so
that's a new issue since it's only exist on ecspi5. Software is the same on all ecspi
port, so it's seems a hardware issue, I will involve design team to look into it. For now,
suggest you using other ecspi port if you can.

./spidev_test -D /dev/spidev4.0 -s 20000000 -b 8 -S 64 -I 100
spi mode: 0x20
bits per word: 8
max speed: 20000000 Hz (20000 KHz)


transfer error !
TX | E1 51 24 E9 F3 DC 3C 99 07 57 62 10 70 53 F5 86 DE 1C 9D 8D CD 7A 6A 46 5A 9A 30 3E 15 B0 53 F6  |.Q$...<..Wb.pS.......zjFZ.0>..S.|
TX | 01 77 DF F4 54 1B 8E 5B 73 F0 6B E3 43 60 69 21 7D 06 AE 4A 80 18 90 DB B3 C0 19 C8 70 6C BE 71  |.w..T..[s.k.C`i!}..J........pl.q|
RX | E1 51 24 E9 F3 F3 DC 3C 99 07 57 62 10 70 53 F5 86 DE 1C 9D 8D CD 7A 6A 46 5A 9A 30 3E 15 B0 53  |.Q$....<..Wb.pS.......zjFZ.0>..S|
RX | F6 01 77 DF F4 54 1B 8E 5B 73 F0 6B E3 43 60 69 21 7D 06 AE 4A 80 18 90 DB B3 C0 19 C8 70 6C BE  |..w..T..[s.k.C`i!}..J........pl.|
> 
> 2) I want to improve description and replace magic numbers by constants in
> Device Tree for SDMA. I mean strings like "dmas = <&sdma 11 7 1>, <&sdma
> 12 7 2>;"?
> 
> So, finally Device Tree will have strings like
> 
> dmas = <&sdma SOME_DEF_A IMX_DMATYPE_.. DMA_PRIO_..>, <&sdma
> SOME_DEF_B IMX_DMATYPE_.. DMA_PRIO_..>;
> 
> I think, this will stop black magic manipulations for SDMA in Device Tree, by
> various developers.
> 
> Does first digit means "DMA request/event ID"? Where to find more info about
> this?
Yes, that's mean dma event ID, you could find in "Table 3-2. SDMA event mapping"
from RM.
> 
> Does second digit means "enum sdma_peripheral_type"?
> 
> Does third digit means "enum imx_dma_prio"?
Yes.
> 
> Where can I find description of difference between IMX_DMATYPE_CSPI (MCU
> domain CSPI) and IMX_DMATYPE_CSPI_SP (Shared CSPI)? Googling does not
> help too much.
IMX_DMATYPE_CSPI use AIPS script, IMX_DMATYPE_CSPI_SP use SPBA script which 
SDMA could access peripherals on SPBA directly, AIPS script could be used by all peripherals
since only few peripherals on SPBA but SPBA script is more efficiency because of short path.

> 
> Best wishes.
> --
> Igor Plyatov

RE: Issues with i.MX SPI DMA transfers

[Robin Gong]

[-- Attachment #1: Type: text/plain, Size: 3911 bytes --]

Hi Igor,
	Please have a try with the attached patches, and revert 25aaa75df1e6, ad0d92d7ba6a
, dd4b487b32a3, df07101e1c4a before apply. Besides XCH, tx thresh should be set to 0 ,
now no failure caught on ecspi5.

> -----Original Message-----
> From: Robin Gong
> Sent: 2019年4月2日 16:33
> To: 'Igor Plyatov' <plyatov@gmail.com>; Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de>
> Cc: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-spi@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Fabio Estevam
> <festevam@gmail.com>; Pengutronix Kernel Team <kernel@pengutronix.de>;
> Sascha Hauer <s.hauer@pengutronix.de>; Shawn Guo
> <shawnguo@kernel.org>; Mark Brown <broonie@kernel.org>;
> dmaengine@vger.kernel.org; Vinod Koul <vkoul@kernel.org>; Dan Williams
> <dan.j.williams@intel.com>; Andy Duan <fugang.duan@nxp.com>; Han Xu
> <han.xu@nxp.com>; Clark Wang <xiaoning.wang@nxp.com>
> Subject: RE: Issues with i.MX SPI DMA transfers
> 
> > -----Original Message-----
> > From: Igor Plyatov <plyatov@gmail.com>
> > Sent: 2019年4月2日 15:20
> > To: Robin Gong <yibin.gong@nxp.com>; Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de>
> > Cc: linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org;
> > linux-spi@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Fabio
> > Estevam <festevam@gmail.com>; Pengutronix Kernel Team
> > <kernel@pengutronix.de>; Sascha Hauer <s.hauer@pengutronix.de>; Shawn
> > Guo <shawnguo@kernel.org>; Mark Brown <broonie@kernel.org>;
> > dmaengine@vger.kernel.org; Vinod Koul <vkoul@kernel.org>; Dan Williams
> > <dan.j.williams@intel.com>; Andy Duan <fugang.duan@nxp.com>; Han Xu
> > <han.xu@nxp.com>; Clark Wang <xiaoning.wang@nxp.com>
> > Subject: Re: Issues with i.MX SPI DMA transfers
> >
> > Dear Robin Gong,
> >
> >
> > >> Sorry...below another sdma patch(ad0d92d7ba6a) need to be reverted,
> > >> because spi driver may dynamically change burst length.
> >
> >
> > now I have reverted patch ad0d92d7ba6a.
> >
> > Patches 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch and
> > 0002-spi-spi-imx-fix-ERR009165.patch are applied.
> >
> >
> > Kernel log show messages
> >
> > [   29.202639] imx-sdma 20ec000.sdma: loaded firmware 3.3 [
> > 29.238595] spi_imx 2008000.spi: probed [   29.242802] spi_imx
> > 200c000.spi: probed [   29.245217] spi_imx 2018000.spi: probed
> >
> > SPI DMA transfers still not work.
> >
> > If I test 32 byte transfers, then they work fine. But 64 byte
> > transfers fails always and I see error messages
> >
> > root@cr7:~# spidev_test -D /dev/spidev4.1 -s 1200000 -b 8 -S 64 -I 1
> > -l spi mode: 0x20 bits per word: 8 max speed: 1200000 Hz (1200 KHz) [
> > 423.686736] spi_master spi4: I/O Error in DMA RX [  423.691392] spidev
> > spi4.1: SPI transfer failed: -110 [  423.696382] spi_master spi4:
> > failed to transfer one message from queue can't send spi message:
> > Connection timed out Aborted (core dumped)
> >
> > I suppose, transfers shorter then 64 bytes made with help of PIO.
> >
> > Robin, is there any chance for you to find some time and look at this
> > issue again?
> I have quick test with spidev_test loopback, but didn't meet your error, Is your
> code the almost latest code in linux-next as mine?
> 
> root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
>  48:         37       GPC   2 Level     sdma
>  -lt@imx6qpdlsolox:~# ./spidev_test -D /dev/spidev0.0 -s 1200000 -b 8 -S 64 -I
> 1 -l spi mode: 0x20 bits per word: 8 max speed: 1200000 Hz (1200 KHz)
> root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
>  48:         43       GPC   2 Level     sdma
> ./spidev_test -D /dev/spidev0.0 -s 1200000 -b 8 -S 512 -I 1 -l spi mode: 0x20 bits
> per word: 8 max speed: 1200000 Hz (1200 KHz)
> total: tx 0.5KB, rx 0.5KB
> >
> > Best wishes.
> > --
> > Igor Plyatov

[-- Attachment #2: 0005-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch --]
[-- Type: application/octet-stream, Size: 1369 bytes --]

From fbdf4153b4790a43a7396b5c78a848b4d0735f80 Mon Sep 17 00:00:00 2001
From: Robin Gong <yibin.gong@nxp.com>
Date: Thu, 28 Mar 2019 16:36:12 +0800
Subject: [PATCH 5/6] dma: engine: imx-sdma: add mcu_2_ecspi script

Add mcu_2_ecspi script to fix ecspi errata ERR009165.

Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
 drivers/dma/imx-sdma.c                     | 3 +++
 include/linux/platform_data/dma-imx-sdma.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index adc82d9..0cc52db 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -907,6 +907,9 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
 		emi_2_per = sdma->script_addrs->mcu_2_ata_addr;
 		break;
 	case IMX_DMATYPE_CSPI:
+		per_2_emi = sdma->script_addrs->app_2_mcu_addr;
+		emi_2_per = sdma->script_addrs->mcu_2_ecspi_addr;
+		break;
 	case IMX_DMATYPE_EXT:
 	case IMX_DMATYPE_SSI:
 	case IMX_DMATYPE_SAI:
diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
index 6eaa53c..f794fee 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -51,6 +51,7 @@ struct sdma_script_start_addrs {
 	/* End of v2 array */
 	s32 zcanfd_2_mcu_addr;
 	s32 zqspi_2_mcu_addr;
+	s32 mcu_2_ecspi_addr;
 	/* End of v3 array */
 };
 
-- 
2.7.4


[-- Attachment #3: 0006-spi-spi-imx-fix-ERR009165.patch --]
[-- Type: application/octet-stream, Size: 1635 bytes --]

From aa198c3265fb54d42715c5fa4c25d15a73ad934c Mon Sep 17 00:00:00 2001
From: Robin Gong <yibin.gong@nxp.com>
Date: Thu, 28 Mar 2019 16:38:13 +0800
Subject: [PATCH 6/6] spi: spi-imx: fix ERR009165

Change to XCH  mode even in dma mode, please refer to below
errata:
https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf

Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
 drivers/spi/spi-imx.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 09c9a1e..04af84d 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -585,8 +585,9 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,
 	ctrl |= mx51_ecspi_clkdiv(spi_imx, t->speed_hz, &clk);
 	spi_imx->spi_bus_clk = clk;
 
+	/* ERR009165: work in XHC mode as PIO */
 	if (spi_imx->usedma)
-		ctrl |= MX51_ECSPI_CTRL_SMC;
+		ctrl &= ~MX51_ECSPI_CTRL_SMC;
 
 	writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);
 
@@ -617,7 +618,6 @@ static void mx51_setup_wml(struct spi_imx_data *spi_imx)
 	 * and enable DMA request.
 	 */
 	writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml - 1) |
-		MX51_ECSPI_DMA_TX_WML(spi_imx->wml) |
 		MX51_ECSPI_DMA_RXT_WML(spi_imx->wml) |
 		MX51_ECSPI_DMA_TEDEN | MX51_ECSPI_DMA_RXDEN |
 		MX51_ECSPI_DMA_RXTDEN, spi_imx->base + MX51_ECSPI_DMA);
@@ -1265,10 +1265,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,
 {
 	int ret;
 
-	/* use pio mode for i.mx6dl chip TKT238285 */
-	if (of_machine_is_compatible("fsl,imx6dl"))
-		return 0;
-
 	spi_imx->wml = spi_imx->devtype_data->fifo_size / 2;
 
 	/* Prepare for TX DMA: */
-- 
2.7.4

RE: Issues with i.MX SPI DMA transfers

[Robin Gong]

Hi Igor,
	Did you meet any issue with my latest patch?

> -----Original Message-----
> From: Robin Gong
> Sent: April 9, 2019 11:26> 
> Hi Igor,
> 	Please have a try with the attached patches, and revert 25aaa75df1e6,
> ad0d92d7ba6a , dd4b487b32a3, df07101e1c4a before apply. Besides XCH, tx
> thresh should be set to 0 , now no failure caught on ecspi5.
> 

Re: Issues with i.MX SPI DMA transfers

[Igor Plyatov]

Dear Robin,

> Hi Igor,
> 	Did you meet any issue with my latest patch?

sorry, but unfortunately I have no time to test it.

I have switched to PIO mode and continue other development.

Maybe later I will find time to test DMA mode, but not sure when.

Thank you for support!

--

Igor Plyatov

>> -----Original Message-----
>> From: Robin Gong
>> Sent: April 9, 2019 11:26>
>> Hi Igor,
>> 	Please have a try with the attached patches, and revert 25aaa75df1e6,
>> ad0d92d7ba6a , dd4b487b32a3, df07101e1c4a before apply. Besides XCH, tx
>> thresh should be set to 0 , now no failure caught on ecspi5.
>>

Re: Issues with i.MX SPI DMA transfers

[Robin Gong]

On 2019-04-18 at 06:30 +0000, Igor Plyatov wrote:
> WARNING: This email was created outside of NXP. DO NOT CLICK links or
> attachments unless you recognize the sender and know the content is
> safe.
> 
> 
> 
> Dear Robin,
> 
> > 
> > Hi Igor,
> >       Did you meet any issue with my latest patch?
> sorry, but unfortunately I have no time to test it.
> 
> I have switched to PIO mode and continue other development.
> 
> Maybe later I will find time to test DMA mode, but not sure when.
> 
> Thank you for support!
Okay, I'll send out patch set to review, hope you could have chance to
try.
> 
> --
> 
> Igor Plyatov
> 
> > 
> > > 
> > > -----Original Message-----
> > > From: Robin Gong
> > > Sent: April 9, 2019 11:26>
> > > Hi Igor,
> > >      Please have a try with the attached patches, and revert
> > > 25aaa75df1e6,
> > > ad0d92d7ba6a , dd4b487b32a3, df07101e1c4a before apply. Besides
> > > XCH, tx
> > > thresh should be set to 0 , now no failure caught on ecspi5.
> > > 

Issues with i.MX SPI DMA transfers

[Igor Plyatov]

Dear Robin,

I have made additional tests on another exemplar of board with 
absolutely same hardware.

The spidev_test failed on eCSPI2 and eCSPI5 interfaces, but works 
successfully on eCSPI1 interface.

So, it looks, issue does not correspond to fixed interface number.

This is generic issue of i.MX6 SOC and hardly broken eCSPI interface 
number can change from SOC chip to chip.

Do you have any idea how to improve situation with eCSPI in DMA mode?

Best wishes.
---
Igor Plyatov