linux-toradex.git/include/linux/iio/common, branch v5.14-rc6

iio: accel: st_sensors: Support generic mounting matrix

2021-06-03T17:24:13+00:00

The ST accelerators support a special type of quirky mounting matrix found
in ACPI systems, but not a generic mounting matrix such as from the device
tree.

Augment the ACPI hack to be a bit more generic and accept a mounting
matrix from device properties.

This makes it possible to fix orientation on the Ux500 HREF device.

Cc: Hans de Goede 
Cc: Denis Ciocca 
Cc: Daniel Drake 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Stephan Gerhold 
Signed-off-by: Linus Walleij 
Reviewed-by: Hans de Goede 
Link: https://lore.kernel.org/r/20210518230722.522446-2-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron

iio: st_sensors: Create extended attr macro

2021-06-03T17:24:13+00:00

Extend ST_SENSORS_LSM_CHANNELS() to a version that will accept extended
attributes named ST_SENSORS_LSM_CHANNELS_EXT() and wrap the former as a
specialized version of the former.

Cc: Hans de Goede 
Cc: Denis Ciocca 
Cc: Daniel Drake 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Stephan Gerhold 
Signed-off-by: Linus Walleij 
Reviewed-by: Hans de Goede 
Link: https://lore.kernel.org/r/20210518230722.522446-1-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron

iio: cros_ec_sensors: Fix alignment of buffer in iio_push_to_buffers_with_timestamp()

2021-05-17T12:54:30+00:00

The samples buffer is passed to iio_push_to_buffers_with_timestamp()
which requires a buffer aligned to 8 bytes as it is assumed that
the timestamp will be naturally aligned if present.

Fixes tag is inaccurate but prior to that likely manual backporting needed
(for anything before 4.18) Earlier than that the include file to fix is
drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.h:
commit 974e6f02e27 ("iio: cros_ec_sensors_core: Add common functions
for the ChromeOS EC Sensor Hub.") present since kernel stable 4.10.
(Thanks to Gwendal for tracking this down)

Fixes: 5a0b8cb46624c ("iio: cros_ec: Move cros_ec_sensors_core.h in /include")
Signed-off-by: Jonathan Cameron 
Reviewed-by: Gwendal Grignou

iio: st_sensors: Add lsm9ds0 IMU support

2021-05-17T12:54:22+00:00

We can utilize separate drivers for accelerometer and magnetometer,
so here is the glue driver to enable LSM9DS0 IMU support.

The idea was suggested by Crestez Dan Leonard in [1]. The proposed change
was sent as RFC due to race condition concerns, which are indeed possible.

In order to amend the initial change, I went further by providing a specific
multi-instantiate probe driver that reuses existing accelerometer and
magnetometer.

[1]: https://lore.kernel.org/patchwork/patch/670353/

Suggested-by: Crestez Dan Leonard 
Cc: mr.lahorde@laposte.net
Cc: Matija Podravec 
Cc: Sergey Borishchenko 
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210414195454.84183-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron

iio: st_sensors: Make accel, gyro, magn and pressure probe shared

2021-05-17T12:54:22+00:00

Some IMUs may utilize existing library code for STMicro accelerometer,
gyroscope, magnetometer and pressure. Let's share them via st_sensors.h.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210414195454.84183-5-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron

iio: cros: unify hw fifo attributes without API changes

2021-03-25T19:13:52+00:00

Commit 2e2366c2d141 ("iio: cros_ec: unify hw fifo attributes into the core file")
should be reverted as it set buffer extended attributes at
the wrong place. However, to revert it will requires to revert more
commits:
commit 165aea80e2e2 ("iio: cros_ec: use devm_iio_triggered_buffer_setup_ext()")
commit 21232b4456ba ("iio: buffer: remove iio_buffer_set_attrs() helper")).
and we would still have conflict with more recent development.
commit ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers")

Instead, this commit reverts the first 2 commits without re-adding
iio_buffer_set_attrs() and set the buffer extended attributes at the
right place:

1. Instead of adding has_fw_fifo, deduct it from the configuration:
- EC must support FIFO (EC_FEATURE_MOTION_SENSE_FIFO) set.
- sensors send data a regular interval (accelerometer, gyro,
  magnetomer, barometer, light sensor).
- "Legacy accelerometer" is only present on EC without FIFO, so we don't
need to set buffer attributes.

2. devm_iio_triggered_buffer_setup_ext() does not need to be called when
EC does not support FIFO, as there is no FIFO to manage.

3. Use devm_iio_triggered_buffer_setup_ext() when EC has a FIFO to
specify the buffer extended attributes.

Fixes: 2e2366c2d141 ("iio: cros_ec: unify hw fifo attributes into the core file")
Fixes: 165aea80e2e2 ("iio: cros_ec: use devm_iio_triggered_buffer_setup_ext()")
Signed-off-by: Gwendal Grignou 
Reviewed-by: Alexandru Ardelean 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210318184857.2679181-1-gwendal@chromium.org
Signed-off-by: Jonathan Cameron

iio: cros_ec: unify hw fifo attributes into the core file

2020-09-29T16:27:07+00:00

The intent here is to minimize the use of iio_buffer_set_attrs(). Since we
are planning to add support for multiple IIO buffers per IIO device, the
issue has to do with:
1. Accessing 'indio_dev->buffer' directly (as is done with
   'iio_buffer_set_attrs(indio_dev->buffer, )').
2. The way that the buffer attributes would get handled or expanded when
   there are more buffers per IIO device. Current a sysfs kobj_type expands
   into a 'device' object that expands into an 'iio_dev' object.
   We will need to change this, so that the sysfs attributes for IIO
   buffers expand into IIO buffers at some point.

Right now, the current IIO framework works fine for the
'1 IIO device == 1 IIO buffer' case (that is now).

Signed-off-by: Alexandru Ardelean 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20200923130339.997902-1-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron

iio: cros_ec: Reapply range at resume

2020-06-14T10:49:41+00:00

EC does not currently preserve range across sensor reinit.
If sensor is powered down at suspend, it will default to the EC default
range at resume, not the range set by the host.

Save range if modified, and apply at resume.

Signed-off-by: Gwendal Grignou 
Signed-off-by: Jonathan Cameron

iio: cros_ec: Use Hertz as unit for sampling frequency

2020-03-30T06:24:49+00:00

To be compliant with other sensors, set and get sensor sampling
frequency in Hz, not mHz.

Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs")
Signed-off-by: Gwendal Grignou 
Acked-by: Jonathan Cameron 
Signed-off-by: Enric Balletbo i Serra

iio: cros_ec: Report hwfifo_watermark_max

2020-03-28T21:04:33+00:00

Report the maximum amount of sample the EC can hold.
This is not tunable, but can be useful for application to find out the
maximum amount of time it can sleep when hwfifo_timeout is set to a
large number.

Signed-off-by: Gwendal Grignou 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Enric Balletbo i Serra