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@xxxxxxxx/
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
