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

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