Re: [RFC PATCH 0/4] spi: cadence-xspi: add ACMD PIO support for NAND and NOR

From: "Nuno Sá" <nuno.sa@analog.com>
To: Fei Xie <fei.xie@horizon.auto>
Cc: "Nuno Sá" <noname.nuno@gmail.com>,
	miquel.raynal@bootlin.com, broonie@kernel.org,
	linux-spi@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: [RFC PATCH 0/4] spi: cadence-xspi: add ACMD PIO support for NAND and NOR
Date: Thu, 15 Oct 2026 14:03:09 +0100	[thread overview]
Message-ID: <atDMqnFiKJc5pVlp@nsa> (raw)
In-Reply-To: <20261014093453.688565-1-fei.xie@horizon.auto>

On Wed, Oct 14, 2026 at 05:34:53PM +0800, Fei Xie wrote:
> Hi Nuno,
> 
> Thanks for proposing this. I agree that starting with your simpler ACMD
> support makes sense. Please go ahead with that approach. I would be happy
> to help test it on our Horizon J6B board.

Alright, will prepare something for the next few days (or next week
tops).

> 
> To clarify my earlier benchmarks, "sequential read" referred to reading
> consecutive addresses from /dev/mtd18 using dd, not the NAND device's
> continuous-read mode. Our GD5F4GM8RE datasheet describes page-based reads
> with cache output wrapping within the current page, and its SPI-NAND
> driver entry does not advertise continuous-read support.

Yeah, gave a quick look on the DS. Seems like it does not support it.

> 
> Could you point me to the version you would recommend testing? I can
> compare it against the optimized STIG path and our combined NAND
> read-sequence implementation under the same conditions, checking data
> integrity, throughput and CPU usage.

What do you mean? IIRC, you need to make sure what you're testing has
this:

https://lore.kernel.org/linux-spi/20260511031732.3199-3-jszhang@kernel.org/

But even with the above I saw a slight improvement on performance by
combining the commands. I did not check CPU which should be big gain on
aggregating.

- Nuno Sá

> 
> That should help establish whether combining page-read, ready-poll and
> read-cache operations provides enough additional benefit on this device
> to justify further interface changes. We can then use those results to
> decide what, if anything, should be built on top of the simpler ACMD
> support.
> 
> I also agree that program and erase can remain on the STIG path, given
> our results.
> 
> Thanks,
> Fei
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/