Issues with i.MX SPI DMA transfers

Issues with i.MX SPI DMA transfers

[Igor Plyatov]

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.

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 https://marc.info/?l=dmaengine&m=155322581416268&w=2.

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    : 0000
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:
  &ecspi1 { // SPI C for Option boards.
     status = "okay";
     pinctrl-names = "default";
     pinctrl-0 = <&pinctrl_ecspi1>;
     cs-gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>,
            <&gpio4 11 GPIO_ACTIVE_HIGH>,
            <&gpio3 25 GPIO_ACTIVE_HIGH>;

     spidev0_0: spidev@0_0 {
         status = "okay";
         compatible = "rohm,dh2228fv";
         reg = <0>;
         spi-max-frequency = <40000000>;
     };
     spidev0_1: spidev@0_1 {
         status = "okay";
         compatible = "rohm,dh2228fv";
         reg = <1>;
         spi-max-frequency = <40000000>;
     };
     spidev0_2: spidev@0_2 {
         status = "okay";
         compatible = "rohm,dh2228fv";
         reg = <2>;
         spi-max-frequency = <40000000>;
     };
  };
  &ecspi2 { // SPI A for DSP.
     status = "okay";
     pinctrl-names = "default";
     pinctrl-0 = <&pinctrl_ecspi2>;
     cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>,
            <&gpio2 27 GPIO_ACTIVE_HIGH>,
            <&gpio3 24 GPIO_ACTIVE_HIGH>;

     spidev1_0: spidev@1_0 {
         status = "okay";
         compatible = "rohm,dh2228fv";
         reg = <0>;
         spi-max-frequency = <40000000>;
     };
     spidev1_1: spidev@1_1 {
         status = "okay";
         compatible = "rohm,dh2228fv";
         reg = <1>;
         spi-max-frequency = <40000000>;
     };
     spidev1_2: spidev@1_2 {
         status = "okay";
         compatible = "rohm,dh2228fv";
         reg = <2>;
         spi-max-frequency = <40000000>;
     };
  };
  &ecspi5 { // SPI B for DSP.
     status = "okay";
     pinctrl-names = "default";
     pinctrl-0 = <&pinctrl_ecspi5>;
     cs-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>,
            <&gpio1 19 GPIO_ACTIVE_HIGH>,
            <&gpio1 21 GPIO_ACTIVE_HIGH>;

     spidev4_0: spidev@4_0 {
         status = "okay";
         compatible = "rohm,dh2228fv";
         reg = <0>;
         spi-max-frequency = <40000000>;
     };
     spidev4_1: spidev@4_1 {
         status = "okay";
         compatible = "rohm,dh2228fv";
         reg = <1>;
         spi-max-frequency = <40000000>;
     };
     spidev4_2: spidev@4_2 {
         status = "okay";
         compatible = "rohm,dh2228fv";
         reg = <2>;
         spi-max-frequency = <40000000>;
     };
  };

This gives spidev files:
* /dev/spidev0.0;
* /dev/spidev0.1;
* /dev/spidev0.2;
* /dev/spidev1.0;
* /dev/spidev1.1;
* /dev/spidev1.2;
* /dev/spidev4.0;
* /dev/spidev4.1;
* /dev/spidev4.2


Testing method
--------------

insmod /virt-dma.ko
insmod /imx-sdma.ko
insmod /spi-bitbang.ko
insmod /spi-imx.ko
insmod /spidev.ko

Kernel says
  [  310.818010] fsl-ssi-dai 2028000.ssi: No cache defaults, reading 
back from HW
  [  310.830859] imx-sdma 20ec000.sdma: loaded firmware 3.3
  [  310.865237] imx-sgtl5000 sound: sgtl5000 <-> 2028000.ssi mapping ok
  [  310.875560] spi_imx 2008000.spi: probed
  [  310.883855] spi_imx 200c000.spi: probed
  [  310.899010] spi_imx 2018000.spi: probed

Real SPI slave devices unused, because SPI loopback enabled.
SPI mode: 0;
Bits per word: 8;
Transfer size: 512 bytes;
SPI speeds: 100 kHz and 10 MHz;

Test commands are
  spidev_test -D /dev/spidevX.Y -s 10000000 -b 8 -S 512 -I 1000000 -l
where different devices used.


Description of issues
---------------------


Issue #1
========

Sometimes, during test I see error

  root@cr7:~# spidev_test -D /dev/spidev0.1 -s 100000 -b 8 -S 512 -I 1 -v -l
  spi mode: 0x20
  bits per word: 8
  max speed: 100000 Hz (100 KHz)
  [ 4465.008003] spi_master spi0: I/O Error in DMA RX
  [ 4465.012681] spidev spi0.1: SPI transfer failed: -110
  [ 4465.017676] spi_master spi0: failed to transfer one message from queue
  can't send spi message: Connection timed out
  Aborted (core dumped)

Issue is hard to reproduce, because it can arise after unpredictable 
period of time.
Once, issue was catched immediately after start of test.
It is unclear - what can increase repeatability of issue.


Issue #2
========

Periodically, I see distortion of received data. One of received bytes 
is duplicated and it shifts next bytes and throws last byte.
Probability to catch this issue increase if parallel test commands 
executed for different SPI devices.
Also, probability increase with increase of SPI speed.

If testing command execute alone, then issue arise after ~2 minutes.
If 2 testing commands execute in parallel for two /dev/spidev files, 
then issue can arise after some seconds.

Issue looks as following:

  root@cr7:~# spidev_test -D /dev/spidev4.2 -s 10000000 -b 8 -S 512 -I 
1000000 -l
  spi mode: 0x20
  bits per word: 8
  max speed: 10000000 Hz (10000 KHz)
  transfer error !
  TX | 85 5F 56 44 65 DD A9 4B B0 9E D1 B4 EE F8 8C 70 91 DB EB E7 83 D4 
65 5E 46 D4 8E 1E 56 09 38 DC  |._VDe..K.......p......e^F...V.8.|
  TX | 69 8E 20 CE 6B C9 1A 1B 68 EB CF 56 E4 5B C6 75 37 B1 5C BA 85 C1 
