Message-ID: <87343ghkek.fsf@bootlin.com>
Date: Wed, 04 Feb 2026 11:29:07 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Santhosh Kumar K <s-k6@...com>
Cc: <broonie@...nel.org>,  <robh@...nel.org>,  <krzk+dt@...nel.org>,
  <conor+dt@...nel.org>,  <richard@....at>,  <vigneshr@...com>,
  <tudor.ambarus@...aro.org>,  <pratyush@...nel.org>,  <mwalle@...nel.org>,
  <linux-spi@...r.kernel.org>,  <devicetree@...r.kernel.org>,
  <linux-kernel@...r.kernel.org>,  <linux-mtd@...ts.infradead.org>,
  <praneeth@...com>,  <u-kumar1@...com>,  <p-mantena@...com>,
  <a-dutta@...com>
Subject: Re: [RFC PATCH v2 00/12] spi: cadence-quadspi: add PHY tuning support

Hi Santhosh,

On 13/01/2026 at 19:46:05 +0530, Santhosh Kumar K <s-k6@...com> wrote:

> This series implements PHY tuning support for the Cadence QSPI controller to
> enable reliable high-speed operations. Without PHY tuning, controllers use
> conservative timing that limits the performance. PHY tuning calibrates RX/TX
> delay lines to find optimal data capture timing windows, enabling operation up
> to the controller's maximum frequency.
>
> Background:
> High-speed SPI memory controllers require precise timing calibration for
> reliable operation. At higher frequencies, board-to-board variations make
> fixed timing parameters inadequate. The Cadence QSPI controller includes
> a PHY interface with programmable delay lines (0-127 taps) for RX and TX
> paths, but these require runtime calibration to find the valid timing window.
>
> Approach:
> Add SDR/DDR PHY tuning algorithms for the Cadence controller:
>
> SDR Mode Tuning (1D search):
> - Searches for two consecutive valid RX delay windows
> - Selects the larger window and uses its midpoint for maximum margin
> - TX delay fixed at maximum (127) as it's less critical in SDR
>
> DDR Mode Tuning (2D search):
> - Finds RX boundaries (rxlow/rxhigh) using TX window sweeps
> - Finds TX boundaries (txlow/txhigh) at fixed RX positions
> - Defines valid region corners and detects gaps via binary search
> - Applies temperature compensation for optimal point selection
> - Handles single or dual passing regions with different strategies
>
> DQS Support:
> - Adds optional DQS (Data Strobe) mode for improved timing margins
> - Configures read data capture to use dedicated strobe signal

I am glad to know this signal is useful. I do not consider the DT
property as being the correct way to carry this information ATM, so I
will investigate a bit a propose a solution that is more uniform with
the rest of the chips description we have today.

> Patch description:
> Infrastructure (1-5):
> - Patch 1:   Add DT binding for spi-has-dqs property
> - Patch 2:   Implement spi_mem_execute_tuning() API in SPI core
> - Patch 3-5: Refactor and integrate tuning in MTD SPI-NAND/NOR layers and call
>              tuning during probe
>
> Cadence QSPI Implementation (6-12):
> - Patch 6-8: Preparatory refactoring and DQS support
> - Patch 9:   Add PHY tuning infrastructure with placeholders
> - Patch 10:  Implement complete SDR/DDR tuning algorithms
> - Patch 11:  Restrict PHY frequency to calibrated operations only
> - Patch 12:  Enable PHY for direct memory-mapped reads and large writes
>
> Testing:
> This series was tested on TI's
> AM62A SK with OSPI NAND flash and
> AM62P SK with OSPI NOR flash:
>
> Read throughput:
> |-------------------------------------|
> |           | without PHY | with PHY  |
> |-------------------------------------|           
> |OSPI NOR   | 37.5 MB/s   | 216 MB/s  |
> |-------------------------------------|
> |OSPI NAND  | 9.2 MB/s    | 35.1 MB/s |
> |-------------------------------------|

I am surprised by these numbers, I would expect these to get higher for
SPI NANDs. I will test the series and report my observations, especially
since there is also ODDR SPI NAND support now (in nand/next, should be
part of my upcoming merge request to Linus for 6.19+1);

> Write throughput:
> |-------------------------------------|
> |           | without PHY | with PHY  |
> |-------------------------------------|           
> |OSPI NAND  | 6 MB/s      | 9.2 MB/s  |
> |-------------------------------------|

Overall I want to say that this series has greatly improved already, I
am really looking forward seeing this merged. I have several comments to
make, but they are mostly minor improvements which won't be very
impacting.

The tuning procedure is very well described in the code as well, which
is appreciated.

Please remove the RFC prefix for v3, it is clearly no longer needed.

Thanks,
Miquèl

Powered by blists - more mailing lists