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