18 CB 95 A6 E9 EB B0 22 C7 19  |i. .k...h..V.[.u7.\.........."..|
  TX | B0 E7 E7 1C B1 01 37 19 ED 07 6F D1 62 35 46 99 E6 A2 54 6C 63 6C 
37 F8 13 21 E3 C3 43 AB DC F3  |......7...o.b5F...Tlcl7..!..C...|
  TX | 92 C3 0F 43 C5 47 5C B2 4E CB 83 B0 00 C9 4A E7 6B 9E 53 CE 0A 8A 
C6 1D AB A9 E0 EE 54 BC E2 E7  |...C.G\.N.....J.k.S.........T...|
  TX | 80 F1 2A 45 38 87 F7 86 52 7A 37 53 43 81 3A AE 1F 8D 7C 29 17 42 
47 C3 EB 27 B1 40 E4 93 27 64  |..*E8...Rz7SC.:...|).BG..'.@..'d|
  TX | 85 51 A9 BD D8 A0 44 2B 1A 7B 7E 5D FC B8 0B 1B 45 87 44 5C C9 8B 
1F B4 B3 D1 F4 97 64 1B FB E9  |.Q....D+.{~]....E.D\........d...|
  TX | 6D A4 A7 45 44 EB 70 5E 66 EE BB 62 A6 C6 7D EB 4D C1 48 16 4D 67 
CA 00 38 BF 97 9D DA 92 86 47  |m..ED.p^f..b..}.M.H.Mg..8......G|
  TX | 36 2D 8D 7A 18 FD D8 7E EC 93 E0 92 59 5D 7E A6 1F C6 BC 6C 2D 86 
6C 66 45 03 03 20 95 89 67 CB  |6-.z...~....Y]~....l-.lfE.. ..g.|
  TX | B7 F4 45 CF F2 1D 4E DE B0 2E 70 09 8C EE AF AB B4 6B 17 E2 F1 83 
48 37 86 4B 57 1B D4 BE E6 8B  |..E...N...p......k....H7.KW.....|
  TX | B3 2B 5B A5 48 A9 83 F8 D7 F3 01 63 E2 B0 0E 96 1B 25 78 0C A8 C0 
43 2E 0B 9A 49 E0 59 2F 6B 0C  |.+[.H......c.....%x...C...I.Y/k.|
  TX | 5A C6 B1 A2 6F 34 9A 47 27 9B AA 09 4B B9 A0 66 DE 18 73 87 D9 B6 
B5 E4 51 FF C4 AA 2E 30 B6 89  |Z...o4.G'...K..f..s.....Q....0..|
  TX | F6 67 2B 66 9B C6 AD C2 61 57 CC AD 10 6C 13 EF 84 86 76 5D 3D 2B 
42 8E 2A 06 38 59 36 EE E2 2D  |.g+f....aW...l....v]=+B.*.8Y6..-|
  TX | 55 0D 93 F0 D3 40 B2 35 97 7E E2 A8 EA F5 97 6F 7C 0D CC B9 38 0E 
47 63 15 7F BC 4B 6D 9E 78 C2  |U....@.5.~.....o|...8.Gc...Km.x.|
  TX | AB 0B B2 7F 4B 64 B4 E3 E3 96 8B CD 8B 22 3C 07 2F 09 C0 67 17 07 
CA 2C 86 86 78 F3 24 F0 B5 D0 |....Kd......."<./..g...,..x.$...|
  TX | FC 67 4F 47 CC 03 2A AF 99 B5 7C 24 D7 B9 2C 06 C2 EC 6E D9 F4 38 
06 7A BF 7E 6E E3 6E 23 B3 6A  |.gOG..*...|$..,...n..8.z.~n.n#.j|
  TX | 8B 02 B2 57 05 DC 06 9E 92 82 C3 69 3B EF 70 FD DB DE D7 CF 16 DD 
4A D5 5B B8 B9 C9 DB 6C 34 66  |...W.......i;.p.......J.[....l4f|
  RX | 85 5F 56 44 65 DD A9 4B B0 9E D1 B4 EE F8 8C 70 91 DB EB E7 83 D4 
65 5E 46 D4 8E 1E 56 09 38 DC  |._VDe..K.......p......e^F...V.8.|
  RX | 69 8E 20 CE 6B C9 1A 1B 68 EB CF 56 E4 5B C6 75 37 B1 5C BA 85 C1 
18 CB 95 A6 E9 EB B0 22 C7 19  |i. .k...h..V.[.u7.\.........."..|
  RX | B0 E7 E7 1C B1 B1 01 37 19 ED 07 6F D1 62 35 46 99 E6 A2 54 6C 63 
6C 37 F8 13 21 E3 C3 43 AB DC  |.......7...o.b5F...Tlcl7..!..C..|
  RX | F3 92 C3 0F 43 C5 47 5C B2 4E CB 83 B0 00 C9 4A E7 6B 9E 53 CE 0A 
8A C6 1D AB A9 E0 EE 54 BC E2  |....C.G\.N.....J.k.S.........T..|
  RX | E7 80 F1 2A 45 38 87 F7 86 52 7A 37 53 43 81 3A AE 1F 8D 7C 29 17 
42 47 C3 EB 27 B1 40 E4 93 27  |...*E8...Rz7SC.:...|).BG..'.@..'|
  RX | 64 85 51 A9 BD D8 A0 44 2B 1A 7B 7E 5D FC B8 0B 1B 45 87 44 5C C9 
8B 1F B4 B3 D1 F4 97 64 1B FB  |d.Q....D+.{~]....E.D\........d..|
  RX | E9 6D A4 A7 45 44 EB 70 5E 66 EE BB 62 A6 C6 7D EB 4D C1 48 16 4D 
67 CA 00 38 BF 97 9D DA 92 86  |.m..ED.p^f..b..}.M.H.Mg..8......|
  RX | 47 36 2D 8D 7A 18 FD D8 7E EC 93 E0 92 59 5D 7E A6 1F C6 BC 6C 2D 
86 6C 66 45 03 03 20 95 89 67  |G6-.z...~....Y]~....l-.lfE.. ..g|
  RX | CB B7 F4 45 CF F2 1D 4E DE B0 2E 70 09 8C EE AF AB B4 6B 17 E2 F1 
83 48 37 86 4B 57 1B D4 BE E6  |...E...N...p......k....H7.KW....|
  RX | 8B B3 2B 5B A5 48 A9 83 F8 D7 F3 01 63 E2 B0 0E 96 1B 25 78 0C A8 
