Re: [PATCH v4 00/16] spi: cadence-quadspi: add PHY tuning support
Santhosh Kumar K <[email protected]> Sat, 18 Jul 2026 00:30:29 +0530
| Newsgroups | gmane.linux.kernel.spi.devel,gmane.linux.drivers.devicetree,gmane.linux.kernel,gmane.linux.drivers.mtd |
|---|---|
| Message-ID | <[email protected]> |
Hello Michal, On 16/07/26 19:27, Michal Simek wrote: > > > 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? Yes, I've added support for this in the v5 series, which I just posted. [0] [0] https://lore.kernel.org/linux-spi/[email protected]/ Thanks, Santhosh. > > Thanks, > Michal