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