C0 43 2E 0B 9A 49 E0 59 2F 6B  |..+[.H......c.....%x...C...I.Y/k|
  RX | 0C 5A C6 B1 A2 6F 34 9A 47 27 9B AA 09 4B B9 A0 66 DE 18 73 87 D9 
B6 B5 E4 51 FF C4 AA 2E 30 B6  |.Z...o4.G'...K..f..s.....Q....0.|
  RX | 89 F6 67 2B 66 9B C6 AD C2 61 57 CC AD 10 6C 13 EF 84 86 76 5D 3D 
2B 42 8E 2A 06 38 59 36 EE E2  |..g+f....aW...l....v]=+B.*.8Y6..|
  RX | 2D 55 0D 93 F0 D3 40 B2 35 97 7E E2 A8 EA F5 97 6F 7C 0D CC B9 38 
0E 47 63 15 7F BC 4B 6D 9E 78  |-U....@.5.~.....o|...8.Gc...Km.x|
  RX | C2 AB 0B B2 7F 4B 64 B4 E3 E3 96 8B CD 8B 22 3C 07 2F 09 C0 67 17 
07 CA 2C 86 86 78 F3 24 F0 B5 |.....Kd......."<./..g...,..x.$..|
  RX | D0 FC 67 4F 47 CC 03 2A AF 99 B5 7C 24 D7 B9 2C 06 C2 EC 6E D9 F4 
38 06 7A BF 7E 6E E3 6E 23 B3  |..gOG..*...|$..,...n..8.z.~n.n#.|
  RX | 6A 8B 02 B2 57 05 DC 06 9E 92 82 C3 69 3B EF 70 FD DB DE D7 CF 16 
DD 4A D5 5B B8 B9 C9 DB 6C 34  |j...W.......i;.p.......J.[....l4|

  root@cr7:~# spidev_test -D /dev/spidev4.2 -s 10000000 -b 8 -S 512 -I 
1000000 -l
  spi mode: 0x20
  bits per word: 8
  max speed: 10000000 Hz (10000 KHz)
  transfer error !
  TX | B1 5F DB DA 56 B7 B3 33 E0 AC F0 51 46 C4 33 57 58 A8 7F 20 21 D4 
11 25 F3 26 27 A0 24 10 7F D5  |._..V..3...QF.3WX.. !..%.&'.$...|
  TX | 6F 5A B0 C5 11 63 F9 F1 10 E9 42 56 AD 76 AD 05 1E 2D 25 3F 01 36 
64 F4 5C 8C 95 80 9C 14 56 0B  |oZ...c....BV.v...-%?.6d.\.....V.|
  TX | 6F 06 D1 80 69 CA 72 79 B3 B4 CF 61 2A 7D 66 48 AA 8C 88 AB C2 EC 
9F 1F 78 34 9F 14 49 F5 20 B8  |o...i.ry...a*}fH........x4..I. .|
  TX | FB F1 38 65 BB AA DE 6E 5F AE CF 89 2B 36 D2 D5 C2 5A 80 84 46 1F 
A3 BF 54 43 D3 9D 38 F3 55 34  |..8e...n_...+6...Z..F...TC..8.U4|
  TX | E4 8D 99 9F 38 77 0E 97 25 DD 20 50 13 F2 25 D5 4C A5 5A 93 C5 FD 
52 19 40 25 B6 79 19 0B AD FD  |....8w..%. P..%.L.Z...R.@%.y....|
  TX | 98 46 9D D0 BD AB 67 E3 88 88 33 9C 7A 59 71 C7 FE CB 5A C3 C9 AC 
DC 09 D1 92 82 EA 9D 2F E8 36  |.F....g...3.zYq...Z........../.6|
  TX | 75 85 06 33 30 6E 16 B8 F6 49 54 70 A2 C6 37 A1 91 91 64 5A 3D 41 
64 0F D3 E6 F9 71 16 E1 A7 8B  |u..30n...ITp..7...dZ=Ad....q....|
  TX | 66 AD BE 96 1B D4 4F 11 1E A3 82 C0 69 B9 61 FB 4B C6 55 88 07 B9 
97 DA A0 91 4B B6 72 F2 41 D9  |f.....O.....i.a.K.U.......K.r.A.|
  TX | A0 00 6F BB D4 BE CD F2 62 4F B3 CB 08 14 C6 53 DA 1C DC E1 D5 73 
BC 75 04 07 2B 77 FA 6D 50 9A  |..o.....bO.....S.....s.u..+w.mP.|
  TX | 6D BF 55 41 7E 22 34 E0 71 E7 AB 7A FB 72 CD D6 8E A9 B7 63 1D 73 
D9 21 7B 04 98 75 71 E8 0F DE  |m.UA~"4.q..z.r.....c.s.!{..uq...|
  TX | A8 64 20 26 87 54 06 F8 3B B1 72 36 23 40 0C B1 E9 C4 15 06 37 EE 
28 B2 F2 C0 27 64 A9 36 42 51  |.d &.T..;.r6#@......7.(...'d.6BQ|
  TX | 9B 62 77 22 B6 7D 1A F1 2E 8D 28 52 CD 34 03 B6 F8 18 BD 30 06 E5 
E2 F9 A5 0A 5D 4E 40 9F 9F DB  |.bw".}....(R.4.....0......]N@...|
  TX | 02 16 FD B8 93 18 AA C2 A5 D2 14 72 06 17 28 FF 30 E5 2F 36 CA 11 
2F 70 1B 8C BE 5C 2C 5E 37 2E  |...........r..(.0./6../p...\,^7.|
  TX | 74 35 E6 08 4D 90 CA F2 62 DE 64 69 F5 8C 68 25 72 97 5C 3C A8 8B 
AC C4 18 6B 20 44 C9 57 72 3D  |t5..M...b.di..h%r.\<.....k D.Wr=|
  TX | 8C 58 45 D9 E9 0F CB 4B ED 2F B4 E3 BC 1C 08 2E B3 64 6A 5C F0 17 
20 08 82 40 4C 4B 97 BE 88 24  |.XE....K./.......dj\.. ..@LK...$|
  TX | 16 CE FD FF DD C9 4B CB F8 FF AE B4 1C B6 E2 CF 1B 4D 2B 0B 64 4B 
13 E6 8B 5F 31 23 1D B9 47 33  |......K..........M+.dK..._1#..G3|
  RX | B1 5F DB DA 56 B7 B3 33 E0 AC F0 51 46 C4 33 57 58 A8 7F 20 21 D4 
11 25 F3 26 27 A0 24 10 7F D5  |._..V..3...QF.3WX.. !..%.&'.$...|
  RX | 6F 5A B0 C5 11 63 63 F9 F1 10 E9 42 56 AD 76 AD 05 1E 2D 25 3F 01 
36 64 F4 5C 8C 95 80 9C 14 56  |oZ...cc....BV.v...-%?.6d.\.....V|
  RX | 0B 6F 06 D1 80 69 CA 72 79 B3 B4 CF 61 2A 7D 66 48 AA 8C 88 AB C2 
EC 9F 1F 78 34 9F 14 49 F5 20  |.o...i.ry...a*}fH........x4..I. |
  RX | B8 FB F1 38 65 BB AA DE 6E 5F AE CF 89 2B 36 D2 D5 C2 5A 80 84 46 
