Re: [PATCH v4 00/16] spi: cadence-quadspi: add PHY tuning support
Michal Simek <[email protected]> Thu, 16 Jul 2026 15:57:09 +0200
| Newsgroups | gmane.linux.drivers.devicetree,gmane.linux.kernel.spi.devel,gmane.linux.kernel,gmane.linux.drivers.mtd |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> >>> Sent: Thursday, June 18, 2026 1:07 PM >>> To: [email protected]; [email protected]; [email protected]; >>> [email protected]; [email protected]; richard-/[email protected]; >>> [email protected]; [email protected]; [email protected]; >>> takahiro.kuwano-d0qZbvYSIPpWk0Htik3J/[email protected] >>> Cc: [email protected]; [email protected]; linux- >>> [email protected]; [email protected]; [email protected]; u- >>> [email protected]; [email protected]; [email protected] >>> 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