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

[Santhosh Kumar K]

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 <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?

Yes, I've added support for this in the v5 series, which I just
posted. [0]

[0] https://lore.kernel.org/linux-spi/20260717185116.2065505-1-s-k6@ti.com/

Thanks,
Santhosh.

> 
> Thanks,
> Michal