Re: [RFC PATCH v2 09/12] spi: cadence-quadspi: add PHY tuning infrastructure

[Santhosh Kumar K]

On 05/02/26 23:09, Miquel Raynal wrote:
> On 13/01/2026 at 19:46:14 +0530, Santhosh Kumar K <s-k6@xxxxxx> wrote:
>
> > Implement the spi_controller_mem_ops execute_tuning callback to enable
> > PHY tuning support for the Cadence controller. PHY tuning optimizes data
> > capture timing at high frequencies by calibrating the read data capture
> > delay through the controller's PHY interface.
> >
> > Tuning algorithm functions (cqspi_phy_tuning_ddr/sdr and
> > cqspi_phy_pre/post_config) are placeholders to be implemented
> > in subsequent commits.
> >
> > Signed-off-by: Santhosh Kumar K <s-k6@xxxxxx>
> > ---
> >   drivers/spi/spi-cadence-quadspi.c | 241 ++++++++++++++++++++++++++++++
> >   1 file changed, 241 insertions(+)
> >
> > diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c
> > index 0df286d24256..b8b0e85f4f68 100644
> > --- a/drivers/spi/spi-cadence-quadspi.c
> > +++ b/drivers/spi/spi-cadence-quadspi.c
> > @@ -32,6 +32,7 @@
> >   
> >   #define CQSPI_NAME			"cadence-qspi"
> >   #define CQSPI_MAX_CHIPSELECT		4
> > +#define CQSPI_AM654_NON_PHY_CLK_RATE	25000000
> >   
> >   static_assert(CQSPI_MAX_CHIPSELECT <= SPI_DEVICE_CS_CNT_MAX);
> >   
> > @@ -65,6 +66,7 @@ struct cqspi_st;
> >   struct cqspi_flash_pdata {
> >   	struct cqspi_st	*cqspi;
> >   	u32		clk_rate;
> > +	u32		non_phy_clk_rate;
>
> This is the second (and last) main issue I have with the series as it is
> right now. We cannot set this type of frequency in the driver IMO, it is
> too board specific.
>
> We currently have a DT property for the SPI maximum supported
> frequency. I believe this is no longer enough. Why not making this
> frequency property an array? First frequency would be the default,
> non tuned maximum frequency. The second would be the maximum frequency
> reachable when tuning the PHY.

If the concern is only about where this is set, we could introduce a DT
property such as "non-phy-max-freq" to carry this information. This
would allow us to avoid any changes to the existing "spi-max-frequency"
handling. Let me know your thoughts on this.

I'll also test the approach you suggested and share my inputs based on
the results. By the way, where are you insisting to adjust/switch to
the maximum frequency - within the controller driver or in the
spi-core?

Regards,
Santhosh.

> The rest of the patch LGTM otherwise, but there is this frequency
> information which I think should be handled with more care.
>
> Thanks,
> Miquèl