Re: [PATCH v3 01/13] spi: dt-bindings: allow spi-max-frequency to specify a frequency pair

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

Hi Conor,

On 02/06/2026 at 17:18:15 +01, Conor Dooley <conor@kernel.org> wrote:

> On Tue, Jun 02, 2026 at 02:05:53PM +0200, Miquel Raynal wrote:
>> Hello Conor, Santhosh,
>> 
>> >> I also don't get the point of this property, why can't you just set
>> >> the
>> >> max that the device can do and if the controller can configure itself to
>> >> be fast enough it will do so, and if it can't then it'll pick whatever
>> >> the fastest it can actually do instead?
>> 
>> If I may, this is not doable because there is always a phase at low
>> speed. By low speed, I mean the speed which allows reliable data
>> transfers between the host and the device. This "maximum low" speed is
>> non discoverable, it is necessary to describe it. As of today, it is
>> widely used (and I believe for good reasons) and covers 99.99% of the
>> use cases.
>> 
>> >> Seems like you're abusing a peripheral property to encode information
>> >> about the controller.
>> >
>> > The controller-side approach you mentioned is similar to what I had in
>> > v2, where a compatible-specific base_freq is used for non-PHY ops.
>> >
>> > Miquel,
>> >
>> > I think we should revert to the v2 approach.
>> >
>> > The non-PHY frequency is a controller limitation/capability rather than
>> > a flash characteristic, so it seems more appropriate to keep it in the
>> > controller driver as Conor suggested.
>> 
>> The non tuned frequency is the maximum frequency one could use
>> reliably. It is not controller specific. It is mostly board specific,
>> and to some extend may also be chip specific.
>> 
>> The tuned frequency is the maximum frequency one could use reliably
>> after line a controller or chip specific training procedure. It is
>> also the result of an aggregated set of non discoverable hardware
>> limitations:
>> - board routing
>> - chip capability
>> - controller capability
>
> Right, and this I guess is what scuppers letting the controller driver
> sort the configuration out itself and leaving the property as-is.
> It could be that the speed in spi-max-frequency is lower than the "base
> speed" of the controller but because of board routing or device
> capability that the tuned mode is still required, right?

I do not actually expect any tuned mode/frequency to be mandatory.
What Santhosh calls the base speed is typically what we have today, so
the best of what we can do without any line training. spi-max-frequency
expresses exactly this today.

>> We must try to think about other (non TI) possible use cases of these
>> properties and also take into account the existing DT expectations. If
>> turning the property into an array is too complex, we may go for a
>
> I don't think it is "too complex", but it requires removing the
> definitions of spi-max-frequency from the 4 or 5 bindings that redefine
> it and making a mechanical change to all spi device bindings that
> specify a limit. It's not complex, but it will be annoying without
> tooling doing it for you.

Indeed.

>> second property, but I believe the name should not be TI specific (but
>> I'll let the final decision to the DT gurus).
>
> Yeah, I concur. If not doing the 2 cell spi-max-frequency, then
> something like spi-max-post-tuning-frequency or w/e I think should be
> used. Doesn't seem like TI would be the only people that end up doing
> something like this.

Why not. Might be simpler approach from a binding side, while also
rather easy to work with in the spi core.

Thanks,
Miquèl