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

[Miquel Raynal <miquel.raynal@bootlin.com>]

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