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

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Santhosh,

+ Frieder and Eberhard

On 13/02/2026 at 09:21:11 +01, Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> On 07/02/2026 at 00:57:04 +0530, Santhosh Kumar K <s-k6@ti.com> 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, 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.

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.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/