* [PATCH 0/3] spi: cadence-xspi: add ACMD mode support
@ 2026-10-29 15:53 Nuno Sá
2026-10-29 16:07 ` Nuno Sá
0 siblings, 1 reply; 3+ messages in thread
From: Nuno Sá @ 2026-10-29 15:53 UTC (permalink / raw)
To: linux-spi, linux-kernel, Parshuram Thombare, devicetree
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jisheng Zhang, Fei Xie
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á
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH 0/3] spi: cadence-xspi: add ACMD mode support
@ 2026-10-29 16:03 Nuno Sá
0 siblings, 0 replies; 3+ messages in thread
From: Nuno Sá @ 2026-10-29 16:03 UTC (permalink / raw)
To: linux-spi, linux-kernel, Parshuram Thombare, devicetree
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jisheng Zhang, Fei Xie
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á
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 0/3] spi: cadence-xspi: add ACMD mode support
2026-10-29 15:53 [PATCH 0/3] spi: cadence-xspi: add ACMD mode support Nuno Sá
@ 2026-10-29 16:07 ` Nuno Sá
0 siblings, 0 replies; 3+ messages in thread
From: Nuno Sá @ 2026-10-29 16:07 UTC (permalink / raw)
To: linux-spi, linux-kernel, Parshuram Thombare, devicetree
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jisheng Zhang, Fei Xie
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á
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-29 16:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-29 15:53 [PATCH 0/3] spi: cadence-xspi: add ACMD mode support Nuno Sá
2026-10-29 16:07 ` Nuno Sá
-- strict thread matches above, loose matches on Subject: below --
2026-10-29 16:03 Nuno Sá
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox