Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Robin Gong <yibin.gong@nxp.com>
To:     Marco Felsch <m.felsch@pengutronix.de>
CC:     "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "broonie@kernel.org" <broonie@kernel.org>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "catalin.marinas@arm.com" <catalin.marinas@arm.com>,
        "vkoul@kernel.org" <vkoul@kernel.org>,
        "will.deacon@arm.com" <will.deacon@arm.com>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>,
        "festevam@gmail.com" <festevam@gmail.com>,
        "s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
        "martin.fuzzey@flowbird.group" <martin.fuzzey@flowbird.group>,
        "u.kleine-koenig@pengutronix.de" <u.kleine-koenig@pengutronix.de>,
        "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
        "matthias.schiffer@ew.tq-group.com" 
        <matthias.schiffer@ew.tq-group.com>,
        "frieder.schrempf@kontron.de" <frieder.schrempf@kontron.de>,
        "r.schwebel@pengutronix.de" <r.schwebel@pengutronix.de>,
        "Benjamin.Bara@skidata.com" <Benjamin.Bara@skidata.com>,
        "Richard.Leitner@skidata.com" <Richard.Leitner@skidata.com>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
        dl-linux-imx <linux-imx@nxp.com>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>,
        "dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH v13 00/12] add ecspi ERR009165 for i.mx6/7 soc family
Thread-Topic: [PATCH v13 00/12] add ecspi ERR009165 for i.mx6/7 soc family
Thread-Index: AQHWf2tkimfqSdG8kEGKEyob2MpDZaljtaAAgA8dHUA=
Date:   Mon, 21 Sep 2020 08:25:16 +0000
Message-ID: <VE1PR04MB66387B8FEBBC937CE0A1AC24893A0@VE1PR04MB6638.eurprd04.prod.outlook.com>
References: <1598889805-30399-1-git-send-email-yibin.gong@nxp.com>
 <20200911164018.6treqdmywzjhqe3a@pengutronix.de>
In-Reply-To: <20200911164018.6treqdmywzjhqe3a@pengutronix.de>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cba8acb2-8acd-45f3-82fb-08d85e07df91
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 08:25:16.5621
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yrooecPYo5u8wfdUnZ9g/kH4VAByXTj1mqqwA/yyWEEjmO2xxTweKcnQxfTeG25goXhUz+HEvKDQiwF6GZ4vWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB6944
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2020/09/12 0:40 Marco Felsch <m.felsch@pengutronix.de> wrote:
> Hi Robin,
>=20
> 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 t=
ests except
> the needed SPI-NOR patches [1]. Following are my results:
Marco, thanks for your test :)

>=20
> Testcase 1: "Using ROM-FW"
> =3D=3D=3D
> [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)
>=20
> 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=
.
That means the script you're using is ram script which may not be loaded as=
 your
case. That should be a warning I think, to avoid too much noise I have refi=
ne it
to dev_warn_once.

>=20
> - For spi-nor I did run this test:
>   dd if=3D/dev/urandom of=3D/var/tmp/test1M bs=3D1M count=3D1 && \
>   flashcp -v /var/tmp/test1M /dev/mtd2
>=20
>   and checked /proc/interrupts:
>   25:    2107169          0          0          0       GPC  31
> Level	2008000.spi
>=20
> Testcase 2: "Using new FW from linux-firmware"
> =3D=3D=3D
> [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)
>=20
> Notes:
> - For spi-nor I did run this test:
>   dd if=3D/dev/urandom of=3D/var/tmp/test1M bs=3D1M count=3D1 && \
>   flashcp -v /var/tmp/test1M /dev/mtd2
>=20
>   and checked /proc/interrupts:
>   25:    2107993          0          0          0       GPC  31
> Level	2008000.spi
>=20
>   I saw no SDMA interrupts during this testcase instead I saw only spi
>   controller interrupts.
That's not expected. But I have tried just now and show that SDMA interrupt
caught by spi as belows. Are you sure sdma firmware loaded indeed?

./spidev_test -D /dev/spidev0.0 -s 1200000 -b 8 -S 512 -I 1 -l 8 -S 512 -I
spi mode: 0x24
bits per word: 8
max speed: 1200000 Hz (1200 kHz)
total: tx 0.5KB, rx 0.5KB
root@imx6qpdlsolox:~# cat /proc/interrupts | grep dma
 58:          2          0       GPC   2 Level     sdma=20


>=20
> - 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
3.x is used for i.mx6 family while 4.x is used for i.mx7/8 since there are =
some
change on ROM which depended by RAM script. Not means version bump
between 3.5/4.5. 3.5 is correct on i.mx6q.=20

>=20
> SPI Benchmark:
> =3D=3D=3D
> flash_erase /dev/mtd2 0 0 && \
> 	dd if=3D/dev/urandom of=3D/dev/mtd2 bs=3D1M count=3D1
>=20
> - without firmware (ROM-FW)
>   1048576 bytes (1.0 MB, 1.0 MiB) copied, 51.9713 s, 20.2 kB/s
>=20
> - with firmware
>   1048576 bytes (1.0 MB, 1.0 MiB) copied, 59.4174 s, 17.6 kB/s
>=20
> Conclusion:
> =3D=3D=3D
> It seems that we don't have any performance boost with your patchset inst=
ead
> we are increasing the complexity and the interrupts...
Yes, that's expected. What ERR009165 fix is data correct on spi bus though
that bring performance drop in dma mode, because the workaround just let
sdma do similar thing as cpu (PIO), while cpu running faster than sdma. If =
you
care much spi performance, PIO is better way. If care cpu loading, dma way
is better.=20

>=20
> Pls let me know if I did something wrong during testing or if my test set=
up 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 =3D "barebox-environment";
>  		reg =3D <0xe0000 0x20000>;
>  	};
> +
> +	parition@100000 {
> +		label =3D "user-partition";
> +		reg =3D <0x100000 0x100000>;
> +	};
>  };
>=20
>  &ocotp {
> 8<---------------------------------------------------------------------
> to the barebox device tree.
>=20
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Flists.=
infra
> dead.org%2Fpipermail%2Flinux-mtd%2F2020-September%2F082099.html&am
> p;data=3D02%7C01%7Cyibin.gong%40nxp.com%7C324d4b5c2f2344883a3108d85
> 67166f9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63735439234
> 6471210&amp;sdata=3Dru8fKz6wpDhzYeaHIT28T0OybHlCFHJ41N1lJYuqKgE%3D&
> amp;reserved=3D0
>=20
> Regards,
>   Marco