1F A3 BF 54 43 D3 9D 38 F3 55  |...8e...n_...+6...Z..F...TC..8.U|
  RX | 34 E4 8D 99 9F 38 77 0E 97 25 DD 20 50 13 F2 25 D5 4C A5 5A 93 C5 
FD 52 19 40 25 B6 79 19 0B AD  |4....8w..%. P..%.L.Z...R.@%.y...|
  RX | FD 98 46 9D D0 BD AB 67 E3 88 88 33 9C 7A 59 71 C7 FE CB 5A C3 C9 
AC DC 09 D1 92 82 EA 9D 2F E8  |..F....g...3.zYq...Z........../.|
  RX | 36 75 85 06 33 30 6E 16 B8 F6 49 54 70 A2 C6 37 A1 91 91 64 5A 3D 
41 64 0F D3 E6 F9 71 16 E1 A7  |6u..30n...ITp..7...dZ=Ad....q...|
  RX | 8B 66 AD BE 96 1B D4 4F 11 1E A3 82 C0 69 B9 61 FB 4B C6 55 88 07 
B9 97 DA A0 91 4B B6 72 F2 41  |.f.....O.....i.a.K.U.......K.r.A|
  RX | D9 A0 00 6F BB D4 BE CD F2 62 4F B3 CB 08 14 C6 53 DA 1C DC E1 D5 
73 BC 75 04 07 2B 77 FA 6D 50  |...o.....bO.....S.....s.u..+w.mP|
  RX | 9A 6D BF 55 41 7E 22 34 E0 71 E7 AB 7A FB 72 CD D6 8E A9 B7 63 1D 
73 D9 21 7B 04 98 75 71 E8 0F  |.m.UA~"4.q..z.r.....c.s.!{..uq..|
  RX | DE A8 64 20 26 87 54 06 F8 3B B1 72 36 23 40 0C B1 E9 C4 15 06 37 
EE 28 B2 F2 C0 27 64 A9 36 42  |..d &.T..;.r6#@......7.(...'d.6B|
  RX | 51 9B 62 77 22 B6 7D 1A F1 2E 8D 28 52 CD 34 03 B6 F8 18 BD 30 06 
E5 E2 F9 A5 0A 5D 4E 40 9F 9F  |Q.bw".}....(R.4.....0......]N@..|
  RX | DB 02 16 FD B8 93 18 AA C2 A5 D2 14 72 06 17 28 FF 30 E5 2F 36 CA 
