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

[Miquel Raynal]

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

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
second property, but I believe the name should not be TI specific (but
I'll let the final decision to the DT gurus).

Thanks,
Miquèl