[PATCH v4 00/16] spi: cadence-quadspi: add PHY tuning support
Michal Simek
michal.simek at amd.com
Thu Jul 16 06:57:09 PDT 2026
On 7/16/26 08:04, Santhosh Kumar K wrote:
> Hello Amit,
>
> Apologies for the delayed response.
>
> On 22/06/26 10:00, Mahapatra, Amit Kumar wrote:
>> AMD General
>>
>> Hello Santosh,
>>
>>> -----Original Message-----
>>> From: Santhosh Kumar K <s-k6 at ti.com>
>>> Sent: Thursday, June 18, 2026 1:07 PM
>>> To: broonie at kernel.org; robh at kernel.org; krzk+dt at kernel.org;
>>> conor+dt at kernel.org; miquel.raynal at bootlin.com; richard at nod.at;
>>> vigneshr at ti.com; pratyush at kernel.org; mwalle at kernel.org;
>>> takahiro.kuwano at infineon.com
>>> Cc: linux-spi at vger.kernel.org; devicetree at vger.kernel.org; linux-
>>> kernel at vger.kernel.org; linux-mtd at lists.infradead.org; praneeth at ti.com; u-
>>> kumar1 at ti.com; a-dutta at ti.com; s-k6 at ti.com
>>> Subject: [PATCH v4 00/16] spi: cadence-quadspi: add PHY tuning support
>>>
>>> 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 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
>>
>> Thank you for this series. I had a question regarding the Virtual Concat
>> driver patch series [1]. Now that it has been merged into the kernel and
>> enables support for multiple flash devices connected in stacked mode-where
>> each flash device is probed and configured independently-if both flash
>> parts are required to operate in DDR mode, each device would need to
>> perform tuning and store its tuning data separately.
>>
>> Given this, should we consider this use case and adapt the tuning
>> architecture to support it?
>>
>> I'd appreciate your thoughts on this.
>
> Good point.
>
> The current implementation already stores the calibration state per
> chip select (delay line settings, tuned flags, and operation templates),
> so the data model supports independent tuning for each device.
>
> However, the runtime path that enables PHY mode does not restore the
> per-CS delay line settings when switching between chip selects. As a
> result, consecutive PHY accesses to different devices could end up using
> the wrong delay line settings.
>
> This can be addressed with a small change by reading the currently
> programmed DLL and reprogramming the PHY configuration registers
> whenever they differ from the calibrated values for the selected chip.
Are you going to include it to your series?
Thanks,
Michal
More information about the linux-mtd
mailing list