+ /* Find an approximate index by looking up the table */Any why is your PHY special, in that is does care about out of rangeWe are not rounding to nearest here. Basically the helper works to find the
delays, when others using new the new core helper don't?
best match
If the delay passed in is less than or equal to the smallest delay then
return the smallest delay index
If the delay passed in is greater then the largest delay then return the max
delay index
+ if (delay > delay_values[i - 1] &&
+ delay < delay_values[i]) {
+ if (delay - delay_values[i - 1] < delay_values[i] - delay)
+ return i - 1;
+ else
+ return i;
This appears to round to the nearest value when it is not an exact
match.
The documentation is a hint to the DT developer what value to put in
DT. By saying it rounders, the developer does not need to go digging
through the source code to find an exact value, otherwise -EINVAL will
be returned. They can just use the value the HW engineer suggested,
and the PHY will pick whatever is nearest.
Not sure what you mean about this PHY being special. This helper isAs you said, if out of range, the helper returns the top/bottom
not PHY specific.
value. Your PHY is special, the top/bottom value is not good enough,
you throw an error.
The point of helpers is to give uniform behaviour. We have one line
helpers, simply because they give uniform behaviour, rather than have
each driver do it subtlety different. But it also means drivers should
try to not add additional constraints over what the helper already
has, unless it is actually required by the hardware.
After I think about this more I am thinking a helper may be over kill hereThe helper is useful, it will result in uniform handling of rounding
and the delay to setting should be done within the PHY driver itself
between DT values and what the PHY can actually do. But please also
move your range check and error message inside the helper.
Andrew