Re: [PATCH v5 4/4] iio: imu: st_lsm6dsx: Add support for rotation sensor

[Francesco Lavra <flavra@baylibre.com>]

On Thu, 2026-01-22 at 20:29 +0000, Jonathan Cameron wrote:
> On Thu, 22 Jan 2026 17:23:35 +0100
> Francesco Lavra <flavra@baylibre.com> wrote:
> 
> > Some IMU chips in the LSM6DSX family have sensor fusion features that
> > combine data from the accelerometer and gyroscope. One of these
> > features
> > generates rotation vector data and makes it available in the hardware
> > FIFO as a quaternion (more specifically, the X, Y and Z components of
> > the
> > quaternion vector, expressed as 16-bit half-precision floating-point
> > numbers).
> > 
> > Add support for a new sensor instance that allows receiving sensor
> > fusion
> > data, by defining a new struct st_lsm6dsx_sf_settings (which contains
> > chip-specific details for the sensor fusion functionality), and adding
> > this
> > struct as a new field in struct st_lsm6dsx_settings. In
> > st_lsm6dsx_core.c,
> > populate this new struct for the LSM6DSV and LSM6DSV16X chips, and add
> > the
> > logic to initialize an additional IIO device if this struct is
> > populated
> > for the hardware type being probed.
> > Note: a new IIO device is being defined (as opposed to adding channels
> > to
> > an existing device) because the rate at which sensor fusion data is
> > generated may not match the data rate from any of the existing devices.
> > 
> > Tested on LSMDSV16X.
> > 
> > Signed-off-by: Francesco Lavra <flavra@baylibre.com>
> > Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> 
> > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> > b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> > index ded9a96076e6..3b4fa57bf461 100644
> > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> 
> > @@ -580,6 +584,16 @@ st_lsm6dsx_push_tagged_data(struct st_lsm6dsx_hw
> > *hw, u8 tag,
> >         case ST_LSM6DSX_EXT2_TAG:
> >                 iio_dev = hw->iio_devs[ST_LSM6DSX_ID_EXT2];
> >                 break;
> > +       case ST_LSM6DSX_ROT_TAG:
> > +               /*
> > +                * The sensor reports only the {X, Y, Z} elements of
> > the
> > +                * quaternion vector; set the W value to 0 (it can be
> > derived
> > +                * from the {X, Y, Z} values due to the property that
> > the vector
> > +                * is normalized).
> 
> I'd missed this before.  This is going to really confuse user space.
> I don't think we can just return it with a 0 in that last entry.
> At the very least we need an ABI doc update to reflect this oddity.
> 
> I don't think that is enough though. This isn't a quaternion, but
> rather something we can derive one from. Annoying though it is,
> we can't realistically fix it up in kernel, so we are probably talking
> a new MOD_TYPE.

Quaternion data read from the sensor is expressed in floating-point format,
and as such needs to be interpreted by userspace in a "non-standard" way
(note there is no scale in the channel info, and this is intentional
because we are not dealing with integers) regardless of whether the W value
is present or must be derived.
Isn't the absence of the scale info enough to let userspace know that this
data is non-standard? Only applications that know how to deal specifically
with this sensor device can make sense of the data (and these applications
know that the quaternion vector is normalized and the W value must be
derived from X, Y, Z).

> Also it's been a long time since I did much with quaternions,
> but isn't the sign of w ambiguous if we are relying on only X, Y and Z?
> A bit of googling + AI suggests flipping it inverts the direction of
> rotation around a given axis. Feels like there is a constraint missing
> in this description.

Flipping the sign of W doesn't just invert the direction of rotation, it
basically applies an offset of -360 degrees; if a value w0 indicates a
rotation by an angle theta0, the value -w0 indicates a rotation by (theta0
- 360), which is basically the same as rotating by theta0. So knowing the
{X, Y, Z} values is enough to have a non-ambiguous orientation.