Re: [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@xxxxxx>
> > > > Sent: Thursday, June 18, 2026 1:07 PM
> > > > To: broonie@xxxxxxxxxx; robh@xxxxxxxxxx; krzk+dt@xxxxxxxxxx;
> > > > conor+dt@xxxxxxxxxx; miquel.raynal@xxxxxxxxxxx; richard@xxxxxx;
> > > > vigneshr@xxxxxx; pratyush@xxxxxxxxxx; mwalle@xxxxxxxxxx;
> > > > takahiro.kuwano@xxxxxxxxxxxx
> > > > Cc: linux-spi@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-
> > > > kernel@xxxxxxxxxxxxxxx; linux-mtd@xxxxxxxxxxxxxxxxxxx; 
> > > > praneeth@xxxxxx; u-
> > > > kumar1@xxxxxx; a-dutta@xxxxxx; s-k6@xxxxxx
> > > > 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@xxxxxx/

Thanks,
Santhosh.

> Thanks,
> Michal