linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Nuno Sá" <nuno.sa@analog.com>
To: <devicetree@vger.kernel.org>, <linux-iio@vger.kernel.org>
Cc: Jonathan Cameron <jic23@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	Alexandru Ardelean <alexandru.ardelean@analog.com>
Subject: [PATCH 0/4] Fix/Improve sync clock mode handling
Date: Thu, 21 Jan 2021 12:49:50 +0100	[thread overview]
Message-ID: <20210121114954.64156-1-nuno.sa@analog.com> (raw)

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).

The following patches introduces changes in the sampling frequency
calculation when sync scale/pps modes are used. First, it's important
to understand the purpose of this mode and how it should be used. Let's
say our part has an internal rate of 4250 (e.g adis1649x family) and the
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 on.
Hence, we can use this mode to give an input clock of 1HZ, scale it to
something like 4200 or 4000 SPS and then use the decimation filter to get
the exact desired 200SPS. There are also some limits that should be
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 now,
I'm just throwing a warning saying we might get into trouble if we get a
value lower than that. I was also tempted to just return -EINVAL or
clamp the value. However, I know that there are ADI customers that
(for some reason) are using a sampling rate lower than the minimum
advised.

That said, the patch for the adis16480 driver is a fix as this mode was
being wrongly handled. There should not be a "separation" between using
the sync_scale and the dec_rate registers. The way things were being done,
we could easily get into a situation where the part could be running with
an internal rate way lower than the optimal minimum.

For the adis16475 drivers, things were not really wrong. They were just
not optimal as we were forcing users to specify the IMU scaled internal
rate once in the devicetree. Calculating things at runtime gives much
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(-)

-- 
2.30.0


             reply	other threads:[~2021-01-21 11:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21 11:49 Nuno Sá [this message]
2021-01-21 11:49 ` [PATCH 1/4] iio: adis: add helpers for locking Nuno Sá
2021-01-24 13:30   ` Jonathan Cameron
2021-01-25  8:46     ` Sa, Nuno
2021-01-21 11:49 ` [PATCH 2/4] iio: adis16480: fix pps mode sampling frequency math Nuno Sá
2021-01-24 13:43   ` Jonathan Cameron
2021-01-25  8:47     ` Sa, Nuno
2021-01-26  8:29     ` Sa, Nuno
2021-01-21 11:49 ` [PATCH 3/4] iio: adis16475: improve sync scale mode handling Nuno Sá
2021-01-21 11:49 ` [PATCH 4/4] dt-bindings: adis16475: remove property Nuno Sá
2021-02-09 16:04   ` Rob Herring
2021-01-24 14:20 ` [PATCH 0/4] Fix/Improve sync clock mode handling Jonathan Cameron
2021-01-25  9:16   ` Sa, Nuno
     [not found]     ` <20210131113557.0cba0496@archlinux>
2021-02-02  9:45       ` Sa, Nuno
2021-02-06 14:06         ` Jonathan Cameron
2021-01-26 12:13   ` Sa, Nuno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210121114954.64156-1-nuno.sa@analog.com \
    --to=nuno.sa@analog.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=alexandru.ardelean@analog.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).