[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <zkxaafrvyizbnxtuuj7jwh26jdat7tbvsnnxpnfz7fnmqjuycy@qqr6fzb46kvg>
Date: Mon, 14 Jul 2025 12:06:49 +0000
From: Sean Nyekjaer <sean@...nix.com>
To: remi.buisson@....com
Cc: Jonathan Cameron <jic23@...nel.org>, David Lechner <dlechner@...libre.com>, Nuno Sá <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 0/8] iio: imu: new inv_icm45600 driver
On Thu, Jul 10, 2025 at 08:57:55AM +0100, Remi Buisson via B4 Relay wrote:
> This series add a new driver for managing InvenSense ICM-456xx 6-axis IMUs.
> This next generation of chips includes new generations of 3-axis gyroscope
> and 3-axis accelerometer, support of I3C in addition to I2C and SPI, and
> intelligent MotionTracking features like pedometer, tilt detection, and
> tap detection.
>
> This series is delivering a driver supporting gyroscope, accelerometer and
> temperature data, with polling and buffering using hwfifo and watermark,
> on I2C, SPI and I3C busses.
>
> Gyroscope and accelerometer sensors are completely independent and can have
> different ODRs. Since there is only a single FIFO a specific value is used to
> mark invalid data. For keeping the device standard we are de-multiplexing data
> from the FIFO to 2 IIO devices with 2 buffers, 1 for the accelerometer and 1
> for the gyroscope. This architecture also enables to easily turn each sensor
> on/off without impacting the other. The device interrupt is used to read the
> FIFO and launch parsing of accelerometer and gyroscope data. This driver
> relies on the common Invensense timestamping mechanism to handle correctly
> FIFO watermark and dynamic changes of settings.
>
> The structure of the driver is quite similar to the inv_icm42600 driver,
> however there are significant reasons for adding a different driver for
> inv_icm45600, such as:
> - A completely different register map.
At one point we asked TDK/Invense for a driver for icm42670. It also
have a completely different register map... Grrr :S
Anyhow, should we combine these drivers in inv_icm42600? Like
st_lsm6dsx?
/Sean
> - Different FIFO management, based on number of samples instead of bytes.
> - Different indirect register access mechanism.
>
Powered by blists - more mailing lists