linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Ramona Gradinariu <ramona.bolboaca13@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	linux-doc@vger.kernel.org, devicetree@vger.kernel.org,
	corbet@lwn.net, conor+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, robh@kernel.org,
	Ramona Gradinariu <ramona.gradinariu@analog.com>
Subject: Re: [PATCH 2/5] iio: imu: adis16480.c: Add delta angle and delta velocity channels
Date: Sun, 28 Apr 2024 16:04:38 +0100	[thread overview]
Message-ID: <20240428160438.424e33d2@jic23-huawei> (raw)
In-Reply-To: <20240423084210.191987-3-ramona.gradinariu@analog.com>

On Tue, 23 Apr 2024 11:42:07 +0300
Ramona Gradinariu <ramona.bolboaca13@gmail.com> wrote:

> Add support for delta angle and delta velocity raw readings to
> adis16480 driver.

Why are these not allowed via the buffer interface?   Normally
my expectation of delta values is they are more or less useless
without buffered capture. The intent of providing those channels
is that they are gathered over time and summed up to give the
angle difference (for example) between start of capture and now.
Note the formula on the datasheet 
https://www.analog.com/media/en/technical-documentation/data-sheets/adis16545-16547.pdf
looks wrong (formula 3) as it's adding the signals at time
nD + d and at nD + D - 1 whereas for a delta you'd subtract those
(maybe I'm reading that wrong).

If we are providing these values as raw readings I'd expect them
to be presented as delta_angle / time (e.g. rate of change of angle) and
delta_velocity / time = acceleration (be it slightly distorted vs
the acceleration measured as a result of oversampling.).
So basically spot measurements of delta values are normally pretty
useless.

My guess is that you did this because the device either seems
to allow burst reads of the main channels or of these delta
values?

If so consider using available_scan_masks to allow one or the
other set of channels rather than not allowing capture of these
via the buffered interfaces.

Jonathan



> 
> Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
> ---
>  drivers/iio/imu/adis16480.c | 78 ++++++++++++++++++++++++++++++++++++-
>  1 file changed, 76 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/imu/adis16480.c b/drivers/iio/imu/adis16480.c
> index bc6cbd00cd4b..4adc2244a4ef 100644
> --- a/drivers/iio/imu/adis16480.c
> +++ b/drivers/iio/imu/adis16480.c
> @@ -140,6 +140,8 @@ struct adis16480_chip_info {
>  	unsigned int accel_max_val;
>  	unsigned int accel_max_scale;
>  	unsigned int temp_scale;
> +	unsigned int deltang_max_val;
> +	unsigned int deltvel_max_val;
>  	unsigned int int_clk;
>  	unsigned int max_dec_rate;
>  	const unsigned int *filter_freqs;
> @@ -445,6 +447,12 @@ enum {
>  	ADIS16480_SCAN_MAGN_Z,
>  	ADIS16480_SCAN_BARO,
>  	ADIS16480_SCAN_TEMP,
> +	ADIS16480_SCAN_DELTANG_X,
> +	ADIS16480_SCAN_DELTANG_Y,
> +	ADIS16480_SCAN_DELTANG_Z,
> +	ADIS16480_SCAN_DELTVEL_X,
> +	ADIS16480_SCAN_DELTVEL_Y,
> +	ADIS16480_SCAN_DELTVEL_Z,
>  };
>  
>  static const unsigned int adis16480_calibbias_regs[] = {
> @@ -688,6 +696,14 @@ static int adis16480_read_raw(struct iio_dev *indio_dev,
>  			*val = 131; /* 1310mbar = 131 kPa */
>  			*val2 = 32767 << 16;
>  			return IIO_VAL_FRACTIONAL;
> +		case IIO_DELTA_ANGL:
> +			*val = st->chip_info->deltang_max_val;
> +			*val2 = 31;
> +			return IIO_VAL_FRACTIONAL_LOG2;
> +		case IIO_DELTA_VELOCITY:
> +			*val = st->chip_info->deltvel_max_val;
> +			*val2 = 31;
> +			return IIO_VAL_FRACTIONAL_LOG2;
>  		default:
>  			return -EINVAL;
>  		}
> @@ -761,6 +777,30 @@ static int adis16480_write_raw(struct iio_dev *indio_dev,
>  	BIT(IIO_CHAN_INFO_CALIBSCALE), \
>  	32)
>  
> +#define ADIS16480_DELTANG_CHANNEL(_mod) \
> +	ADIS16480_MOD_CHANNEL(IIO_DELTA_ANGL, IIO_MOD_ ## _mod, \
> +	ADIS16480_REG_ ## _mod ## _DELTAANG_OUT, ADIS16480_SCAN_DELTANG_ ## _mod, \
> +	0, \

Trivial but why this line wrap?  I'd push 32 onto the line above at least.

> +	32)
> +
> +#define ADIS16480_DELTANG_CHANNEL_NO_SCAN(_mod) \
> +	ADIS16480_MOD_CHANNEL(IIO_DELTA_ANGL, IIO_MOD_ ## _mod, \
> +	ADIS16480_REG_ ## _mod ## _DELTAANG_OUT, -1, \
> +	0, \
> +	32)
> +
> +#define ADIS16480_DELTVEL_CHANNEL(_mod) \
> +	ADIS16480_MOD_CHANNEL(IIO_DELTA_VELOCITY, IIO_MOD_ ## _mod, \
> +	ADIS16480_REG_ ## _mod ## _DELTAVEL_OUT, ADIS16480_SCAN_DELTVEL_ ## _mod, \
> +	0, \
> +	32)
> +
> +#define ADIS16480_DELTVEL_CHANNEL_NO_SCAN(_mod) \
> +	ADIS16480_MOD_CHANNEL(IIO_DELTA_VELOCITY, IIO_MOD_ ## _mod, \
> +	ADIS16480_REG_ ## _mod ## _DELTAVEL_OUT, -1, \
> +	0, \
> +	32)


  reply	other threads:[~2024-04-28 15:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-23  8:42 [PATCH 0/5] Add support for adis16545/47 Ramona Gradinariu
2024-04-23  8:42 ` [PATCH 1/5] iio: adis16480: make the burst_max_speed configurable Ramona Gradinariu
2024-04-23  8:42 ` [PATCH 2/5] iio: imu: adis16480.c: Add delta angle and delta velocity channels Ramona Gradinariu
2024-04-28 15:04   ` Jonathan Cameron [this message]
2024-04-28 15:07     ` Jonathan Cameron
2024-04-23  8:42 ` [PATCH 3/5] dt-bindings: iio: imu: Add docs for ADIS16545/47 Ramona Gradinariu
2024-04-23  9:45   ` Krzysztof Kozlowski
2024-04-23  8:42 ` [PATCH 4/5] iio: adis16480: add support for adis16545/7 families Ramona Gradinariu
2024-04-28 15:25   ` Jonathan Cameron
2024-04-29  7:58     ` Nuno Sá
2024-04-29 13:17       ` Gradinariu, Ramona
2024-04-29 19:40         ` Jonathan Cameron
2024-05-02 11:31           ` Nuno Sá
2024-05-02 19:14             ` Jonathan Cameron
2024-05-03  6:09               ` Nuno Sá
2024-05-03  8:42                 ` Jonathan Cameron
2024-05-03  9:07                   ` Nuno Sá
2024-04-29  8:01     ` Nuno Sá
2024-04-23  8:42 ` [PATCH 5/5] docs: iio: add documentation for adis16480 driver Ramona Gradinariu
2024-04-28 15:33   ` Jonathan Cameron

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=20240428160438.424e33d2@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ramona.bolboaca13@gmail.com \
    --cc=ramona.gradinariu@analog.com \
    --cc=robh@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).