All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Remi Buisson via B4 Relay <devnull+remi.buisson.tdk.com@kernel.org>
Cc: remi.buisson@tdk.com, "David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v5 3/9] iio: imu: inv_icm45600: add buffer support in iio devices
Date: Mon, 25 Aug 2025 11:42:05 +0100	[thread overview]
Message-ID: <20250825114205.65ec79bc@jic23-huawei> (raw)
In-Reply-To: <20250820-add_newport_driver-v5-3-2fc9f13dddee@tdk.com>

On Wed, 20 Aug 2025 14:24:21 +0000
Remi Buisson via B4 Relay <devnull+remi.buisson.tdk.com@kernel.org> wrote:

> From: Remi Buisson <remi.buisson@tdk.com>
> 
> Add FIFO control functions.
> Support hwfifo watermark by multiplexing gyro and accel settings.
> Support hwfifo flush.
> 
> Signed-off-by: Remi Buisson <remi.buisson@tdk.com>

A few really minor things inline.

> diff --git a/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..50fd21a24e34decfbe10426946a51c61353eb6a9
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.c

> +
> +/**
> + * inv_icm45600_buffer_update_watermark - update watermark FIFO threshold
> + * @st:	driver internal state
> + *
> + * Returns 0 on success, a negative error code otherwise.
> + *
> + * FIFO watermark threshold is computed based on the required watermark values
> + * set for gyro and accel sensors. Since watermark is all about acceptable data
> + * latency, use the smallest setting between the 2. It means choosing the
> + * smallest latency but this is not as simple as choosing the smallest watermark
> + * value. Latency depends on watermark and ODR. It requires several steps:
> + * 1) compute gyro and accel latencies and choose the smallest value.
> + * 2) adapt the chosen latency so that it is a multiple of both gyro and accel
> + *    ones. Otherwise it is possible that you don't meet a requirement. (for
> + *    example with gyro @100Hz wm 4 and accel @100Hz with wm 6, choosing the
> + *    value of 4 will not meet accel latency requirement because 6 is not a
> + *    multiple of 4. You need to use the value 2.)
> + * 3) Since all periods are multiple of each others, watermark is computed by
> + *    dividing this computed latency by the smallest period, which corresponds
> + *    to the FIFO frequency.
> + */
> +int inv_icm45600_buffer_update_watermark(struct inv_icm45600_state *st)
> +{
> +	const size_t packet_size = sizeof(struct inv_icm45600_fifo_2sensors_packet);
> +	unsigned int wm_gyro, wm_accel, watermark;
> +	u32 period_gyro, period_accel, period;
> +	u32 latency_gyro, latency_accel, latency;
> +
> +	/* Compute sensors latency, depending on sensor watermark and odr. */
> +	wm_gyro = inv_icm45600_wm_truncate(st->fifo.watermark.gyro, packet_size,
> +					   st->fifo.period);
> +	wm_accel = inv_icm45600_wm_truncate(st->fifo.watermark.accel, packet_size,
> +					    st->fifo.period);
> +	/* Use us for odr to avoid overflow using 32 bits values. */
> +	period_gyro = inv_icm45600_odr_to_period(st->conf.gyro.odr) / 1000UL;
> +	period_accel = inv_icm45600_odr_to_period(st->conf.accel.odr) / 1000UL;
> +	latency_gyro = period_gyro * wm_gyro;
> +	latency_accel = period_accel * wm_accel;
> +
> +	/* 0 value for watermark means that the sensor is turned off. */
> +	if (wm_gyro == 0 && wm_accel == 0)
> +		return 0;
> +
> +	if (latency_gyro == 0) {
> +		watermark = wm_accel;
> +		st->fifo.watermark.eff_accel = wm_accel;
> +	} else if (latency_accel == 0) {
> +		watermark = wm_gyro;
> +		st->fifo.watermark.eff_gyro = wm_gyro;
> +	} else {
> +		/* Compute the smallest latency that is a multiple of both. */
> +		if (latency_gyro <= latency_accel)
> +			latency = latency_gyro - (latency_accel % latency_gyro);
> +		else
> +			latency = latency_accel - (latency_gyro % latency_accel);
> +		/* Use the shortest period. */
> +		period = min(period_gyro, period_accel);
> +		/* All this works because periods are multiple of each others. */
> +		watermark = max(latency / period, 1);
> +		/* Update effective watermark. */
> +		st->fifo.watermark.eff_gyro = max(latency / period_gyro, 1);
> +		st->fifo.watermark.eff_accel = max(latency / period_accel, 1);
> +	}
> +

1 blank line is enough.

> +
> +	st->buffer.u16 = cpu_to_le16(watermark);
> +	return regmap_bulk_write(st->map, INV_ICM45600_REG_FIFO_WATERMARK,
> +				 &st->buffer.u16, sizeof(st->buffer.u16));
> +}
>
> diff --git a/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.h b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.h
> new file mode 100644
> index 0000000000000000000000000000000000000000..da463461b5f2708014126f868fa6008db0520a4e
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm45600/inv_icm45600_buffer.h


