[PATCH v13 00/12] add ecspi ERR009165 for i.mx6/7 soc family

[Marco Felsch]

On 20-09-01 00:03, Robin Gong wrote:
> There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
> transfer to be send twice in DMA mode. Please get more information from:
> https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. The workaround is adding
> new sdma ram script which works in XCH  mode as PIO inside sdma instead
> of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0. The issue should be
> exist on all legacy i.mx6/7 soc family before i.mx6ul.
> NXP fix this design issue from i.mx6ul, so newer chips including i.mx6ul/
> 6ull/6sll do not need this workaroud anymore. All other i.mx6/7/8 chips
> still need this workaroud. This patch set add new 'fsl,imx6ul-ecspi'
> for ecspi driver and 'ecspi_fixed' in sdma driver to choose if need errata
> or not.
> The first two reverted patches should be the same issue, though, it
> seems 'fixed' by changing to other shp script. Hope Sean or Sascha could
> have the chance to test this patch set if could fix their issues.
> Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not work
> on i.mx8mm because the event id is zero.
> 
> PS:
>    Please get sdma firmware from below linux-firmware and copy it to your
> local rootfs /lib/firmware/imx/sdma.
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma

Hi Robin,

I took your patches and did a few test on the mainline available
fsl,imx6q-sabrelite. I used a vanilla linux version v5.9-rc1 for all my
tests except the needed SPI-NOR patches [1]. Following are my results:

Testcase 1: "Using ROM-FW"
===
[OK] Playing Audio (SSI)
[OK] TX/RX bytes on a different UART (not the serial used for
     interaction)
[OK] Writing to the SPI-NOR
[OK] Doing all at the same time (once for TX and once for RX on UART)

Notes:
- Your Patches adding a maybe noise message "sdma firmware not ready".
  Maybe we should consider about that if it should be a warning or a info.

- For spi-nor I did run this test:
  dd if=/dev/urandom of=/var/tmp/test1M bs=1M count=1 && \
  flashcp -v /var/tmp/test1M /dev/mtd2

  and checked /proc/interrupts:
  25:    2107169          0          0          0       GPC  31 Level	2008000.spi

Testcase 2: "Using new FW from linux-firmware"
===
[OK] Playing Audio (SSI)
[OK] TX/RX bytes on a different UART (not the serial used for
     interaction)
[OK] Writing to the SPI-NOR
[OK] Doing all at the same time (once for TX and once for RX on UART)

Notes:
- For spi-nor I did run this test:
  dd if=/dev/urandom of=/var/tmp/test1M bs=1M count=1 && \
  flashcp -v /var/tmp/test1M /dev/mtd2

  and checked /proc/interrupts:
  25:    2107993          0          0          0       GPC  31 Level	2008000.spi

  I saw no SDMA interrupts during this testcase instead I saw only spi
  controller interrupts.

- According linux-firmware you did a version bump from 3.5 to 4.5 but my
  dmesg shows:
  imx-sdma 20ec000.sdma: loaded firmware 3.5

SPI Benchmark:
===
flash_erase /dev/mtd2 0 0 && \
	dd if=/dev/urandom of=/dev/mtd2 bs=1M count=1

- without firmware (ROM-FW)
  1048576 bytes (1.0 MB, 1.0 MiB) copied, 51.9713 s, 20.2 kB/s

- with firmware
  1048576 bytes (1.0 MB, 1.0 MiB) copied, 59.4174 s, 17.6 kB/s

Conclusion:
===
It seems that we don't have any performance boost with your patchset
instead we are increasing the complexity and the interrupts...

Pls let me know if I did something wrong during testing or if my test
setup was wrong. Note: the /dev/mtd2 isn't mainlined yet but if you use
barebox you only have to add:
8<---------------------------------------------------------------------
diff --git a/arch/arm/dts/imx6qdl-sabrelite.dtsi b/arch/arm/dts/imx6qdl-sabrelite.dtsi
index ec3d364bde..256dd90a0f 100644
--- a/arch/arm/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/dts/imx6qdl-sabrelite.dtsi
@@ -38,6 +38,11 @@
 		label = "barebox-environment";
 		reg = <0xe0000 0x20000>;
 	};
+
+	parition at 100000 {
+		label = "user-partition";
+		reg = <0x100000 0x100000>;
+	};
 };
 
 &ocotp {
8<---------------------------------------------------------------------
to the barebox device tree.

[1] http://lists.infradead.org/pipermail/linux-mtd/2020-September/082099.html 

Regards,
  Marco