11 2F 70 1B 8C BE 5C 2C 5E 37  |............r..(.0./6../p...\,^7|
  RX | 2E 74 35 E6 08 4D 90 CA F2 62 DE 64 69 F5 8C 68 25 72 97 5C 3C A8 
8B AC C4 18 6B 20 44 C9 57 72  |.t5..M...b.di..h%r.\<.....k D.Wr|
  RX | 3D 8C 58 45 D9 E9 0F CB 4B ED 2F B4 E3 BC 1C 08 2E B3 64 6A 5C F0 
17 20 08 82 40 4C 4B 97 BE 88  |=.XE....K./.......dj\.. ..@LK...|
  RX | 24 16 CE FD FF DD C9 4B CB F8 FF AE B4 1C B6 E2 CF 1B 4D 2B 0B 64 
4B 13 E6 8B 5F 31 23 1D B9 47  |$......K..........M+.dK..._1#..G|

Best wishes.
--
Igor Plyatov

RE: Issues with i.MX SPI DMA transfers

[Aisheng Dong]

> From: Igor Plyatov [mailto:plyatov@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    : 0000
> 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:
>   &ecspi1 { // SPI C for Option boards.
>      status = "okay";
>      pinctrl-names = "default";
>      pinctrl-0 = <&pinctrl_ecspi1>;
>      cs-gpios = <&gpio5 25 GPIO_ACTIVE_HIGH>,
>             <&gpio4 11 GPIO_ACTIVE_HIGH>,
>             <&gpio3 25 GPIO_ACTIVE_HIGH>;
> 
>      spidev0_0: spidev@0_0 {
>          status = "okay";
>          compatible = "rohm,dh2228fv";
>          reg = <0>;
>          spi-max-frequency = <40000000>;
>      };
>      spidev0_1: spidev@0_1 {
>          status = "okay";
>          compatible = "rohm,dh2228fv";
>          reg = <1>;
>          spi-max-frequency = <40000000>;
>      };
>      spidev0_2: spidev@0_2 {
>          status = "okay";
>          compatible = "rohm,dh2228fv";
>          reg = <2>;
>          spi-max-frequency = <40000000>;
>      };
>   };
>   &ecspi2 { // SPI A for DSP.
>      status = "okay";
>      pinctrl-names = "default";
>      pinctrl-0 = <&pinctrl_ecspi2>;
>      cs-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>,
>             <&gpio2 27 GPIO_ACTIVE_HIGH>,
>             <&gpio3 24 GPIO_ACTIVE_HIGH>;
> 
>      spidev1_0: spidev@1_0 {
>          status = "okay";
>          compatible = "rohm,dh2228fv";
>          reg = <0>;
>          spi-max-frequency = <40000000>;
>      };
>      spidev1_1: spidev@1_1 {
>          status = "okay";
>          compatible = "rohm,dh2228fv";
>          reg = <1>;
>          spi-max-frequency = <40000000>;
>      };
>      spidev1_2: spidev@1_2 {
>          status = "okay";
>          compatible = "rohm,dh2228fv";
>          reg = <2>;
>          spi-max-frequency = <40000000>;
>      };
>   };
>   &ecspi5 { // SPI B for DSP.
>      status = "okay";
>      pinctrl-names = "default";
>      pinctrl-0 = <&pinctrl_ecspi5>;
>      cs-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>,
>             <&gpio1 19 GPIO_ACTIVE_HIGH>,
>             <&gpio1 21 GPIO_ACTIVE_HIGH>;
> 
>      spidev4_0: spidev@4_0 {
>          status = "okay";
>          compatible = "rohm,dh2228fv";
>          reg = <0>;
>          spi-max-frequency = <40000000>;
>      };
>      spidev4_1: spidev@4_1 {
>          status = "okay";
>          compatible = "rohm,dh2228fv";
>          reg = <1>;
>          spi-max-frequency = <40000000>;
>      };
>      spidev4_2: spidev@4_2 {
>          status = "okay";
>          compatible = "rohm,dh2228fv";
>          reg = <2>;
>          spi-max-frequency = <40000000>;
>      };
>   };
> 
> This gives spidev files:
> * /dev/spidev0.0;
> * /dev/spidev0.1;
> * /dev/spidev0.2;
> * /dev/spidev1.0;
> * /dev/spidev1.1;
> * /dev/spidev1.2;
> * /dev/spidev4.0;
> * /dev/spidev4.1;
> * /dev/spidev4.2
> 
> 
> Testing method
> --------------
> 
> insmod /virt-dma.ko
> insmod /imx-sdma.ko
> insmod /spi-bitbang.ko
> insmod /spi-imx.ko
> insmod /spidev.ko
> 
> Kernel says
>   [  310.818010] fsl-ssi-dai 2028000.ssi: No cache defaults, reading
> back from HW
>   [  310.830859] imx-sdma 20ec000.sdma: loaded firmware 3.3
>   [  310.865237] imx-sgtl5000 sound: sgtl5000 <-> 2028000.ssi mapping ok
>   [  310.875560] spi_imx 2008000.spi: probed
>   [  310.883855] spi_imx 200c000.spi: probed
>   [  310.899010] spi_imx 2018000.spi: probed
> 
> Real SPI slave devices unused, because SPI loopback enabled.
> SPI mode: 0;
> Bits per word: 8;
> Transfer size: 512 bytes;
> SPI speeds: 100 kHz and 10 MHz;
> 
> Test commands are
>   spidev_test -D /dev/spidevX.Y -s 10000000 -b 8 -S 512 -I 1000000 -l
> where different devices used.
> 
> 
> Description of issues
> ---------------------
> 
> 
> Issue #1
> ========
> 
> Sometimes, during test I see error
> 
>   root@cr7:~# spidev_test -D /dev/spidev0.1 -s 100000 -b 8 -S 512 -I 1 -v -l
>   spi mode: 0x20
>   bits per word: 8
>   max speed: 100000 Hz (100 KHz)
>   [ 4465.008003] spi_master spi0: I/O Error in DMA RX
>   [ 4465.012681] spidev spi0.1: SPI transfer failed: -110
>   [ 4465.017676] spi_master spi0: failed to transfer one message from queue
>   can't send spi message: Connection timed out
>   Aborted (core dumped)
> 
> Issue is hard to reproduce, because it can arise after unpredictable
> period of time.
> Once, issue was catched immediately after start of test.
> It is unclear - what can increase repeatability of issue.
> 
> 
> Issue #2
> ========
> 
> Periodically, I see distortion of received data. One of received bytes
> is duplicated and it shifts next bytes and throws last byte.
> Probability to catch this issue increase if parallel test commands
> executed for different SPI devices.
> Also, probability increase with increase of SPI speed.
> 
> If testing command execute alone, then issue arise after ~2 minutes.
> If 2 testing commands execute in parallel for two /dev/spidev files,
> then issue can arise after some seconds.
> 
> Issue looks as following:
> 
>   root@cr7:~# spidev_test -D /dev/spidev4.2 -s 10000000 -b 8 -S 512 -I
> 1000000 -l
>   spi mode: 0x20
>   bits per word: 8
>   max speed: 10000000 Hz (10000 KHz)
>   transfer error !
>   TX | 85 5F 56 44 65 DD A9 4B B0 9E D1 B4 EE F8 8C 70 91 DB EB E7 83 D4
> 65 5E 46 D4 8E 1E 56 09 38 DC  |._VDe..K.......p......e^F...V.8.|
>   TX | 69 8E 20 CE 6B C9 1A 1B 68 EB CF 56 E4 5B C6 75 37 B1 5C BA 85 C1
> 18 CB 95 A6 E9 EB B0 22 C7 19  |i. .k...h..V.[.u7.\.........."..|
>   TX | B0 E7 E7 1C B1 01 37 19 ED 07 6F D1 62 35 46 99 E6 A2 54 6C 63 6C
> 37 F8 13 21 E3 C3 43 AB DC F3  |......7...o.b5F...Tlcl7..!..C...|
>   TX | 92 C3 0F 43 C5 47 5C B2 4E CB 83 B0 00 C9 4A E7 6B 9E 53 CE 0A 8A
> C6 1D AB A9 E0 EE 54 BC E2 E7  |...C.G\.N.....J.k.S.........T...|
>   TX | 80 F1 2A 45 38 87 F7 86 52 7A 37 53 43 81 3A AE 1F 8D 7C 29 17 42
> 47 C3 EB 27 B1 40 E4 93 27 64  |..*E8...Rz7SC.:...|).BG..'.@..'d|
>   TX | 85 51 A9 BD D8 A0 44 2B 1A 7B 7E 5D FC B8 0B 1B 45 87 44 5C C9 8B
> 1F B4 B3 D1 F4 97 64 1B FB E9  |.Q....D+.{~]....E.D\........d...|
>   TX | 6D A4 A7 45 44 EB 70 5E 66 EE BB 62 A6 C6 7D EB 4D C1 48 16 4D 67
> CA 00 38 BF 97 9D DA 92 86 47  |m..ED.p^f..b..}.M.H.Mg..8......G|
>   TX | 36 2D 8D 7A 18 FD D8 7E EC 93 E0 92 59 5D 7E A6 1F C6 BC 6C 2D 86
> 6C 66 45 03 03 20 95 89 67 CB  |6-.z...~....Y]~....l-.lfE.. ..g.|
>   TX | B7 F4 45 CF F2 1D 4E DE B0 2E 70 09 8C EE AF AB B4 6B 17 E2 F1 83
> 48 37 86 4B 57 1B D4 BE E6 8B  |..E...N...p......k....H7.KW.....|
>   TX | B3 2B 5B A5 48 A9 83 F8 D7 F3 01 63 E2 B0 0E 96 1B 25 78 0C A8 C0
> 43 2E 0B 9A 49 E0 59 2F 6B 0C  |.+[.H......c.....%x...C...I.Y/k.|
>   TX | 5A C6 B1 A2 6F 34 9A 47 27 9B AA 09 4B B9 A0 66 DE 18 73 87 D9 B6
> B5 E4 51 FF C4 AA 2E 30 B6 89  |Z...o4.G'...K..f..s.....Q....0..|
>   TX | F6 67 2B 66 9B C6 AD C2 61 57 CC AD 10 6C 13 EF 84 86 76 5D 3D 2B
> 42 8E 2A 06 38 59 36 EE E2 2D  |.g+f....aW...l....v]=+B.*.8Y6..-|
>   TX | 55 0D 93 F0 D3 40 B2 35 97 7E E2 A8 EA F5 97 6F 7C 0D CC B9 38 0E
> 47 63 15 7F BC 4B 6D 9E 78 C2  |U....@.5.~.....o|...8.Gc...Km.x.|
>   TX | AB 0B B2 7F 4B 64 B4 E3 E3 96 8B CD 8B 22 3C 07 2F 09 C0 67 17 07
> CA 2C 86 86 78 F3 24 F0 B5 D0 |....Kd......."<./..g...,..x.$...|
>   TX | FC 67 4F 47 CC 03 2A AF 99 B5 7C 24 D7 B9 2C 06 C2 EC 6E D9 F4 38
> 06 7A BF 7E 6E E3 6E 23 B3 6A  |.gOG..*...|$..,...n..8.z.~n.n#.j|
>   TX | 8B 02 B2 57 05 DC 06 9E 92 82 C3 69 3B EF 70 FD DB DE D7 CF 16 DD
> 4A D5 5B B8 B9 C9 DB 6C 34 66  |...W.......i;.p.......J.[....l4f|
>   RX | 85 5F 56 44 65 DD A9 4B B0 9E D1 B4 EE F8 8C 70 91 DB EB E7 83 D4
> 65 5E 46 D4 8E 1E 56 09 38 DC  |._VDe..K.......p......e^F...V.8.|
>   RX | 69 8E 20 CE 6B C9 1A 1B 68 EB CF 56 E4 5B C6 75 37 B1 5C BA 85 C1
> 18 CB 95 A6 E9 EB B0 22 C7 19  |i. .k...h..V.[.u7.\.........."..|
>   RX | B0 E7 E7 1C B1 B1 01 37 19 ED 07 6F D1 62 35 46 99 E6 A2 54 6C 63
> 6C 37 F8 13 21 E3 C3 43 AB DC  |.......7...o.b5F...Tlcl7..!..C..|
>   RX | F3 92 C3 0F 43 C5 47 5C B2 4E CB 83 B0 00 C9 4A E7 6B 9E 53 CE 0A
> 8A C6 1D AB A9 E0 EE 54 BC E2  |....C.G\.N.....J.k.S.........T..|
>   RX | E7 80 F1 2A 45 38 87 F7 86 52 7A 37 53 43 81 3A AE 1F 8D 7C 29 17
> 42 47 C3 EB 27 B1 40 E4 93 27  |...*E8...Rz7SC.:...|).BG..'.@..'|
>   RX | 64 85 51 A9 BD D8 A0 44 2B 1A 7B 7E 5D FC B8 0B 1B 45 87 44 5C C9
> 8B 1F B4 B3 D1 F4 97 64 1B FB  |d.Q....D+.{~]....E.D\........d..|
>   RX | E9 6D A4 A7 45 44 EB 70 5E 66 EE BB 62 A6 C6 7D EB 4D C1 48 16 4D
> 67 CA 00 38 BF 97 9D DA 92 86  |.m..ED.p^f..b..}.M.H.Mg..8......|
>   RX | 47 36 2D 8D 7A 18 FD D8 7E EC 93 E0 92 59 5D 7E A6 1F C6 BC 6C 2D
> 86 6C 66 45 03 03 20 95 89 67  |G6-.z...~....Y]~....l-.lfE.. ..g|
>   RX | CB B7 F4 45 CF F2 1D 4E DE B0 2E 70 09 8C EE AF AB B4 6B 17 E2 F1
> 83 48 37 86 4B 57 1B D4 BE E6  |...E...N...p......k....H7.KW....|
>   RX | 8B B3 2B 5B A5 48 A9 83 F8 D7 F3 01 63 E2 B0 0E 96 1B 25 78 0C A8
> C0 43 2E 0B 9A 49 E0 59 2F 6B  |..+[.H......c.....%x...C...I.Y/k|
>   RX | 0C 5A C6 B1 A2 6F 34 9A 47 27 9B AA 09 4B B9 A0 66 DE 18 73 87 D9
> B6 B5 E4 51 FF C4 AA 2E 30 B6  |.Z...o4.G'...K..f..s.....Q....0.|
>   RX | 89 F6 67 2B 66 9B C6 AD C2 61 57 CC AD 10 6C 13 EF 84 86 76 5D 3D
> 2B 42 8E 2A 06 38 59 36 EE E2  |..g+f....aW...l....v]=+B.*.8Y6..|
>   RX | 2D 55 0D 93 F0 D3 40 B2 35 97 7E E2 A8 EA F5 97 6F 7C 0D CC B9 38
> 0E 47 63 15 7F BC 4B 6D 9E 78  |-U....@.5.~.....o|...8.Gc...Km.x|
>   RX | C2 AB 0B B2 7F 4B 64 B4 E3 E3 96 8B CD 8B 22 3C 07 2F 09 C0 67 17
> 07 CA 2C 86 86 78 F3 24 F0 B5 |.....Kd......."<./..g...,..x.$..|
>   RX | D0 FC 67 4F 47 CC 03 2A AF 99 B5 7C 24 D7 B9 2C 06 C2 EC 6E D9 F4
> 38 06 7A BF 7E 6E E3 6E 23 B3  |..gOG..*...|$..,...n..8.z.~n.n#.|
>   RX | 6A 8B 02 B2 57 05 DC 06 9E 92 82 C3 69 3B EF 70 FD DB DE D7 CF 16
> DD 4A D5 5B B8 B9 C9 DB 6C 34  |j...W.......i;.p.......J.[....l4|
> 
>   root@cr7:~# spidev_test -D /dev/spidev4.2 -s 10000000 -b 8 -S 512 -I
> 1000000 -l
>   spi mode: 0x20
>   bits per word: 8
>   max speed: 10000000 Hz (10000 KHz)
>   transfer error !
>   TX | B1 5F DB DA 56 B7 B3 33 E0 AC F0 51 46 C4 33 57 58 A8 7F 20 21 D4
> 11 25 F3 26 27 A0 24 10 7F D5  |._..V..3...QF.3WX.. !..%.&'.$...|
>   TX | 6F 5A B0 C5 11 63 F9 F1 10 E9 42 56 AD 76 AD 05 1E 2D 25 3F 01 36
> 64 F4 5C 8C 95 80 9C 14 56 0B  |oZ...c....BV.v...-%?.6d.\.....V.|
>   TX | 6F 06 D1 80 69 CA 72 79 B3 B4 CF 61 2A 7D 66 48 AA 8C 88 AB C2 EC
> 9F 1F 78 34 9F 14 49 F5 20 B8  |o...i.ry...a*}fH........x4..I. .|
>   TX | FB F1 38 65 BB AA DE 6E 5F AE CF 89 2B 36 D2 D5 C2 5A 80 84 46 1F
> A3 BF 54 43 D3 9D 38 F3 55 34  |..8e...n_...+6...Z..F...TC..8.U4|
>   TX | E4 8D 99 9F 38 77 0E 97 25 DD 20 50 13 F2 25 D5 4C A5 5A 93 C5 FD
> 52 19 40 25 B6 79 19 0B AD FD  |....8w..%. P..%.L.Z...R.@%.y....|
>   TX | 98 46 9D D0 BD AB 67 E3 88 88 33 9C 7A 59 71 C7 FE CB 5A C3 C9 AC
> DC 09 D1 92 82 EA 9D 2F E8 36  |.F....g...3.zYq...Z........../.6|
>   TX | 75 85 06 33 30 6E 16 B8 F6 49 54 70 A2 C6 37 A1 91 91 64 5A 3D 41
> 64 0F D3 E6 F9 71 16 E1 A7 8B  |u..30n...ITp..7...dZ=Ad....q....|
>   TX | 66 AD BE 96 1B D4 4F 11 1E A3 82 C0 69 B9 61 FB 4B C6 55 88 07 B9
> 97 DA A0 91 4B B6 72 F2 41 D9  |f.....O.....i.a.K.U.......K.r.A.|
>   TX | A0 00 6F BB D4 BE CD F2 62 4F B3 CB 08 14 C6 53 DA 1C DC E1 D5 73
> BC 75 04 07 2B 77 FA 6D 50 9A  |..o.....bO.....S.....s.u..+w.mP.|
>   TX | 6D BF 55 41 7E 22 34 E0 71 E7 AB 7A FB 72 CD D6 8E A9 B7 63 1D 73
> D9 21 7B 04 98 75 71 E8 0F DE  |m.UA~"4.q..z.r.....c.s.!{..uq...|
>   TX | A8 64 20 26 87 54 06 F8 3B B1 72 36 23 40 0C B1 E9 C4 15 06 37 EE
> 28 B2 F2 C0 27 64 A9 36 42 51  |.d &.T..;.r6#@......7.(...'d.6BQ|
>   TX | 9B 62 77 22 B6 7D 1A F1 2E 8D 28 52 CD 34 03 B6 F8 18 BD 30 06 E5
> E2 F9 A5 0A 5D 4E 40 9F 9F DB  |.bw".}....(R.4.....0......]N@...|
>   TX | 02 16 FD B8 93 18 AA C2 A5 D2 14 72 06 17 28 FF 30 E5 2F 36 CA 11
> 2F 70 1B 8C BE 5C 2C 5E 37 2E  |...........r..(.0./6../p...\,^7.|
>   TX | 74 35 E6 08 4D 90 CA F2 62 DE 64 69 F5 8C 68 25 72 97 5C 3C A8 8B
> AC C4 18 6B 20 44 C9 57 72 3D  |t5..M...b.di..h%r.\<.....k D.Wr=|
>   TX | 8C 58 45 D9 E9 0F CB 4B ED 2F B4 E3 BC 1C 08 2E B3 64 6A 5C F0 17
> 20 08 82 40 4C 4B 97 BE 88 24  |.XE....K./.......dj\.. ..@LK...$|
>   TX | 16 CE FD FF DD C9 4B CB F8 FF AE B4 1C B6 E2 CF 1B 4D 2B 0B 64 4B
> 13 E6 8B 5F 31 23 1D B9 47 33  |......K..........M+.dK..._1#..G3|
>   RX | B1 5F DB DA 56 B7 B3 33 E0 AC F0 51 46 C4 33 57 58 A8 7F 20 21 D4
> 11 25 F3 26 27 A0 24 10 7F D5  |._..V..3...QF.3WX.. !..%.&'.$...|
>   RX | 6F 5A B0 C5 11 63 63 F9 F1 10 E9 42 56 AD 76 AD 05 1E 2D 25 3F 01
> 36 64 F4 5C 8C 95 80 9C 14 56  |oZ...cc....BV.v...-%?.6d.\.....V|
>   RX | 0B 6F 06 D1 80 69 CA 72 79 B3 B4 CF 61 2A 7D 66 48 AA 8C 88 AB C2
> EC 9F 1F 78 34 9F 14 49 F5 20  |.o...i.ry...a*}fH........x4..I. |
>   RX | B8 FB F1 38 65 BB AA DE 6E 5F AE CF 89 2B 36 D2 D5 C2 5A 80 84 46
> 1F A3 BF 54 43 D3 9D 38 F3 55  |...8e...n_...+6...Z..F...TC..8.U|
>   RX | 34 E4 8D 99 9F 38 77 0E 97 25 DD 20 50 13 F2 25 D5 4C A5 5A 93 C5
> FD 52 19 40 25 B6 79 19 0B AD  |4....8w..%. P..%.L.Z...R.@%.y...|
>   RX | FD 98 46 9D D0 BD AB 67 E3 88 88 33 9C 7A 59 71 C7 FE CB 5A C3 C9
> AC DC 09 D1 92 82 EA 9D 2F E8  |..F....g...3.zYq...Z........../.|
>   RX | 36 75 85 06 33 30 6E 16 B8 F6 49 54 70 A2 C6 37 A1 91 91 64 5A 3D
> 41 64 0F D3 E6 F9 71 16 E1 A7  |6u..30n...ITp..7...dZ=Ad....q...|
>   RX | 8B 66 AD BE 96 1B D4 4F 11 1E A3 82 C0 69 B9 61 FB 4B C6 55 88 07
> B9 97 DA A0 91 4B B6 72 F2 41  |.f.....O.....i.a.K.U.......K.r.A|
>   RX | D9 A0 00 6F BB D4 BE CD F2 62 4F B3 CB 08 14 C6 53 DA 1C DC E1 D5
> 73 BC 75 04 07 2B 77 FA 6D 50  |...o.....bO.....S.....s.u..+w.mP|
>   RX | 9A 6D BF 55 41 7E 22 34 E0 71 E7 AB 7A FB 72 CD D6 8E A9 B7 63 1D
> 73 D9 21 7B 04 98 75 71 E8 0F  |.m.UA~"4.q..z.r.....c.s.!{..uq..|
>   RX | DE A8 64 20 26 87 54 06 F8 3B B1 72 36 23 40 0C B1 E9 C4 15 06 37
> EE 28 B2 F2 C0 27 64 A9 36 42  |..d &.T..;.r6#@......7.(...'d.6B|
>   RX | 51 9B 62 77 22 B6 7D 1A F1 2E 8D 28 52 CD 34 03 B6 F8 18 BD 30 06
> E5 E2 F9 A5 0A 5D 4E 40 9F 9F  |Q.bw".}....(R.4.....0......]N@..|
>   RX | DB 02 16 FD B8 93 18 AA C2 A5 D2 14 72 06 17 28 FF 30 E5 2F 36 CA
> 11 2F 70 1B 8C BE 5C 2C 5E 37  |............r..(.0./6../p...\,^7|
>   RX | 2E 74 35 E6 08 4D 90 CA F2 62 DE 64 69 F5 8C 68 25 72 97 5C 3C A8
> 8B AC C4 18 6B 20 44 C9 57 72  |.t5..M...b.di..h%r.\<.....k D.Wr|
>   RX | 3D 8C 58 45 D9 E9 0F CB 4B ED 2F B4 E3 BC 1C 08 2E B3 64 6A 5C F0
> 17 20 08 82 40 4C 4B 97 BE 88  |=.XE....K./.......dj\.. ..@LK...|
>   RX | 24 16 CE FD FF DD C9 4B CB F8 FF AE B4 1C B6 E2 CF 1B 4D 2B 0B 64
> 4B 13 E6 8B 5F 31 23 1D B9 47  |$......K..........M+.dK..._1#..G|
> 
> Best wishes.
> --
> Igor Plyatov

Re: Issues with i.MX SPI DMA transfers

[Uwe Kleine-König]

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

[Igor Plyatov]

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

[Igor Plyatov]

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

[Robin Gong]

> -----Original Message-----
> From: Igor Plyatov <plyatov@gmail.com>
> Sent: 2019年3月28日 15:04
> To: 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>; Robin Gong <yibin.gong@nxp.com>; Clark Wang
> <xiaoning.wang@nxp.com>
> 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

[Uwe Kleine-König]

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&m=155191201208766&w=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

[Robin Gong]

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

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 <plyatov@gmail.com>
> Sent: 2019年3月28日 15:04
> To: 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>; Robin Gong <yibin.gong@nxp.com>; Clark Wang
> <xiaoning.wang@nxp.com>
> 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


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

From cedd7aece6a3566f61e39cbee9ceeaea3f34cfd1 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 1/2] 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 7fae4bf..1f1ce7c 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -908,6 +908,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: 0002-spi-spi-imx-fix-ERR009165.patch --]
[-- Type: application/octet-stream, Size: 1280 bytes --]

