-----Original Message-----
From: Jonathan Cameron <jic23@kernel.org>
Sent: Sunday, January 31, 2021 12:36 PM
To: Sa, Nuno <Nuno.Sa@analog.com>
Cc: devicetree@vger.kernel.org; linux-iio@vger.kernel.org; Rob
Herring [off-list ref]; Peter Meerwald-Stadler
[off-list ref]; Lars-Peter Clausen [off-list ref];
Hennerich, Michael [off-list ref]; Ardelean,
Alexandru [off-list ref]
Subject: Re: [PATCH 0/4] Fix/Improve sync clock mode handling


On Mon, 25 Jan 2021 09:16:19 +0000
"Sa, Nuno" [off-list ref] wrote:

quoted

quoted

-----Original Message-----
From: Jonathan Cameron <jic23@kernel.org>
Sent: Sunday, January 24, 2021 3:21 PM
To: Sa, Nuno <Nuno.Sa@analog.com>
Cc: devicetree@vger.kernel.org; linux-iio@vger.kernel.org; Rob
Herring [off-list ref]; Peter Meerwald-Stadler
[off-list ref]; Lars-Peter Clausen [off-list ref];
Hennerich, Michael [off-list ref]; Ardelean,
Alexandru [off-list ref]
Subject: Re: [PATCH 0/4] Fix/Improve sync clock mode handling


On Thu, 21 Jan 2021 12:49:50 +0100
Nuno Sá [off-list ref] wrote:

quoted

The first patch in this series is just a simple helper to lock/unlock
the device. Having these helpers make the code slightly neater

(IMHO).

quoted

The following patches introduces changes in the sampling

frequency

quoted

quoted

quoted

calculation when sync scale/pps modes are used. First, it's

important

quoted

quoted

quoted

to understand the purpose of this mode and how it should be

used.

quoted

quoted

Let's

quoted

say our part has an internal rate of 4250 (e.g adis1649x family) and

the

quoted

user wants an output rate of 200SPS. Obviously, we can't use this
sampling rate and divide back down to get 200 SPS with

decimation

quoted

quoted

on.

quoted

Hence, we can use this mode to give an input clock of 1HZ, scale it

to

quoted

quoted

quoted

something like 4200 or 4000 SPS and then use the decimation

filter to

quoted

quoted

get

quoted

the exact desired 200SPS. There are also some limits that should

be

quoted

quoted

quoted

taken into account when scaling:

 * For the devices in the adis16475 driver:
     - Input sync frequency range is 1 to 128 Hz
     - Native sample rate: 2 kSPS.  Optimal range: 1900-2100 sps

 * For the adis1649x family (adis16480 driver):
    - Input sync frequency range is 1 to 128 Hz
    - Native sample rate: 4.25 kSPS.  Optimal range: 4000-4250 sps

I'm not 100% convinced on how to handle the optimal minimum.

For

quoted

quoted

now,

quoted

I'm just throwing a warning saying we might get into trouble if we

get

quoted

quoted

a

quoted

value lower than that. I was also tempted to just return -EINVAL

or

quoted

quoted

quoted

clamp the value. However, I know that there are ADI customers

that

quoted

quoted

quoted

(for some reason) are using a sampling rate lower than the

minimum

quoted

quoted

quoted

advised.

So the opening question I'd have here is how critical is the actual
userspace sampling rate to your users?   Often they don't mind
getting a little more data than they asked for (say 200.5Hz when

asking

quoted

quoted

for 200) and can always read back the attribute after writing it to
discover this has happened.

Well, honestly I'm not really sure here. I can just say (from the info I

got internally) that some

quoted

users are really using these parts with a data rate lower than the

advised. However, I'd say

quoted

that this would depend on the use case. For some critical cases, I

would expect that users really

quoted

want to have an exact sample rate. Though I'd argue that in those

cases, they should know what

quoted

they are doing and provide an output rate that fits nicely (multiple of

both the input clock and IMU

quoted

internal sample rate). And as you said, they can always readback the

value to check if they are

quoted

getting something that is not really what they expect...

quoted

As such, once you've discovered that value doesn't have an exact
match, perhaps tweak the output data rate until it fits nicely?

