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

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Nuno Sá" <nuno.sa@analog.com>
Cc: Mark Brown <broonie@kernel.org>,  Fei Xie <fei.xie@horizon.auto>,
	Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 Rob Herring <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	 Parshuram Thombare <pthombar@cadence.com>,
	 linux-spi@vger.kernel.org, linux-mtd@lists.infradead.org,
	 devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/4] spi: cadence-xspi: add ACMD support for SPI NAND
Date: Fri, 25 Sep 2026 12:23:21 +0200	[thread overview]
Message-ID: <87ecehljdy.fsf@bootlin.com> (raw)
In-Reply-To: <arZHjbzUEFhydnHt@nsa> ("Nuno Sá"'s message of "Fri, 25 Sep 2026 11:14:01 +0100")

Hello,

>> > 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).

That's precisely what I was expecting.

> 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).

I am very happy to see this feature being used! It already caused quite
a bit of churn in the core :-)

> As for PROGRAM and ERASE commands I really did not saw any added
> value.

Yes, most of the time is spent in the wait_ready, which is not getting
faster with hardware automation.

> 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.

Thanks,
Miquèl

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