Re: [PATCH 1/2] spi: dt-bindings: spi-fsl-qspi: add optional sampling-delay

[Michael Walle <michael@walle.cc>]

>>>>> unfortunately, the rx-sample-delay-ns property does not fit here, 
>>>>> as we
>>>>> can only delay
>>>>> the sampling point between zero and three "half cycles" (or edges), 
>>>>> not
>>>>> by an arbitrary
>>>>> number of nanoseconds.
>>>> 
>>>> Why this is a problem for FSL but not for other platforms having 
>>>> exactly
>>>> the same constraints/property?
>>> 
>>> Please use the common delay in DT and calculate to half cycle in 
>>> driver, we have
>>> the similar discussion before for fspi controller delay settings.
>> 
>> Do you mean [1]? There my suggestion was to use a -degrees property 
>> (because
>> it doesn't depend on the frequency). There wasn't any follow-up, or 
>> did I miss
>> something?
>> 
>> -michael
>> 
>> [1] 
>> https://lore.kernel.org/linux-spi/62f113a0cdb0d58bf04ab0b274912eb7@walle.cc/
> 
> I think the patch using existing ns property (and calculating cycles or
> phase shift or whatever was needed) was merged. In such case please go
> the same way.

I couldn't find anything that the fspi driver now supports this delay.

I still think this is the wrong way to go. Like I said, it depends on
the frequency, which means that you need to change the delay-ns property
everytime you change the frequency. Think of a bootloader which patches
the frequency (or something like that). But what's worse is that you
cannot have an enum in the binding for this property then.

Now OTOH, you could actually have a hardware which take the
delay as a time period, in that case this -delay-ns makes sense
and recalculating that into -degrees would be impossible.

Are there standard properties which expresses the same, but just in a
different way? Like for example drive strength as an impedance or in
current at a specific voltage. But having two different properties for
the same thing might be just as bad..

-michael