I did thought about this. The reason why I didn't went for it in this

first version is because of those

quoted

who seems to really want to run the part at lower rates. Let's assume

we have an input clock of

quoted

1HZ and someone writes an output rate of 3000SPS. The only way to

accomplish this is to set

quoted

sync_scale at 3000 and let the IMU run at 3000SPS with decimation

off (DEC_RATE=0). If we are

quoted

going to tweak the output rate to fit nicely, we would have to force it

to 4000SPS which is

quoted

significantly different from the desired 3000SPS.

Good point. If someone wants to do that there isn't much we can do
to make it work nicely.  I'd argue they are wrong and move it to
the nearest within the constraints, but that might be rather
unexpected
for them...

I wonder if we do something ugly like have an extra control to
say 'really do what I say even if it's horrible'.
That would mean we'd get what 'most' users expect (I hope) in that
it's within the documented range, but provide the control to those
who want to do something horrible..  Not nice, what do you think?

You mean like a driver parameter? Not sure a runtime control would
make much sense (either you want this or not). Yeah, it is definitely 
not pretty but I seems to be the only way to make everyone 'happy'.

quoted

quoted

A bit of quick investigation suggests (by my wife who happened
to be sat across the room) suggests that you have a hideous set
of local minima so your best bet is to brute force search
(not that bad and we don't expect to change this a lot!)

Hmm, not sure what do you have in mind here :)?

You have two controllable parameters both of which are integers.  As
such
there isn't a nice easy 'right' answer for what combination to use.
For example, if we have a case where there is no right answer, you
will have to search for every possible multiplier, find the best divisor
and check how far that is above the desired frequency.  Of those
find the smallest one (best option given constraints).

Hmm, I need to give it a thought and see what I can come up to v2. We
continue from there.

But this opens one question... Do we want to tweak the output rate to fit
nicely only for 'if (imu_rate) < 4000' or should we also do it in the other
cases? By other cases I mean 'if (lcm(output_rate, input_ckl) > max_imu_rate)'
and in the generic case where we don't have external clock and the IMU runs
with it's internal rate (pretty much all the time the value does not fit nicely)?
Note that DEC_RATE is an integer parameter and for things to fit nicely, the
rate given by the user should be a multiple of the IMU sampling rate. I'm bringing
this up because if we are going into this much trouble to tweak the user rate to
fit nicely and avoid 'possible' undersampling issues, we might do the same for the
other cases... Otherwise, to avoid the oversampling case we could just force the
IMU sample rate to the maximum multiple of the input clock lower than max_rate
and calculate DEC_RATE with 'DIV_ROUND_CLOSEST()' which is what we are
already doing for the generic case. Naturally with this, the user won't get exactly
what he might expect as DEC_RATE is an integer (but again, that is how things are now anyways)...
We would still need the extra control for those who really want to stick to lower IMU rates.

- Nuno Sá

Jonathan

quoted

- Nuno Sá

quoted

quoted

That said, the patch for the adis16480 driver is a fix as this mode

was

quoted

quoted

quoted

being wrongly handled. There should not be a "separation"

between

quoted

quoted

using

quoted

the sync_scale and the dec_rate registers. The way things were

being done,

quoted

we could easily get into a situation where the part could be

running

quoted

quoted

with

quoted

an internal rate way lower than the optimal minimum.

For the adis16475 drivers, things were not really wrong. They

were

quoted

quoted

just

quoted

not optimal as we were forcing users to specify the IMU scaled

internal

quoted

rate once in the devicetree. Calculating things at runtime gives

much

quoted

quoted

quoted

more flexibility to choose the output rate.

Nuno Sá (4):
  iio: adis: add helpers for locking
  iio: adis16480: fix pps mode sampling frequency math
  iio: adis16475: improve sync scale mode handling
  dt-bindings: adis16475: remove property

 .../bindings/iio/imu/adi,adis16475.yaml       |   9 --
 drivers/iio/imu/adis16475.c                   | 110 ++++++++++++----
 drivers/iio/imu/adis16480.c                   | 120 +++++++++++++-----
 include/linux/iio/imu/adis.h                  |  10 ++
 4 files changed, 178 insertions(+), 71 deletions(-)