> +
> +static inline s16 inv_icm45600_fifo_get_sensor_data(__le16 d)
> +{
> +	return le16_to_cpu(d);
I'm not really seeing advantage of this wrapper vs just using le16_to_cpu()
inline.

> +}
> +
> +static inline bool
> +inv_icm45600_fifo_is_data_valid(const struct inv_icm45600_fifo_sensor_data *s)
> +{
> +	s16 x, y, z;
> +
> +	x = inv_icm45600_fifo_get_sensor_data(s->x);
> +	y = inv_icm45600_fifo_get_sensor_data(s->y);
> +	z = inv_icm45600_fifo_get_sensor_data(s->z);
	x = le16_to_cpu(s->x);

is pretty obvious.

> +
> +	if (x == INV_ICM45600_DATA_INVALID &&
> +	    y == INV_ICM45600_DATA_INVALID &&
> +	    z == INV_ICM45600_DATA_INVALID)
> +		return false;
> +
> +	return true;
> +}



  parent reply	other threads:[~2025-08-25 10:42 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-20 14:24 [PATCH v5 0/9] iio: imu: new inv_icm45600 driver Remi Buisson
2025-08-20 14:24 ` Remi Buisson via B4 Relay
2025-08-20 14:24 ` [PATCH v5 1/9] dt-bindings: iio: imu: Add inv_icm45600 Remi Buisson
2025-08-20 14:24   ` Remi Buisson via B4 Relay
2025-08-20 19:33   ` Conor Dooley
2025-08-20 14:24 ` [PATCH v5 2/9] iio: imu: inv_icm45600: add new inv_icm45600 driver Remi Buisson
2025-08-20 14:24   ` Remi Buisson via B4 Relay
2025-08-21  9:02   ` Andy Shevchenko
2025-09-04 12:58     ` Remi Buisson
2025-09-04 13:17       ` Andy Shevchenko
2025-09-05 12:43         ` Remi Buisson
2025-09-05 13:47           ` Andy Shevchenko
2025-08-25 10:34   ` Jonathan Cameron
2025-09-04 13:04     ` Remi Buisson
2025-09-07 13:31       ` Jonathan Cameron
2025-08-20 14:24 ` [PATCH v5 3/9] iio: imu: inv_icm45600: add buffer support in iio devices Remi Buisson
2025-08-20 14:24   ` Remi Buisson via B4 Relay
2025-08-21  9:20   ` Andy Shevchenko
2025-09-04 13:01     ` Remi Buisson
2025-09-04 13:49       ` Andy Shevchenko
2025-09-05 12:44         ` Remi Buisson
2025-09-05 13:49           ` Andy Shevchenko
2025-09-07 13:34           ` Jonathan Cameron
2025-09-22  8:52           ` Remi Buisson
2025-08-25 10:42   ` Jonathan Cameron [this message]
2025-09-04 13:05     ` Remi Buisson
2025-08-20 14:24 ` [PATCH v5 4/9] iio: imu: inv_icm45600: add IMU IIO gyroscope device Remi Buisson
2025-08-20 14:24   ` Remi Buisson via B4 Relay
2025-08-25 10:55   ` Jonathan Cameron
2025-09-04 13:06     ` Remi Buisson
2025-08-20 14:24 ` [PATCH v5 5/9] iio: imu: inv_icm45600: add IMU IIO accelerometer device Remi Buisson
2025-08-20 14:24   ` Remi Buisson via B4 Relay
2025-08-20 14:24 ` [PATCH v5 6/9] iio: imu: inv_icm45600: add I2C driver for inv_icm45600 driver Remi Buisson
2025-08-20 14:24   ` Remi Buisson via B4 Relay
2025-08-20 14:24 ` [PATCH v5 7/9] iio: imu: inv_icm45600: add SPI " Remi Buisson
2025-08-20 14:24   ` Remi Buisson via B4 Relay
2025-08-20 14:24 ` [PATCH v5 8/9] iio: imu: inv_icm45600: add I3C " Remi Buisson
2025-08-20 14:24   ` Remi Buisson via B4 Relay
2025-08-20 14:24 ` [PATCH v5 9/9] MAINTAINERS: add entry for inv_icm45600 6-axis imu sensor Remi Buisson
2025-08-20 14:24   ` Remi Buisson via B4 Relay

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=20250825114205.65ec79bc@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=devnull+remi.buisson.tdk.com@kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=remi.buisson@tdk.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.