Re: Issues with i.MX SPI DMA transfers
[ Trimming recipients list ] On 03/04/2019 17:51, Igor Plyatov wrote: > 2) I want to improve description and replace magic numbers by constants > in Device Tree for SDMA. I mean strings like "dmas = < 11 7 1>, > < 12 7 2>;"? > > So, finally Device Tree will have strings like > > dmas = < SOME_DEF_A IMX_DMATYPE_.. DMA_PRIO_..>, < 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"? Start at Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt - dmas: DMA specifiers for tx and rx dma. See the DMA client binding, Documentation/devicetree/bindings/dma/dma.txt. - dma-names: DMA request names, if present, should include "tx" and "rx". Client drivers should specify the DMA property using a phandle to the controller followed by DMA controller specific data. Required property: - dmas: List of one or more DMA specifiers, each consisting of - A phandle pointing to DMA controller node - A number of integer cells, as determined by the #dma-cells property in the node referenced by phandle containing DMA controller specific information. This typically contains a DMA request line number or a channel number, but can contain any data that is required for configuring a channel. - dma-names:Contains one identifier string for each DMA specifier in the dmas property. The specific strings that can be used are defined in the binding of the DMA client device. Multiple DMA specifiers can be used to represent alternatives and in this case the dma-names for those DMA specifiers must be identical (see examples). Turning our attention to Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt - #dma-cells : Must be <3>. The first cell specifies the DMA request/event ID. See details below about the second and third cell. The second cell of dma phandle specifies the peripheral type of DMA transfer. The full ID of peripheral types can be found below. ID transfer type - 0 MCU domain SSI 1 Shared SSI 2 MMC 3 SDHC 4 MCU domain UART 5 Shared UART 6 FIRI 7 MCU domain CSPI 8 Shared CSPI 9 SIM 10 ATA 11 CCM 12 External peripheral 13 Memory Stick Host Controller 14 Shared Memory Stick Host Controller 15 DSP 16 Memory 17 FIFO type Memory 18 SPDIF 19 IPU Memory 20 ASRC 21 ESAI 22 SSI Dual FIFO (needs firmware ver >= 2) 23 Shared ASRC 24 SAI The third cell specifies the transfer priority as below. ID transfer priority - 0 High 1 Medium 2 Low
Re: Issues with i.MX SPI DMA transfers
On 2019-04-18 at 06:30 +, 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. > > >
Re: Issues with i.MX SPI DMA transfers
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
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
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' ; Uwe Kleine-König > > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam > ; Pengutronix Kernel Team ; > Sascha Hauer ; Shawn Guo > ; Mark Brown ; > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams > ; Andy Duan ; Han Xu > ; Clark Wang > Subject: RE: Issues with i.MX SPI DMA transfers > > > -Original Message- > > From: Igor Plyatov > > Sent: 2019年4月2日 15:20 > > To: Robin Gong ; Uwe Kleine-König > > > > Cc: linux-kernel@vger.kernel.org; > > linux-arm-ker...@lists.infradead.org; > > linux-...@vger.kernel.org; dl-linux-imx ; Fabio > > Estevam ; Pengutronix Kernel Team > > ; Sascha Hauer ; Shawn > > Guo ; Mark Brown ; > > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams > > ; Andy Duan ; Han Xu > > ; Clark Wang > > 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 120 -b 8 -S 64 -I 1 > > -l spi mode: 0x20 bits per word: 8 max speed: 120 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 120 -b 8 -S 64 -I > 1 -l spi mode: 0x20 bits per word: 8 max speed: 120 Hz (1200 KHz) > root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma > 48: 43 GPC 2 Level sdma > ./spidev_test -D /dev/spidev0.0 -s 120 -b 8 -S 512 -I 1 -l spi mode: 0x20 > bits > per word: 8 max speed: 120 Hz (1200 KHz) > total: tx 0.5KB, rx 0.5KB > > > > Best wishes. > > -- > > Igor Plyatov 0005-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch Description: 0005-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch 0006-spi-spi-imx-fix-ERR009165.patch Description: 0006-spi-spi-imx-fix-ERR009165.patch
RE: Issues with i.MX SPI DMA transfers
> -Original Message- > From: Igor Plyatov > Sent: 2019年4月3日 23:51 > To: Robin Gong > Cc: Uwe Kleine-König ; > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam > ; Pengutronix Kernel Team ; > Sascha Hauer ; Shawn Guo > ; Mark Brown ; > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams > ; Andy Duan ; Han Xu > ; Clark Wang > 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 2000 -b 8 -S 64 -I 100 spi mode: 0x20 bits per word: 8 max speed: 2000 Hz (2 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!}..Jpl.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!}..Jpl.| > > 2) I want to improve description and replace magic numbers by constants in > Device Tree for SDMA. I mean strings like "dmas = < 11 7 1>, < > 12 7 2>;"? > > So, finally Device Tree will have strings like > > dmas = < SOME_DEF_A IMX_DMATYPE_.. DMA_PRIO_..>, < > 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
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
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? "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/dd5c5ba58d2b0b23cfab4a286f9d3f551f20/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 100 -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 = < 11 7 1>, < 12 7 2>;"? So, finally Device Tree will have strings like dmas = < SOME_DEF_A IMX_DMATYPE_.. DMA_PRIO_..>, < 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 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 --- 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 = < IMX6Q_CLK_ECSPI5>, < IMX6Q_CLK_ECSPI5>; clock-names = "ipg", "per"; - dmas = < 11 8 1>, < 12 8 2>; + dmas = < 11 7 1>, < 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 = < IMX6QDL_CLK_ECSPI1>, < IMX6QDL_CLK_ECSPI1>; clock-names = "ipg", "per"; - dmas = < 3 8 1>, < 4 8 2>; + dmas = < 3 7 1>, < 4 7 2>; dma-names = "rx", "tx"; status = "disabled"; }; @@ -352,7 +352,7 @@ clocks = < IMX6QDL_CLK_ECSPI2>, < IMX6QDL_CLK_ECSPI2>; clock-names = "ipg", "per"; - dmas = < 5 8 1>, < 6 8 2>; + dmas = < 5 7 1>, < 6 7 2>; dma-names = "rx", "tx"; status = "disabled"; }; @@ -366,7 +366,7 @@ clocks = < IMX6QDL_CLK_ECSPI3>, < IMX6QDL_CLK_ECSPI3>; clock-names = "ipg", "per"; - dmas = < 7 8 1>, < 8 8 2>; + dmas = < 7 7 1>, < 8 7 2>; dma-names = "rx", "tx"; status = "disabled"; }; @@ -380,7 +380,7 @@ clocks
RE: Issues with i.MX SPI DMA transfers
> -Original Message- > From: Igor Plyatov > Sent: 2019年4月2日 20:15 > To: Robin Gong > Cc: Uwe Kleine-König ; > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam > ; Pengutronix Kernel Team ; > Sascha Hauer ; Shawn Guo > ; Mark Brown ; > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams > ; Andy Duan ; Han Xu > ; Clark Wang > 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 120 -b 8 -S 64 -I 1 > >> -l spi mode: 0x20 bits per word: 8 max speed: 120 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 120 -b 8 > > -S 64 -I 1 -l spi mode: 0x20 bits per word: 8 max speed: 120 Hz > > (1200 KHz) root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma > > 48: 43 GPC 2 Level sdma > > ./spidev_test -D /dev/spidev0.0 -s 120 -b 8 -S 512 -I 1 -l spi > > mode: 0x20 bits per word: 8 max speed: 120 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) 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
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 120 -b 8 -S 64 -I 1 -l
spi mode: 0x20
bits per word: 8
max speed: 120 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 120 -b 8 -S 64 -I
1 -l
spi mode: 0x20
bits per word: 8
max speed: 120 Hz (1200 KHz)
root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma
48: 43 GPC 2 Level sdma
./spidev_test -D /dev/spidev0.0 -s 120 -b 8 -S 512 -I 1 -l
spi mode: 0x20
bits per word: 8
max speed: 120 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;
u32shp_addr, per_addr;
enum dma_status status;
- boolcontext_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(>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(>vc.lock, flags);
vchan_dma_desc_free_list(>vc, );
- 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, );
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
RE: Issues with i.MX SPI DMA transfers
> -Original Message- > From: Igor Plyatov > Sent: 2019年4月2日 15:20 > To: Robin Gong ; Uwe Kleine-König > > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam > ; Pengutronix Kernel Team ; > Sascha Hauer ; Shawn Guo > ; Mark Brown ; > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams > ; Andy Duan ; Han Xu > ; Clark Wang > 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 120 -b 8 -S 64 -I 1 -l > spi mode: 0x20 > bits per word: 8 > max speed: 120 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 120 -b 8 -S 64 -I 1 -l spi mode: 0x20 bits per word: 8 max speed: 120 Hz (1200 KHz) root@imx6qpdlsolox:~# cat /proc/interrupts | grep sdma 48: 43 GPC 2 Level sdma ./spidev_test -D /dev/spidev0.0 -s 120 -b 8 -S 512 -I 1 -l spi mode: 0x20 bits per word: 8 max speed: 120 Hz (1200 KHz) total: tx 0.5KB, rx 0.5KB > > Best wishes. > -- > Igor Plyatov
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 120 -b 8 -S 64 -I 1 -l spi mode: 0x20 bits per word: 8 max speed: 120 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? Best wishes. -- Igor Plyatov
RE: Issues with i.MX SPI DMA transfers
> -Original Message- > From: Igor Plyatov > Sent: 2019年3月28日 19:06 > To: Robin Gong ; Uwe Kleine-König > > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam > ; Pengutronix Kernel Team ; > Sascha Hauer ; Shawn Guo > ; Mark Brown ; > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams > ; Andy Duan ; Han Xu > ; Clark Wang > Subject: Re: Issues with i.MX SPI DMA transfers > > Dear Robin, > > I have applied patches > 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch, > 0002-spi-spi-imx-fix-ERR009165.patch and made testing. > > Results are following: > > root@cr7:~# spidev_test -D /dev/spidev0.0 -s 1200 -b 8 -S 512 -I > 100 -l > spi mode: 0x20 > bits per word: 8 > max speed: 1200 Hz (12000 KHz) > [ 133.987798] spi_imx 2008000.spi: I/O Error in DMA TX [ 133.992810] > spidev spi0.0: SPI transfer failed: -110 [ 133.997860] spi_master spi0: > failed > to transfer one message from queue can't send spi message: Connection timed > out Aborted (core dumped) > > root@cr7:~# spidev_test -D /dev/spidev1.0 -s 1200 -b 8 -S 512 -I > 100 -l > spi mode: 0x20 > bits per word: 8 > max speed: 1200 Hz (12000 KHz) > [ 483.530815] spi_imx 200c000.spi: I/O Error in DMA TX [ 483.535825] > spidev spi1.0: SPI transfer failed: -110 [ 483.540873] spi_master spi1: > failed > to transfer one message from queue can't send spi message: Connection timed > out Aborted (core dumped) > > root@cr7:~# spidev_test -D /dev/spidev4.0 -s 1200 -b 8 -S 512 -I > 100 -l > spi mode: 0x20 > bits per word: 8 > max speed: 1200 Hz (12000 KHz) > [ 94.228774] spi_imx 2018000.spi: I/O Error in DMA TX [ 94.233788] > spidev spi4.0: SPI transfer failed: -110 [ 94.238837] spi_master spi4: > failed > to transfer one message from queue can't send spi message: Connection timed > out Aborted (core dumped) > > Best wishes. > > -- > > Igor Plyatov > > > > Hi Igor, Sorry...below another sdma patch(ad0d92d7ba6a) need to be reverted, because spi driver may dynamically change burst length. > > Please have a try with the attached patch, assume you have already > > used the sdma firmware From > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. > > > kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ffirmware%2Flinux-firm > w > > > are.git%2Ftree%2Fimx%2Fsdma%2Fsdma-imx6q.bindata=02%7C01%7C > yibin. > > > gong%40nxp.com%7Cc0da8a1121f5498ae6b808d6b36d5e70%7C686ea1d3bc2 > b4c6fa9 > > > 2cd99c5c301635%7C0%7C1%7C636893679644630034sdata=jgZV1tj3M > hFXj3XN > > N7MBQzqwpEPEoZcq6P5eBqEBUlw%3Dreserved=0 > >> -Original Message- > >> From: Igor Plyatov > >> Sent: 2019年3月28日 15:04 > >> To: Uwe Kleine-König > >> Cc: linux-kernel@vger.kernel.org; > >> linux-arm-ker...@lists.infradead.org; > >> linux-...@vger.kernel.org; dl-linux-imx ; Fabio > >> Estevam ; Pengutronix Kernel Team > >> ; Sascha Hauer ; > Shawn > >> Guo ; Mark Brown ; > >> dmaeng...@vger.kernel.org; Vinod Koul ; Dan > >> Williams ; Andy Duan ; > >> Han Xu ; Robin Gong ; Clark > Wang > >> > >> Subject: Re: Issues with i.MX SPI DMA transfers > >> > >> Dear Uwe, > >> > >> > >>> Hello Igor, > >>> > >>> On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: > >>>> please, help to resolve two issues with SPI DMA transfers at i.MX6Q > >>>> platform. > >>>> > >>>> First issue is > >>>> [ 4465.008003] spi_master spi0: I/O Error in DMA RX > >>>> > >>>> Second issue is duplication for one of received bytes. > >>>> > >>>> Probably, these issues related to each one. > >>> This is probably the same problem I hit some time ago. Check > >>> ERR009165 in the errata. You either need to disable DMA or need a > >>> fixed sdma-Script. > >> disabling of DMA is not an option, because high throughput required > >> for SPI bus to communicate with DSPs. > >> > >> I'm aware of ERR009165, but as I write some minutes earlier to list, > >> spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, > >> while > >> spi4 (alias for ecspi5) fails very fast. > >> > >> Does same SDMA script used for all SPI interfaces or scripts are different? > >> > >> Best wishes. > >> > >> -- > >> > >> Igor Plyatov
Re: Issues with i.MX SPI DMA transfers
Dear Uwe, On Thu, Mar 28, 2019 at 10:04:21AM +0300, Igor Plyatov wrote: Dear Uwe, Hello Igor, On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: please, help to resolve two issues with SPI DMA transfers at i.MX6Q platform. First issue is [ 4465.008003] spi_master spi0: I/O Error in DMA RX Second issue is duplication for one of received bytes. Probably, these issues related to each one. This is probably the same problem I hit some time ago. Check ERR009165 in the errata. You either need to disable DMA or need a fixed sdma-Script. disabling of DMA is not an option, because high throughput required for SPI bus to communicate with DSPs. Is this a theoretical reasoning, or is that backed by testing? People here on the list already said things like: The eCSPI appears to insert a 4 bit pause after each word in DMA mode, not done in PIO mode, which can make DMA transfers 50% slower than PIO. You might want to read the thread https://marc.info/?l=linux-spi=155191201208766=2 . SPI throughput depends from transfer mode (PIO or DMA), OS load and OS version. For example, Linux-4.9.87 has quite bad results for SPI throughput when PIO transfer used and OS highly loaded by other processes. Throughput varies from 2700 kbps to 0.8 kbps and this is totally unacceptable for my application, where streaming of DSP data required. Linux-5.1.0-rc2 has much better performance of SPI with PIO transfers. Throughput varies within 10%. I'm aware of ERR009165, but as I write some minutes earlier to list, spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while spi4 (alias for ecspi5) fails very fast. As the issue is a timing race, it might depend on things like length of the SPI lines, load on the data lines and other electrical properties. So you might just be happy that spi0 and spi1 don't show the issue for you. Or you didn't apply the "right" work load yet. This e-mail thread discuss operation of SPI only in loopback mode. So, real lines of SPI does not used. SPI module of SOC has connected MOSI and MISO lines internally, while MISO disconnected from SOC pad. So, electrical characteristics of SPI lines are not important at all. Best wishes. -- Igor Plyatov
Re: Issues with i.MX SPI DMA transfers
Dear Robin, I have applied patches 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch, 0002-spi-spi-imx-fix-ERR009165.patch and made testing. Results are following: root@cr7:~# spidev_test -D /dev/spidev0.0 -s 1200 -b 8 -S 512 -I 100 -l spi mode: 0x20 bits per word: 8 max speed: 1200 Hz (12000 KHz) [ 133.987798] spi_imx 2008000.spi: I/O Error in DMA TX [ 133.992810] spidev spi0.0: SPI transfer failed: -110 [ 133.997860] spi_master spi0: failed to transfer one message from queue can't send spi message: Connection timed out Aborted (core dumped) root@cr7:~# spidev_test -D /dev/spidev1.0 -s 1200 -b 8 -S 512 -I 100 -l spi mode: 0x20 bits per word: 8 max speed: 1200 Hz (12000 KHz) [ 483.530815] spi_imx 200c000.spi: I/O Error in DMA TX [ 483.535825] spidev spi1.0: SPI transfer failed: -110 [ 483.540873] spi_master spi1: failed to transfer one message from queue can't send spi message: Connection timed out Aborted (core dumped) root@cr7:~# spidev_test -D /dev/spidev4.0 -s 1200 -b 8 -S 512 -I 100 -l spi mode: 0x20 bits per word: 8 max speed: 1200 Hz (12000 KHz) [ 94.228774] spi_imx 2018000.spi: I/O Error in DMA TX [ 94.233788] spidev spi4.0: SPI transfer failed: -110 [ 94.238837] spi_master spi4: failed to transfer one message from queue can't send spi message: Connection timed out Aborted (core dumped) Best wishes. -- Igor Plyatov Hi Igor, Please have a try with the attached patch, assume you have already used the sdma firmware From https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma/sdma-imx6q.bin -Original Message- From: Igor Plyatov Sent: 2019年3月28日 15:04 To: Uwe Kleine-König Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam ; Pengutronix Kernel Team ; Sascha Hauer ; Shawn Guo ; Mark Brown ; dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams ; Andy Duan ; Han Xu ; Robin Gong ; Clark Wang Subject: Re: Issues with i.MX SPI DMA transfers Dear Uwe, Hello Igor, On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: please, help to resolve two issues with SPI DMA transfers at i.MX6Q platform. First issue is [ 4465.008003] spi_master spi0: I/O Error in DMA RX Second issue is duplication for one of received bytes. Probably, these issues related to each one. This is probably the same problem I hit some time ago. Check ERR009165 in the errata. You either need to disable DMA or need a fixed sdma-Script. disabling of DMA is not an option, because high throughput required for SPI bus to communicate with DSPs. I'm aware of ERR009165, but as I write some minutes earlier to list, spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while spi4 (alias for ecspi5) fails very fast. Does same SDMA script used for all SPI interfaces or scripts are different? Best wishes. -- Igor Plyatov
RE: Issues with i.MX SPI DMA transfers
Hi Igor, Please have a try with the attached patch, assume you have already used the sdma firmware From https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma/sdma-imx6q.bin > -Original Message- > From: Igor Plyatov > Sent: 2019年3月28日 15:04 > To: Uwe Kleine-König > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam > ; Pengutronix Kernel Team ; > Sascha Hauer ; Shawn Guo > ; Mark Brown ; > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams > ; Andy Duan ; Han Xu > ; Robin Gong ; Clark Wang > > Subject: Re: Issues with i.MX SPI DMA transfers > > Dear Uwe, > > > > Hello Igor, > > > > On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: > >> please, help to resolve two issues with SPI DMA transfers at i.MX6Q > >> platform. > >> > >> First issue is > >> [ 4465.008003] spi_master spi0: I/O Error in DMA RX > >> > >> Second issue is duplication for one of received bytes. > >> > >> Probably, these issues related to each one. > > This is probably the same problem I hit some time ago. Check ERR009165 > > in the errata. You either need to disable DMA or need a fixed > > sdma-Script. > > disabling of DMA is not an option, because high throughput required for SPI > bus > to communicate with DSPs. > > I'm aware of ERR009165, but as I write some minutes earlier to list, > spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while > spi4 (alias for ecspi5) fails very fast. > > Does same SDMA script used for all SPI interfaces or scripts are different? > > Best wishes. > > -- > > Igor Plyatov 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch Description: 0001-dma-engine-imx-sdma-add-mcu_2_ecspi-script.patch 0002-spi-spi-imx-fix-ERR009165.patch Description: 0002-spi-spi-imx-fix-ERR009165.patch
Re: Issues with i.MX SPI DMA transfers
On Thu, Mar 28, 2019 at 10:04:21AM +0300, Igor Plyatov wrote: > Dear Uwe, > > > > Hello Igor, > > > > On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: > > > please, help to resolve two issues with SPI DMA transfers at i.MX6Q > > > platform. > > > > > > First issue is > > > [ 4465.008003] spi_master spi0: I/O Error in DMA RX > > > > > > Second issue is duplication for one of received bytes. > > > > > > Probably, these issues related to each one. > > This is probably the same problem I hit some time ago. Check ERR009165 > > in the errata. You either need to disable DMA or need a fixed > > sdma-Script. > > disabling of DMA is not an option, because high throughput required for SPI > bus to communicate with DSPs. Is this a theoretical reasoning, or is that backed by testing? People here on the list already said things like: The eCSPI appears to insert a 4 bit pause after each word in DMA mode, not done in PIO mode, which can make DMA transfers 50% slower than PIO. You might want to read the thread https://marc.info/?l=linux-spi=155191201208766=2 . > I'm aware of ERR009165, but as I write some minutes earlier to list, spi0 > (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while spi4 > (alias for ecspi5) fails very fast. As the issue is a timing race, it might depend on things like length of the SPI lines, load on the data lines and other electrical properties. So you might just be happy that spi0 and spi1 don't show the issue for you. Or you didn't apply the "right" work load yet. > Does same SDMA script used for all SPI interfaces or scripts are different? As answered already before: The same script is used for all interfaces. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
RE: Issues with i.MX SPI DMA transfers
> -Original Message- > From: Igor Plyatov > Sent: 2019年3月28日 15:04 > To: Uwe Kleine-König > Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-...@vger.kernel.org; dl-linux-imx ; Fabio Estevam > ; Pengutronix Kernel Team ; > Sascha Hauer ; Shawn Guo > ; Mark Brown ; > dmaeng...@vger.kernel.org; Vinod Koul ; Dan Williams > ; Andy Duan ; Han Xu > ; Robin Gong ; Clark Wang > > Subject: Re: Issues with i.MX SPI DMA transfers > > Dear Uwe, > > > > Hello Igor, > > > > On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: > >> please, help to resolve two issues with SPI DMA transfers at i.MX6Q > >> platform. > >> > >> First issue is > >> [ 4465.008003] spi_master spi0: I/O Error in DMA RX > >> > >> Second issue is duplication for one of received bytes. > >> > >> Probably, these issues related to each one. > > This is probably the same problem I hit some time ago. Check ERR009165 > > in the errata. You either need to disable DMA or need a fixed > > sdma-Script. > > disabling of DMA is not an option, because high throughput required for SPI > bus > to communicate with DSPs. > > I'm aware of ERR009165, but as I write some minutes earlier to list, > spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while > spi4 (alias for ecspi5) fails very fast. > > Does same SDMA script used for all SPI interfaces or scripts are different? No different handle inside sdma script for different ecspi port. Agree Uwe, your duplicate data caught seems like ERR009165. Anyway I'll create ecspi patch for you to try in these days. > > Best wishes. > > -- > > Igor Plyatov
Re: Issues with i.MX SPI DMA transfers
Dear Uwe, Hello Igor, On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: please, help to resolve two issues with SPI DMA transfers at i.MX6Q platform. First issue is [ 4465.008003] spi_master spi0: I/O Error in DMA RX Second issue is duplication for one of received bytes. Probably, these issues related to each one. This is probably the same problem I hit some time ago. Check ERR009165 in the errata. You either need to disable DMA or need a fixed sdma-Script. disabling of DMA is not an option, because high throughput required for SPI bus to communicate with DSPs. I'm aware of ERR009165, but as I write some minutes earlier to list, spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless, while spi4 (alias for ecspi5) fails very fast. Does same SDMA script used for all SPI interfaces or scripts are different? Best wishes. -- Igor Plyatov
Re: Issues with i.MX SPI DMA transfers
Dear developers, I have update about these issues. 12 hours testing show very fast (some seconds) appearance of byte duplication at interface spi4 (alias for ecspi5), while interfaces spi0 (alias for ecspi1) and spi1 (alias for ecspi2) work flawless (at least without any other OS load). Looks like, ecspi5 has some different configuration in SPI or SDMA drivers or bug in SDMA script. Any ideas? Best wishes. -- Igor Plyatov
Re: Issues with i.MX SPI DMA transfers
Hello Igor, On Wed, Mar 27, 2019 at 08:40:00PM +0300, Igor Plyatov wrote: > please, help to resolve two issues with SPI DMA transfers at i.MX6Q > platform. > > First issue is > [ 4465.008003] spi_master spi0: I/O Error in DMA RX > > Second issue is duplication for one of received bytes. > > Probably, these issues related to each one. This is probably the same problem I hit some time ago. Check ERR009165 in the errata. You either need to disable DMA or need a fixed sdma-Script. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
RE: Issues with i.MX SPI DMA transfers
> From: Igor Plyatov [mailto:plya...@gmail.com]
>
> Dear developers,
>
> please, help to resolve two issues with SPI DMA transfers at i.MX6Q platform.
>
> First issue is
> [ 4465.008003] spi_master spi0: I/O Error in DMA RX
>
> Second issue is duplication for one of received bytes.
>
Copy Xu Han, Clark, and Yibin who may help
Regards
Dong Aisheng
> Probably, these issues related to each one.
>
> I think suspicious code is one of files linux/drivers/spi/spi-imx.c,
> linux/drivers/dma/imx-sdma.c, /lib/firmware/imx/sdma/sdma-imx6q.bin.
>
>
> My environment
> --
>
> Linux kernel: 5.1.0-rc2 from Linus mainline master branch, where last
> commit is 14c741de93861749dfb60b4964028541f5c506ca from Tue Mar 26
> 14:25:48 2019 -0700.
>
> File "drivers/dma/imx-sdma.c" has been patched by me, because I have
> kernel errors "imx-sdma 20ec000.sdma: Timeout waiting for CH0 ready".
> Where patch was taken from email of Andy Duan with Subject "[PATCH v2
> dmaengine 1/1] dmaengine: imx-sdma: revert: add clock ratio 1:1 check"
> E-mail can be found at
> ...
>
> Issues exists in Linux kernel 4.9 too.
>
> SOM (System On Module) is from Toradex and called "Apalis iMX6 Quad 2GB
> IT V1.1C". It is installed onto custom carrier board. I think, type of
> carrier board is not important, because issue happens even without real
> SPI slaves (with SPI loopback enabled).
> root@cr7:~# cat /proc/cpuinfo
> processor : 0
> model name : ARMv7 Processor rev 10 (v7l)
> BogoMIPS : 6.00
> Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x2
> CPU part : 0xc09
> CPU revision : 10
>
> processor : 1
> model name : ARMv7 Processor rev 10 (v7l)
> BogoMIPS : 6.00
> Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x2
> CPU part : 0xc09
> CPU revision : 10
>
> processor : 2
> model name : ARMv7 Processor rev 10 (v7l)
> BogoMIPS : 6.00
> Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x2
> CPU part : 0xc09
> CPU revision : 10
>
> processor : 3
> model name : ARMv7 Processor rev 10 (v7l)
> BogoMIPS : 6.00
> Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x2
> CPU part : 0xc09
> CPU revision : 10
>
> Hardware : Freescale i.MX6 Quad/DualLite (Device Tree)
> Revision :
> Serial : 05154315
>
> Linux host acts as SPI master, where different /dev/spidevX.Y files used
> for testing.
>
> The tools/spi/spidev_test.c from Linux kernel sources, compiled and used
> to test SPI driver from user-space.
> I use latest spidev_test.c (it does not change from 4.20.17 up to
> 5.1.0-rc2).
>
> My custom Device Tree contains description for spidev devices at 3 SPI
> bus, with 3 Chip Selects each:
> { // SPI C for Option boards.
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_ecspi1>;
> cs-gpios = < 25 GPIO_ACTIVE_HIGH>,
> < 11 GPIO_ACTIVE_HIGH>,
> < 25 GPIO_ACTIVE_HIGH>;
>
> spidev0_0: spidev@0_0 {
> status = "okay";
> compatible = "rohm,dh2228fv";
> reg = <0>;
> spi-max-frequency = <4000>;
> };
> spidev0_1: spidev@0_1 {
> status = "okay";
> compatible = "rohm,dh2228fv";
> reg = <1>;
> spi-max-frequency = <4000>;
> };
> spidev0_2: spidev@0_2 {
> status = "okay";
> compatible = "rohm,dh2228fv";
> reg = <2>;
> spi-max-frequency = <4000>;
> };
> };
> { // SPI A for DSP.
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_ecspi2>;
> cs-gpios = < 26 GPIO_ACTIVE_HIGH>,
> < 27 GPIO_ACTIVE_HIGH>,
> < 24 GPIO_ACTIVE_HIGH>;
>
> spidev1_0: spidev@1_0 {
> status = "okay";
> compatible = "rohm,dh2228fv";
> reg = <0>;
> spi-max-frequency = <4000>;
> };
> spidev1_1: spidev@1_1 {
> status = "okay";
> compatible = "rohm,dh2228fv";
> reg = <1>;
> spi-max-frequency = <4000>;
> };
> spidev1_2: spidev@1_2 {
> status = "okay";
> compatible = "rohm,dh2228fv";
> reg = <2>;
> spi-max-frequency = <4000>;
> };
> };
> { // SPI B for DSP.
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_ecspi5>;
> cs-gpios = < 17 GPIO_ACTIVE_HIGH>,
> < 19 GPIO_ACTIVE_HIGH>,
> < 21 GPIO_ACTIVE_HIGH>;
>
> spidev4_0: spidev@4_0 {
> status = "okay";
> compatible = "rohm,dh2228fv";
> reg = <0>;
> spi-max-frequency = <4000>;
> };
> spidev4_1:
