Re: [PATCH v4 00/16] spi: cadence-quadspi: add PHY tuning support

[Michal Simek <michal.simek@amd.com>]

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@ti.com>
>>> Sent: Thursday, June 18, 2026 1:07 PM
>>> To: broonie@kernel.org; robh@kernel.org; krzk+dt@kernel.org;
>>> conor+dt@kernel.org; miquel.raynal@bootlin.com; richard@nod.at;
>>> vigneshr@ti.com; pratyush@kernel.org; mwalle@kernel.org;
>>> takahiro.kuwano@infineon.com
>>> Cc: linux-spi@vger.kernel.org; devicetree@vger.kernel.org; linux-
>>> kernel@vger.kernel.org; linux-mtd@lists.infradead.org; praneeth@ti.com; u-
>>> kumar1@ti.com; a-dutta@ti.com; s-k6@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