In sensor variants (such as ADXL380 and ADXL382) that support low-power
mode, the SAR signal path allows sampling acceleration data at lower rates;
more specifically, when the sensor operates in VLP mode, the sampling
frequency is 1 kHz.
To add support for the 1kHz sampling frequency value, modify the operating
mode selection logic to take into account the sampling frequency, and
configure the decimation filters only when applicable (i.e. when using a
sampling frequency that relies on the DSM signal path).
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
---
drivers/iio/accel/adxl380.c | 49 +++++++++++++++++++++++--------------
drivers/iio/accel/adxl380.h | 10 +++++++-
2 files changed, 40 insertions(+), 19 deletions(-)
diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
index bbf1f88ca781..a6919dfce2e9 100644
--- a/drivers/iio/accel/adxl380.c
+++ b/drivers/iio/accel/adxl380.c
@@ -245,12 +245,14 @@ static int adxl380_set_measure_en(struct adxl380_state *st, bool en)
/*
* Activity/Inactivity detection available only in VLP/ULP
- * mode and for devices that support low power modes. Otherwise
- * go straight to measure mode (same bits as ADXL380_OP_MODE_HP).
+ * mode and for devices that support low power modes.
*/
if (st->chip_info->has_low_power &&
(FIELD_GET(ADXL380_ACT_EN_MSK, act_inact_ctl) ||
FIELD_GET(ADXL380_INACT_EN_MSK, act_inact_ctl)))
+ st->odr = ADXL380_ODR_VLP;
+
+ if (st->odr == ADXL380_ODR_VLP)
op_mode = ADXL380_OP_MODE_VLP;
else
op_mode = ADXL380_OP_MODE_HP;
@@ -478,17 +480,22 @@ static int adxl380_set_odr(struct adxl380_state *st, u8 odr)
if (ret)
return ret;
- ret = regmap_update_bits(st->regmap, ADXL380_TRIG_CFG_REG,
- ADXL380_TRIG_CFG_DEC_2X_MSK,
- FIELD_PREP(ADXL380_TRIG_CFG_DEC_2X_MSK, odr & 1));
- if (ret)
- return ret;
+ if (odr >= ADXL380_ODR_DSM) {
+ u8 mul = odr - ADXL380_ODR_DSM;
+ u8 field;
- ret = regmap_update_bits(st->regmap, ADXL380_TRIG_CFG_REG,
- ADXL380_TRIG_CFG_SINC_RATE_MSK,
- FIELD_PREP(ADXL380_TRIG_CFG_SINC_RATE_MSK, odr >> 1));
- if (ret)
- return ret;
+ field = FIELD_PREP(ADXL380_TRIG_CFG_DEC_2X_MSK, mul & 1);
+ ret = regmap_update_bits(st->regmap, ADXL380_TRIG_CFG_REG,
+ ADXL380_TRIG_CFG_DEC_2X_MSK, field);
+ if (ret)
+ return ret;
+
+ field = FIELD_PREP(ADXL380_TRIG_CFG_SINC_RATE_MSK, mul >> 1);
+ ret = regmap_update_bits(st->regmap, ADXL380_TRIG_CFG_REG,
+ ADXL380_TRIG_CFG_SINC_RATE_MSK, field);
+ if (ret)
+ return ret;
+ }
st->odr = odr;
ret = adxl380_set_measure_en(st, true);
@@ -1219,9 +1226,14 @@ static int adxl380_read_avail(struct iio_dev *indio_dev,
*length = ARRAY_SIZE(st->chip_info->scale_tbl) * 2;
return IIO_AVAIL_LIST;
case IIO_CHAN_INFO_SAMP_FREQ:
- *vals = (const int *)st->chip_info->samp_freq_tbl;
+ if (st->chip_info->has_low_power) {
+ *vals = st->chip_info->samp_freq_tbl;
+ *length = ADXL380_ODR_MAX;
+ } else {
+ *vals = st->chip_info->samp_freq_tbl + ADXL380_ODR_DSM;
+ *length = ADXL380_ODR_MAX - ADXL380_ODR_DSM;
+ }
*type = IIO_VAL_INT;
- *length = ARRAY_SIZE(st->chip_info->samp_freq_tbl);
return IIO_AVAIL_LIST;
case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
*vals = (const int *)st->lpf_tbl;
@@ -1611,7 +1623,7 @@ const struct adxl380_chip_info adxl318_chip_info = {
[ADXL380_OP_MODE_8G_RANGE] = { 0, 2615434 },
[ADXL380_OP_MODE_16G_RANGE] = { 0, 5229886 },
},
- .samp_freq_tbl = { 8000, 16000, 32000 },
+ .samp_freq_tbl = { 0, 8000, 16000, 32000 },
/*
* The datasheet defines an intercept of 550 LSB at 25 degC
* and a sensitivity of 10.2 LSB/C.
@@ -1629,7 +1641,7 @@ const struct adxl380_chip_info adxl319_chip_info = {
[ADXL382_OP_MODE_30G_RANGE] = { 0, 9806650 },
[ADXL382_OP_MODE_60G_RANGE] = { 0, 19613300 },
},
- .samp_freq_tbl = { 16000, 32000, 64000 },
+ .samp_freq_tbl = { 0, 16000, 32000, 64000 },
/*
* The datasheet defines an intercept of 550 LSB at 25 degC
* and a sensitivity of 10.2 LSB/C.
@@ -1647,7 +1659,7 @@ const struct adxl380_chip_info adxl380_chip_info = {
[ADXL380_OP_MODE_8G_RANGE] = { 0, 2615434 },
[ADXL380_OP_MODE_16G_RANGE] = { 0, 5229886 },
},
- .samp_freq_tbl = { 8000, 16000, 32000 },
+ .samp_freq_tbl = { 1000, 8000, 16000, 32000 },
/*
* The datasheet defines an intercept of 470 LSB at 25 degC
* and a sensitivity of 10.2 LSB/C.
@@ -1667,7 +1679,7 @@ const struct adxl380_chip_info adxl382_chip_info = {
[ADXL382_OP_MODE_30G_RANGE] = { 0, 9806650 },
[ADXL382_OP_MODE_60G_RANGE] = { 0, 19613300 },
},
- .samp_freq_tbl = { 16000, 32000, 64000 },
+ .samp_freq_tbl = { 1000, 16000, 32000, 64000 },
/*
* The datasheet defines an intercept of 570 LSB at 25 degC
* and a sensitivity of 10.2 LSB/C.
@@ -1906,6 +1918,7 @@ int adxl380_probe(struct device *dev, struct regmap *regmap,
st->dev = dev;
st->regmap = regmap;
st->chip_info = chip_info;
+ st->odr = ADXL380_ODR_DSM;
mutex_init(&st->lock);
diff --git a/drivers/iio/accel/adxl380.h b/drivers/iio/accel/adxl380.h
index e67c5aab8efc..d2c260c8b2fa 100644
--- a/drivers/iio/accel/adxl380.h
+++ b/drivers/iio/accel/adxl380.h
@@ -8,10 +8,18 @@
#ifndef _ADXL380_H_
#define _ADXL380_H_
+enum adxl380_odr {
+ ADXL380_ODR_VLP,
+ ADXL380_ODR_DSM,
+ ADXL380_ODR_DSM_2X,
+ ADXL380_ODR_DSM_4X,
+ ADXL380_ODR_MAX
+};
+
struct adxl380_chip_info {
const char *name;
const int scale_tbl[3][2];
- const int samp_freq_tbl[3];
+ const int samp_freq_tbl[ADXL380_ODR_MAX];
const struct iio_info *info;
const int temp_offset;
const u16 chip_id;
--
2.39.5Hi Francesco, On Wed, 2026-01-07 at 13:35 +0100, Francesco Lavra wrote: > In sensor variants (such as ADXL380 and ADXL382) that support low-power > mode, the SAR signal path allows sampling acceleration data at lower rates; > more specifically, when the sensor operates in VLP mode, the sampling > frequency is 1 kHz. > To add support for the 1kHz sampling frequency value, modify the operating > mode selection logic to take into account the sampling frequency, and > configure the decimation filters only when applicable (i.e. when using a > sampling frequency that relies on the DSM signal path). > > Signed-off-by: Francesco Lavra <flavra@baylibre.com> > --- > drivers/iio/accel/adxl380.c | 49 +++++++++++++++++++++++-------------- > drivers/iio/accel/adxl380.h | 10 +++++++- > 2 files changed, 40 insertions(+), 19 deletions(-) > > diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c > index bbf1f88ca781..a6919dfce2e9 100644 > --- a/drivers/iio/accel/adxl380.c > +++ b/drivers/iio/accel/adxl380.c > @@ -245,12 +245,14 @@ static int adxl380_set_measure_en(struct adxl380_state *st, bool en) > > /* > * Activity/Inactivity detection available only in VLP/ULP > - * mode and for devices that support low power modes. Otherwise > - * go straight to measure mode (same bits as ADXL380_OP_MODE_HP). > + * mode and for devices that support low power modes. > */ > if (st->chip_info->has_low_power && > (FIELD_GET(ADXL380_ACT_EN_MSK, act_inact_ctl) || > FIELD_GET(ADXL380_INACT_EN_MSK, act_inact_ctl))) > + st->odr = ADXL380_ODR_VLP; > + So before this change we would go to low power mode but still report whatever sampling frequency userspace had configured (which I guess would not correspond to reality)? With the above we'll update the reported odr right? Some things/doubts that come to mind: 1. If I'm right not sure if this shouldn't be treated as a fix. 2. Should we cache the current odr so that we restore it when appropriate? 3. Other thing that comes to mind is if it makes sense to allow controlling odr if Activity/Inactivity detection is enabled? Thx! - Nuno Sá
On Wed, 2026-01-07 at 13:56 +0000, Nuno Sá wrote: > Hi Francesco, > > On Wed, 2026-01-07 at 13:35 +0100, Francesco Lavra wrote: > > In sensor variants (such as ADXL380 and ADXL382) that support low-power > > mode, the SAR signal path allows sampling acceleration data at lower > > rates; > > more specifically, when the sensor operates in VLP mode, the sampling > > frequency is 1 kHz. > > To add support for the 1kHz sampling frequency value, modify the > > operating > > mode selection logic to take into account the sampling frequency, and > > configure the decimation filters only when applicable (i.e. when using > > a > > sampling frequency that relies on the DSM signal path). > > > > Signed-off-by: Francesco Lavra <flavra@baylibre.com> > > --- > > drivers/iio/accel/adxl380.c | 49 +++++++++++++++++++++++-------------- > > drivers/iio/accel/adxl380.h | 10 +++++++- > > 2 files changed, 40 insertions(+), 19 deletions(-) > > > > diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c > > index bbf1f88ca781..a6919dfce2e9 100644 > > --- a/drivers/iio/accel/adxl380.c > > +++ b/drivers/iio/accel/adxl380.c > > @@ -245,12 +245,14 @@ static int adxl380_set_measure_en(struct > > adxl380_state *st, bool en) > > > > /* > > * Activity/Inactivity detection available only in > > VLP/ULP > > - * mode and for devices that support low power modes. > > Otherwise > > - * go straight to measure mode (same bits as > > ADXL380_OP_MODE_HP). > > + * mode and for devices that support low power modes. > > */ > > if (st->chip_info->has_low_power && > > (FIELD_GET(ADXL380_ACT_EN_MSK, act_inact_ctl) || > > FIELD_GET(ADXL380_INACT_EN_MSK, act_inact_ctl))) > > + st->odr = ADXL380_ODR_VLP; > > + > > So before this change we would go to low power mode but still report > whatever sampling frequency > userspace had configured (which I guess would not correspond to reality)? Correct. > With the above we'll > update the reported odr right? Right. > Some things/doubts that come to mind: > > 1. If I'm right not sure if this shouldn't be treated as a fix. Yes, this technically fixes an existing issue, but I didn't advertise it as a fix because solving the issue requires adding support for the 1kHz frequency, which seems to go beyond the strict definition of a fix and sounds more like a new feature. > 2. Should we cache the current odr so that we restore it when > appropriate? Do you mean caching it when activity detection is enabled and restoring it when detection is disabled? It could be done. > 3. Other thing that comes to mind is if it makes sense to allow > controlling odr if > Activity/Inactivity detection is enabled? Disallowing odr control when activity detection is enabled could be an option, but what error code should be returned if the user tries to set the sampling frequency value when not allowed? -EBUSY? > > Thx! > - Nuno Sá >
On Wed, 2026-01-07 at 16:39 +0100, Francesco Lavra wrote: > On Wed, 2026-01-07 at 13:56 +0000, Nuno Sá wrote: > > Hi Francesco, > > > > On Wed, 2026-01-07 at 13:35 +0100, Francesco Lavra wrote: > > > In sensor variants (such as ADXL380 and ADXL382) that support low-power > > > mode, the SAR signal path allows sampling acceleration data at lower > > > rates; > > > more specifically, when the sensor operates in VLP mode, the sampling > > > frequency is 1 kHz. > > > To add support for the 1kHz sampling frequency value, modify the > > > operating > > > mode selection logic to take into account the sampling frequency, and > > > configure the decimation filters only when applicable (i.e. when using > > > a > > > sampling frequency that relies on the DSM signal path). > > > > > > Signed-off-by: Francesco Lavra <flavra@baylibre.com> > > > --- > > > drivers/iio/accel/adxl380.c | 49 +++++++++++++++++++++++-------------- > > > drivers/iio/accel/adxl380.h | 10 +++++++- > > > 2 files changed, 40 insertions(+), 19 deletions(-) > > > > > > diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c > > > index bbf1f88ca781..a6919dfce2e9 100644 > > > --- a/drivers/iio/accel/adxl380.c > > > +++ b/drivers/iio/accel/adxl380.c > > > @@ -245,12 +245,14 @@ static int adxl380_set_measure_en(struct > > > adxl380_state *st, bool en) > > > > > > /* > > > * Activity/Inactivity detection available only in > > > VLP/ULP > > > - * mode and for devices that support low power modes. > > > Otherwise > > > - * go straight to measure mode (same bits as > > > ADXL380_OP_MODE_HP). > > > + * mode and for devices that support low power modes. > > > */ > > > if (st->chip_info->has_low_power && > > > (FIELD_GET(ADXL380_ACT_EN_MSK, act_inact_ctl) || > > > FIELD_GET(ADXL380_INACT_EN_MSK, act_inact_ctl))) > > > + st->odr = ADXL380_ODR_VLP; > > > + > > > > So before this change we would go to low power mode but still report > > whatever sampling frequency > > userspace had configured (which I guess would not correspond to reality)? > > Correct. > > > With the above we'll > > update the reported odr right? > > Right. > > > Some things/doubts that come to mind: > > > > 1. If I'm right not sure if this shouldn't be treated as a fix. > > Yes, this technically fixes an existing issue, but I didn't advertise it as > a fix because solving the issue requires adding support for the 1kHz > frequency, which seems to go beyond the strict definition of a fix and > sounds more like a new feature. > > > 2. Should we cache the current odr so that we restore it when > > appropriate? > > Do you mean caching it when activity detection is enabled and restoring it > when detection is disabled? It could be done. > Just and idea. I think it makes sense since enabling activity detection will change things under the hood and some users might not realize it. But it is not super important I guess. > > 3. Other thing that comes to mind is if it makes sense to allow > > controlling odr if > > Activity/Inactivity detection is enabled? > > Disallowing odr control when activity detection is enabled could be an > option, but what error code should be returned if the user tries to set the > sampling frequency value when not allowed? -EBUSY? I think it makes sense given the constrains on activity events. EBUSY would be my choice as well. Out of curiosity, do you know how the chip behaves if we change the odr with activity enabled? Is it just ignored? - Nuno Sá
On Thu, 08 Jan 2026 13:45:59 +0000 Nuno Sá <noname.nuno@gmail.com> wrote: > On Wed, 2026-01-07 at 16:39 +0100, Francesco Lavra wrote: > > On Wed, 2026-01-07 at 13:56 +0000, Nuno Sá wrote: > > > Hi Francesco, > > > > > > On Wed, 2026-01-07 at 13:35 +0100, Francesco Lavra wrote: > > > > In sensor variants (such as ADXL380 and ADXL382) that support low-power > > > > mode, the SAR signal path allows sampling acceleration data at lower > > > > rates; > > > > more specifically, when the sensor operates in VLP mode, the sampling > > > > frequency is 1 kHz. > > > > To add support for the 1kHz sampling frequency value, modify the > > > > operating > > > > mode selection logic to take into account the sampling frequency, and > > > > configure the decimation filters only when applicable (i.e. when using > > > > a > > > > sampling frequency that relies on the DSM signal path). > > > > > > > > Signed-off-by: Francesco Lavra <flavra@baylibre.com> > > > > --- > > > > drivers/iio/accel/adxl380.c | 49 +++++++++++++++++++++++-------------- > > > > drivers/iio/accel/adxl380.h | 10 +++++++- > > > > 2 files changed, 40 insertions(+), 19 deletions(-) > > > > > > > > diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c > > > > index bbf1f88ca781..a6919dfce2e9 100644 > > > > --- a/drivers/iio/accel/adxl380.c > > > > +++ b/drivers/iio/accel/adxl380.c > > > > @@ -245,12 +245,14 @@ static int adxl380_set_measure_en(struct > > > > adxl380_state *st, bool en) > > > > > > > > /* > > > > * Activity/Inactivity detection available only in > > > > VLP/ULP > > > > - * mode and for devices that support low power modes. > > > > Otherwise > > > > - * go straight to measure mode (same bits as > > > > ADXL380_OP_MODE_HP). > > > > + * mode and for devices that support low power modes. > > > > */ > > > > if (st->chip_info->has_low_power && > > > > (FIELD_GET(ADXL380_ACT_EN_MSK, act_inact_ctl) || > > > > FIELD_GET(ADXL380_INACT_EN_MSK, act_inact_ctl))) > > > > + st->odr = ADXL380_ODR_VLP; > > > > + > > > > > > So before this change we would go to low power mode but still report > > > whatever sampling frequency > > > userspace had configured (which I guess would not correspond to reality)? > > > > Correct. > > > > > With the above we'll > > > update the reported odr right? > > > > Right. > > > > > Some things/doubts that come to mind: > > > > > > 1. If I'm right not sure if this shouldn't be treated as a fix. > > > > Yes, this technically fixes an existing issue, but I didn't advertise it as > > a fix because solving the issue requires adding support for the 1kHz > > frequency, which seems to go beyond the strict definition of a fix and > > sounds more like a new feature. > > > > > 2. Should we cache the current odr so that we restore it when > > > appropriate? > > > > Do you mean caching it when activity detection is enabled and restoring it > > when detection is disabled? It could be done. > > > > Just and idea. I think it makes sense since enabling activity detection will change things > under the hood and some users might not realize it. But it is not super important I guess. Given these sorts of complex interactions between userspace attributes in IIO are common, we allow any ABI to change any other. So I'd keep it simple and not cache the previous value. Enabling activity/inactivity switches to the low frequency and we stay there if it is disabled until userspace elects to speed things up again. > > > > 3. Other thing that comes to mind is if it makes sense to allow > > > controlling odr if > > > Activity/Inactivity detection is enabled? > > > > Disallowing odr control when activity detection is enabled could be an > > option, but what error code should be returned if the user tries to set the > > sampling frequency value when not allowed? -EBUSY? > > I think it makes sense given the constrains on activity events. EBUSY would be my choice as well. > Out of curiosity, do you know how the chip behaves if we change the odr with activity enabled? Is it > just ignored? Make sure than we report _available for the sampling_frequency and that updates to reflect what is possible when activity detection enabled. That then represents that we can't change it in that mode, but can if we disable activity detection. Jonathan > > - Nuno Sá > >
On Thu, 2026-01-08 at 13:45 +0000, Nuno Sá wrote: > On Wed, 2026-01-07 at 16:39 +0100, Francesco Lavra wrote: > > On Wed, 2026-01-07 at 13:56 +0000, Nuno Sá wrote: > > > > > 3. Other thing that comes to mind is if it makes sense to allow > > > controlling odr if > > > Activity/Inactivity detection is enabled? > > > > Disallowing odr control when activity detection is enabled could be an > > option, but what error code should be returned if the user tries to set > > the > > sampling frequency value when not allowed? -EBUSY? > > I think it makes sense given the constrains on activity events. EBUSY > would be my choice as well. > Out of curiosity, do you know how the chip behaves if we change the odr > with activity enabled? Is it > just ignored? The chip supports activity detection only when in low-power mode; changing the odr to a value that requires exiting from low-power mode would mean effectively disabling activity detection. The driver prevents this by forcing low-power mode whenever detection is enabled, which means that any odr changes by userspace do not take effect as long as detection is enabled.
On Thu, 2026-01-08 at 15:07 +0100, Francesco Lavra wrote: > On Thu, 2026-01-08 at 13:45 +0000, Nuno Sá wrote: > > On Wed, 2026-01-07 at 16:39 +0100, Francesco Lavra wrote: > > > On Wed, 2026-01-07 at 13:56 +0000, Nuno Sá wrote: > > > > > > > 3. Other thing that comes to mind is if it makes sense to allow > > > > controlling odr if > > > > Activity/Inactivity detection is enabled? > > > > > > Disallowing odr control when activity detection is enabled could be an > > > option, but what error code should be returned if the user tries to set > > > the > > > sampling frequency value when not allowed? -EBUSY? > > > > I think it makes sense given the constrains on activity events. EBUSY > > would be my choice as well. > > Out of curiosity, do you know how the chip behaves if we change the odr > > with activity enabled? Is it > > just ignored? > > The chip supports activity detection only when in low-power mode; changing > the odr to a value that requires exiting from low-power mode would mean > effectively disabling activity detection. The driver prevents this by > forcing low-power mode whenever detection is enabled, which means that any > odr changes by userspace do not take effect as long as detection is > enabled. Thx for the explanation! - Nuno Sá
© 2016 - 2026 Red Hat, Inc.