lkml.org 
[lkml]   [2020]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH v13 00/12] add ecspi ERR009165 for i.mx6/7 soc family
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@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

\
 
 \ /
  Last update: 2020-09-11 18:41    [W:0.103 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site