Re: [RFC PATCH v2 11/12] spi: cadence-quadspi: restrict PHY frequency to tuned operations

[Santhosh Kumar K]

Hello Miquel,

On 17/03/26 20:47, Miquel Raynal wrote:
> Hi Santhosh,
>
> + Frieder and Eberhard
>
> On 13/02/2026 at 09:21:11 +01, Miquel Raynal <miquel.raynal@xxxxxxxxxxx> wrote:
>
> > On 07/02/2026 at 00:57:04 +0530, Santhosh Kumar K <s-k6@xxxxxx> wrote:
> >
> > > On 05/02/26 23:17, Miquel Raynal wrote:
> > > > Hi Santhosh,
> > > >
> > > > > +	/*
> > > > > +	 * PHY tuning allows high-frequency operation only for calibrated
> > > > > +	 * commands. Uncalibrated operations use safe non-PHY frequency to
> > > > > +	 * avoid timing violations.
> > > > > +	 */
> > > > > +	if (cqspi->ddata->execute_tuning && f_pdata->use_phy &&
> > > > > +	    (cqspi_op_matches_tuned(op, &f_pdata->phy_read_op) ||
> > > > > +	     cqspi_op_matches_tuned(op, &f_pdata->phy_write_op))) {
> > > > > +		cqspi_configure(f_pdata, op->max_freq);
> > > > > +	} else if (cqspi->ddata->execute_tuning) {
> > > > > +		/* Use safe frequency for untuned operations */
> > > > > +		cqspi_configure(f_pdata, f_pdata->non_phy_clk_rate);
> > > > > +	} else {
> > > > > +		/* No tuning support, always use requested frequency */
> > > > > +		cqspi_configure(f_pdata, op->max_freq);
> > > > > +	}
> > > > Shouldn't we handle this at the core level? We know what kind of
> > > > operation pattern we provided, so it is easy to set the correct
> > > > frequency in the operation structure.
> > > > Can you please make this happen? Perhaps you can return the operation
> > > > frequency once the calibration is successful (in the read and write op
> > > > templates maybe?) so this can be picked up by the core and used for the
> > > > following operations. This way the controller driver no longer needs to
> > > > check if the operation has been tuned or not, it can just look at the
> > > > frequency. When using the highest frequency, PHY tuning must be
> > > > used/enabled, otherwise not.
> > >
> > > No, Miquel, this may not be correct. There can be cases where an
> > > operation does not require tuning but still can run at maximum
> > > frequency (166 MHz, for instance).
> >
> > This is currently not the case. Currently you tune for one or two ops
> > (read/write) and you enable PHY tuning only on these. Do you plan on
> > adding such a feature? If not, I would not bother with this now.
> >
> > > In such scenarios, simply setting
> > > op->max_freq to the maximum frequency value and deciding whether to
> > > enable tuning based on an op->max_freq comparison would not be
> > > sufficient.
> >
> > If there are such cases, can they be listed? I am sorry but I fail to
> > see where this would not work. Any examples to share?
>
> I don't know if you got my feedback

Sorry for the late reply - I did see your feedback, just got caught up
with some critical work.

, but I would like to have all cases
> in mind to decide in which direction we must go. Especially, I would
> like to make the bridge with Frieder's work who is also "playing" with
> the maximum frequency.

Yes, I've gone through the series.

> We need to clarify our mental picture of the max_freq handling. How it
> should be derived, how autonomous shall the SPI controllers be wrt this
> value, shall we flag operations that can go faster and if yes, can we
> attach a meaningful value to these operations, etc etc.
>
> I feel like this is the part that needs extra thinking. The rest of the
> series is promising. I would like us to clarify the needs, maybe propose
> some kind of drawing/slides or even take half an hour to discuss in a
> call once we have all cases in mind.

I'll need a bit more time to gather some ideas and inputs, since I'm
switching back to this after a while. That said, we can still plan for a
call if there's already a proposal to discuss.

Regards,
Santhosh.

> Thanks,
> Miquèl