Re: [RFC PATCH 2/4] spi: cadence-xspi: add ACMD support for SPI NAND

["Nuno Sá" <nuno.sa@analog.com>]

On Fri, Sep 25, 2026 at 11:45:51AM +0200, Miquel Raynal wrote:
> On 24/09/2026 at 19:55:58 +01, Mark Brown <broonie@kernel.org> wrote:
> 
> > On Wed, Sep 23, 2026 at 02:12:11PM +0800, Fei Xie wrote:
> >
> >> The difficulty is that the hardware ACMD sequencer needs the complete
> >> multi-operation sequence to be described before it is started. For
> >> example, the SPI NAND core currently submits PAGE READ, status polling
> >> and READ CACHE as separate spi_mem_exec_op() calls. The STIG path can
> >> execute those operations individually, while the ACMD hardware combines
> >> them into one programmed sequence.
> >
> >> Would an SPI-mem operation-sequence interface be a reasonable direction
> >> to explore? The NAND core could describe the ordered operations and
> >> polling condition, and the controller could either execute the sequence
> >> in hardware or fall back to the existing individual operations. This
> >> would keep NAND-specific knowledge out of the controller driver.
> >
> > I think that makes sense, that mirrors some ideas people have had for
> > optimising SPI mesages in general - submit the sequence to the driver to
> > see if it can do it in one, falling back to just running individual
> > operations if that doesn't work.  See spi_optimize_message().
> 
> The spi-mem operation-sequence interface seems very complex to handle
> correctly IMHO. I fear such a solution would also require major rewrites
> of the core. It is always hard to make fit hardware in code bases not
> thought for them. Most of the time being spent in I/Os and wait states,
> I am wondering how much would be saved by packing the commands. Do you
> have benchmarks?

You can see my replies for a more verbose thing, but the TLDR for me was
that the gains in performance did not really payed off (vs the
complexity we would be adding). The real gains
for me came by using the nand continuous mode so that using ACMD (and
DMA) so that we can actually ready chunks > page size. Of course this works
for nand chips supporting cont mode (which hopefully newer ones all do).

As for PROGRAM and ERASE commands I really did not saw any added value.
So below is my version of this:

https://github.com/analogdevicesinc/linux/pull/3478/changes/477e6095508546552071b825a66522cf697c27c2

I pretty much treat NOR and NAND the same thing. Only when you want to
do thing like having the controller sending commands itself (or walking
pages), then knowing about the chip geometry becomes necessary.

- Nuno Sá

> 
> Thanks,
> Miquèl