Re: [RFC PATCH v2 11/12] spi: cadence-quadspi: restrict PHY frequency to tuned operations
From: Miquel Raynal
Date: Fri Feb 13 2026 - 03:21:58 EST
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?
Thanks,
Miquèl