From: "Nuno Sá" <nuno.sa@analog.com>
To: Miquel Raynal <miquel.raynal@bootlin.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:31:57 +0100 [thread overview]
Message-ID: <arZbZiSTIRT3sxQ2@nsa> (raw)
In-Reply-To: <87ecehljdy.fsf@bootlin.com>
On Fri, Sep 25, 2026 at 12:23:21PM +0200, Miquel Raynal wrote:
> 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 :-)
Yes, I updated my Windbond W25N08LW patch (I resend v2 recently) with
cont mode precisely for this xspi ACMD effort.
- Nuno Sá
>
> > 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/
next prev parent reply other threads:[~2026-09-25 11:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 9:36 [RFC PATCH 0/4] spi: cadence-xspi: add ACMD PIO support for NAND and NOR Fei Xie
2026-09-21 9:36 ` [RFC PATCH 1/4] dt-bindings: spi: cdns,xspi: add SPI NAND compatible Fei Xie
2026-09-21 14:01 ` Mark Brown
2026-09-23 12:54 ` Krzysztof Kozlowski
2026-09-21 9:36 ` [RFC PATCH 2/4] spi: cadence-xspi: add ACMD support for SPI NAND Fei Xie
2026-09-21 14:51 ` Mark Brown
2026-09-23 6:12 ` Fei Xie
2026-09-24 18:55 ` Mark Brown
2026-09-25 9:45 ` Miquel Raynal
2026-09-25 10:14 ` Nuno Sá
2026-09-25 10:23 ` Miquel Raynal
2026-09-25 11:31 ` Nuno Sá [this message]
2026-09-23 12:37 ` Nuno Sá
2026-09-21 9:37 ` [RFC PATCH 3/4] spi: cadence-xspi: factor out reusable ACMD helpers Fei Xie
2026-09-21 9:37 ` [RFC PATCH 4/4] spi: cadence-xspi: add ACMD support for SPI NOR Fei Xie
2026-09-23 12:24 ` [RFC PATCH 0/4] spi: cadence-xspi: add ACMD PIO support for NAND and NOR Nuno Sá
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=arZbZiSTIRT3sxQ2@nsa \
--to=nuno.sa@analog.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fei.xie@horizon.auto \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=pthombar@cadence.com \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®