From d3fa24b37adcfb385a6e60b414d7485a52951aca 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 2/2] 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 | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 09c9a1e..2757815 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: */
-- 
2.7.4

Re: Issues with i.MX SPI DMA transfers

[Igor Plyatov]

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 12000000 -b 8 -S 512 -I 
10000000000 -l
spi mode: 0x20
bits per word: 8
max speed: 12000000 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 12000000 -b 8 -S 512 -I 
10000000000 -l
spi mode: 0x20
bits per word: 8
max speed: 12000000 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 12000000 -b 8 -S 512 -I 
10000000000 -l
spi mode: 0x20
bits per word: 8
max speed: 12000000 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 <plyatov@gmail.com>
>> Sent: 2019年3月28日 15:04
>> To: 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>; Robin Gong <yibin.gong@nxp.com>; Clark Wang
>> <xiaoning.wang@nxp.com>
>> 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

[Igor Plyatov]

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&m=155191201208766&w=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

[Robin Gong]

> -----Original Message-----
> From: Igor Plyatov <plyatov@gmail.com>
> Sent: 2019年3月28日 19:06
> 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,
> 
> 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 12000000 -b 8 -S 512 -I
> 10000000000 -l
> spi mode: 0x20
> bits per word: 8
> max speed: 12000000 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 12000000 -b 8 -S 512 -I
> 10000000000 -l
> spi mode: 0x20
> bits per word: 8
> max speed: 12000000 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 12000000 -b 8 -S 512 -I
> 10000000000 -l
> spi mode: 0x20
> bits per word: 8
> max speed: 12000000 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.bin&amp;data=02%7C01%7C
> yibin.
> >
> gong%40nxp.com%7Cc0da8a1121f5498ae6b808d6b36d5e70%7C686ea1d3bc2
> b4c6fa9
> >
> 2cd99c5c301635%7C0%7C1%7C636893679644630034&amp;sdata=jgZV1tj3M
> hFXj3XN
> > N7MBQzqwpEPEoZcq6P5eBqEBUlw%3D&amp;reserved=0
> >> -----Original Message-----
> >> From: Igor Plyatov <plyatov@gmail.com>
> >> Sent: 2019年3月28日 15:04
> >> To: 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>; Robin Gong <yibin.gong@nxp.com>; Clark
> Wang
> >> <xiaoning.wang@nxp.com>
> >> 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

[Igor Plyatov]

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?

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月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

Re: Issues with i.MX SPI DMA transfers

[Igor Plyatov]

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

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


[-- Attachment #2: spi-and-sdma-drivers.diff --]
[-- Type: text/x-patch, Size: 2768 bytes --]

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 */
 };
 

RE: 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

Re: Issues with i.MX SPI DMA transfers

[Igor Plyatov]

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

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

[-- Attachment #2: 0001-Bugfix-for-incorrect-eCSPI-SDMA-numbers.patch --]
[-- Type: text/x-patch, Size: 2483 bytes --]

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

Re: 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

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.
> > > 

Re: Issues with i.MX SPI DMA transfers

[Marc Gonzalez]

[ 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 = <&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"?

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