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

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]

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?

> 
> 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.

> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]