The ADXL367 is an ultralow power, 3-axis MEMS accelerometer.
The ADXL367 does not alias input signals to achieve ultralow power
consumption, it samples the full bandwidth of the sensor at all
data rates. Measurement ranges of +-2g, +-4g, and +-8g are available,
with a resolution of 0.25mg/LSB on the +-2 g range.
In addition to its ultralow power consumption, the ADXL367
has many features to enable true system level power reduction.
It includes a deep multimode output FIFO, a built-in micropower
temperature sensor, and an internal ADC for synchronous conversion
of an additional analog input.
Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20220214073810.781016-6-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADXL367 is an ultralow power, 3-axis MEMS accelerometer.
The ADXL367 does not alias input signals to achieve ultralow power
consumption, it samples the full bandwidth of the sensor at all
data rates. Measurement ranges of +-2g, +-4g, and +-8g are available,
with a resolution of 0.25mg/LSB on the +-2 g range.
In addition to its ultralow power consumption, the ADXL367
has many features to enable true system level power reduction.
It includes a deep multimode output FIFO, a built-in micropower
temperature sensor, and an internal ADC for synchronous conversion
of an additional analog input.
Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220214073810.781016-5-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
It might be impossible to configure other attributes (e.g.: events, scale,
sampling rate) if they impact the currently active buffer capture session.
On ADXL367, writing to register before 0x2E requires the device to be
placed in standby mode, otherwise the changes might be effective for
only part of a measurement.
To ensure this requirement, the configuration attributes of the IIO
device try to claim direct mode before switching to standby mode.
During a buffer capture, direct mode cannot be claimed, and the
attribute write callback returns -EBUSY.
Describe this behavior in the buffer/enable attribute description.
Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20220214073810.781016-4-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some accelerometers that support activity and inactivity
events also support a referenced mode, in which the
gravitational acceleration is taken as a point of
reference before comparing the acceleration to the
specified activity and inactivity magnitude.
For example, in the case of the ADXL367, for activity
detection, the formula is:
abs(acceleration - reference) > magnitude
Add a new event type that makes this behavior clear.
Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20220214073810.781016-3-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some accelerometers that support activity and inactivity
events also support a referenced mode, in which the
gravitational acceleration is taken as a point of
reference before comparing the acceleration to the
specified activity and inactivity magnitude.
For example, in the case of the ADXL367, for activity
detection, the formula is:
abs(acceleration - reference) > magnitude
Add a new event type that makes this behavior clear.
Signed-off-by: Cosmin Tanislav <cosmin.tanislav@analog.com>
Link: https://lore.kernel.org/r/20220214073810.781016-2-cosmin.tanislav@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This functionality is intended to allow for a few temperature
sensors to be missing (and hence not worth reading) on the final
device in a chain. The ones removed are 3 and 5 (unlike for
the ADC channels where it is 4 and 5).
The datasheet includes a foot note 3 to Table 12 that makes this complex
to support.
"(3) To remove AUX5 or AUX5 and AUX3 from the alert detection, conversions
on three auxiliary ADC input channels only must be selected in the
control register."
This mode has never been supported by the driver.
As this support would be complex to add and the rework is being done
against a QEMU model developed for the purposes of verifying nothing
is broken, it is better to drop this support for now.
Reported-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Link: https://lore.kernel.org/r/20220206190328.333093-16-jic23@kernel.org
This driver had a slightly non standard events ABI but there seems
to be no reason for not doing it with the core support for rising and
falling events on the two types of channels.
In theory the events on different daisy chained chips could be at
different levels, but the driver has never supported this and it doesn't
seem likely to be used so let us ignore that option.
Includes reordering so that we only set the software cached value
of the thresholds if the hardware write succeeds.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Link: https://lore.kernel.org/r/20220206190328.333093-7-jic23@kernel.org
1. Postfix register addresses with _REG to distinguish them from
fields within the registers
2. Switch to using FIELD_PREP and masks to aid readability.
3. Shorten a few defines to make the lines remain a sensible length.
4. Fix an issue whether where an CTRL_LB field is set in CTRL_HB.
5. Fix wrong AUX1_3_4 which should be AUX_1_3_5 according to
table 14 in the datasheet.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Link: https://lore.kernel.org/r/20220206190328.333093-3-jic23@kernel.org
The bit reversal was wrong for bits 1 and 3 of the 5 bits.
Result is driver failure to probe if you have more than 2 daisy-chained
devices. Discovered via QEMU based device emulation.
Fixes tag is for when this moved from a macro to a function, but it
was broken before that.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fixes: 065a7c0b1f ("Staging: iio: adc: ad7280a.c: Fixed Macro argument reuse")
Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Link: https://lore.kernel.org/r/20220206190328.333093-2-jic23@kernel.org
The combinations of either
* pm_sleep_ptr() and DEFINE_SIMPLE_DEV_PM_OPS()
* pm_ptr() and RUNTIME_PM_OPS()/SYSTEM_SLEEP_PM_OPS
Make sure the functions are always visible to the compiler and removed by
it rather than requring #ifdef magic.
This removes the need to mark the functions as __maybe_unused and saves
additional space with some build options as the dev_pm_ops structure
itself can be dropped automatically if CONFIG_PM is not enabled.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Olivier Moysan <olivier.moysan@st.com>
Cc: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Reviewed-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-51-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
Use the new DEFINE_RUNTIME_DEV_PM_OPS to reduce boilerplate.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-47-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM support is simpler and less error prone than the
use of #ifdef based config guards.
This case uses the new DEFINE_RUNTIME_DEV_PM_OPS() to reduce
boilerplate.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-44-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without one or more of CONFIG_PM/CONFIG_PM_SLEEP support is simpler and
less error prone than the use of #ifdef based config guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-42-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards.
Note that in this case the storage for saving state was protected
by CONFIG_PM guards. The storage is very small and unlikely to make
any real difference to the space allocated for state so just drop
those guards.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-41-jic23@kernel.org
Letting the compiler remove these functions when the kernel is built
without CONFIG_PM_SLEEP support is simpler and less error prone than the
use of #ifdef based config guards. Also use SIMPLE_DEV_PM_OPS instead
of open-coding the equivalent.
Removing instances of this approach from IIO also stops them being
copied into new drivers.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20220130193147.279148-32-jic23@kernel.org
