Linux SPI subsystem development
 help / color / mirror / Atom feed
From: "Nuno Sá" <nuno.sa@analog.com>
To: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Parshuram Thombare <pthombar@cadence.com>,
	devicetree@vger.kernel.org
Cc: Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Jisheng Zhang <jszhang@kernel.org>,
	Fei Xie <fei.xie@horizon.auto>
Subject: Re: [PATCH 0/3] spi: cadence-xspi: add ACMD mode support
Date: Thu, 29 Oct 2026 16:07:26 +0000	[thread overview]
Message-ID: <auNu8LJ6lpHqCTAH@nsa> (raw)
In-Reply-To: <20261029-xspi-cadence-add-acmd-v1-0-f4f15bc807fa@analog.com>

On Thu, Oct 29, 2026 at 03:53:07PM +0000, Nuno Sá wrote:
> The Cadence xSPI driver currently drives every operation through STIG
> mode, where the CPU builds each command and drains the data. The
> controller also has an auto command (ACMD) mode where it runs whole
> sequences on its own and can move data with its internal DMA, which
> pays off for bulk reads.
> 
> Whether ACMD and the internal DMA can be used depends on the SoC
> integration (external SRAM, the DMA bus requester interface being
> wired), which the controller registers do not expose. Hence two new
> devicetree properties: cdns,has-acmd and cdns,has-internal-dma.
> 
> For now, ACMD is only used for reads of at least 2048 bytes with an
> address phase, using the internal DMA, and only when both properties
> are set. Smaller reads and all other operations stay on STIG.
> 
> NOR and NAND are handled the same way: NAND operations are still issued
> one by one, not combined into a single ACMD sequence, so no NAND
> geometry is needed. The real gain is on large reads which, for NAND,
> means chips supporting buffer/sequential read mode.
> 
> Another attempt for ACMD was sent in [1] but that relies on knowing the
> NAND geometry which brings much more complexity given that it needs a
> proper interface implemented in the spi-nand core. So we agreed on
> starting with this simpler approach and then build on top of it if we
> agree it pays off (mostly on cpu load).
> 
> Some stats:
> 
> ACMD
> -----
> 
> SPI-NOR - is25wx01g (only reads > 2k are done in ACMD )
> -------
> 
> flash_speed -c 5 -d /dev/mtd4
> not NAND flash, assume page size is 512 bytes.
> scanning for bad eraseblocks
> scanned 5 eraseblocks, 0 are bad
> testing eraseblock write speed
> eraseblock write speed is 1054 KiB/s
> testing eraseblock read speed
> eraseblock read speed is 106666 KiB/s
> testing page write speed
> page write speed is 1035 KiB/s
> testing page read speed
> page read speed is 15238 KiB/s
> 
> SPI-NAND - w25n08lw (all reads are ACMD given that page size is 4k)
> --------
> 
> flash_speed -c 5 -d /dev/mtd5
> scanning for bad eraseblocks
> scanned 5 eraseblocks, 0 are bad
> testing eraseblock write speed
> eraseblock write speed is 6497 KiB/s
> testing eraseblock read speed
> eraseblock read speed is 44137 KiB/s
> testing page write speed
> page write speed is 6336 KiB/s
> testing page read speed
> page read speed is 16842 KiB/s
> 
> STIG
> ----
> 
> SPI-NOR
> -------
> 
> flash_speed -c 5 -d /dev/mtd4
> not NAND flash, assume page size is 512 bytes.
> scanning for bad eraseblocks
> scanned 5 eraseblocks, 0 are bad
> testing eraseblock write speed
> eraseblock write speed is 1054 KiB/s
> testing eraseblock read speed
> eraseblock read speed is 64000 KiB/s
> testing page write speed
> page write speed is 1042 KiB/s
> testing page read speed
> page read speed is 14883 KiB/s
> 
> SPI-NAND (Cont mode)
> --------
> 
> flash_speed -c 5 -d /dev/mtd5
> scanning for bad eraseblocks
> scanned 5 eraseblocks, 0 are bad
> testing eraseblock write speed
> eraseblock write speed is 6564 KiB/s
> testing eraseblock read speed
> eraseblock read speed is 18823 KiB/s
> testing page write speed
> page write speed is 6400 KiB/s
> testing page read speed
> page read speed is 18028 KiB/s
> 
> For now, we have a static threshold to decide to use ACMD or not. I do
> understand that's not ideal. It might depend on sclk and number of lanes
> so not sure if that value will be accurate for everybody. So, open to
> suggestions if someone has something in mind regarding this.
> 
> [1]: https://lore.kernel.org/linux-spi/20260921093701.1341766-1-fei.xie@horizon.auto/
> 
> ---
> Nuno Sá (3):
>       spi: cadence-xspi: rename sdma_error to xfer_error
>       spi: dt-bindings: cdns,xspi: add ACMD and internal DMA properties
>       spi: cadence-xspi: add ACMD mode support
> 
>  .../devicetree/bindings/spi/cdns,xspi.yaml         |  18 ++
>  drivers/spi/spi-cadence-xspi.c                     | 269 +++++++++++++++++++--
>  2 files changed, 273 insertions(+), 14 deletions(-)
> ---
> base-commit: 7da2aca123754c0e06092bbe179d58078b58d8d4
> change-id: 20261027-xspi-cadence-add-acmd-3c0e342cb4f4
> --
> 
> Thanks!
> - Nuno Sá
> 

Ignore this one! 

Somehow lost connection during be send and only this went out! The
complete series was sent afterwards!

- Nuno Sá


  reply	other threads:[~2026-10-29 16:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 15:53 [PATCH 0/3] spi: cadence-xspi: add ACMD mode support Nuno Sá
2026-10-29 16:07 ` Nuno Sá [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-10-29 16:03 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=auNu8LJ6lpHqCTAH@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=jszhang@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=pthombar@cadence.com \
    --cc=robh@kernel.org \
    /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