[PATCH 0/2] accel: adxl380: Add support for 1 kHz sampling frequency

[PATCH 0/2] accel: adxl380: Add support for 1 kHz sampling frequency

[Francesco Lavra]

This series adds support for 1kHz sampling frequency for sensor variants
that implement low-power mode.
The first patch is a preparatory step to decouple sampling frequency values
from decimation filter settings, and the second patch adds support for the
new sampling frequency value.
Tested on ADXL382.

Francesco Lavra (2):
  iio: accel: adxl380: Store sampling frequency index in odr struct
    member
  iio: accel: adxl380: Add support for 1 kHz sampling frequency

 drivers/iio/accel/adxl380.c | 62 ++++++++++++++++++++-----------------
 drivers/iio/accel/adxl380.h | 10 +++++-
 2 files changed, 42 insertions(+), 30 deletions(-)

-- 
2.39.5

[PATCH 1/2] iio: accel: adxl380: Store sampling frequency index in odr struct member

[Francesco Lavra]

The ADXL380 driver assumes that acceleration samples are always retrieved
via the high-performance DSM signal path; as a result, the sampling
frequency value depends exclusively on the decimation filter settings in
the TRIG_CFG register.
In preparation for adding support for sampling frequency values that rely
on the low-power SAR signal path (on which the decimation filters are not
supported), use the (currently unused) 'odr' member of struct adxl380_state
to store the sampling frequency value, and when userspace requests the
current frequency value, retrieve it from the struct instead of calculating
it from the decimation filter settings.

Signed-off-by: Francesco Lavra <flavra@baylibre.com>
---
 drivers/iio/accel/adxl380.c | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
index ce3643c5deb8..bbf1f88ca781 100644
--- a/drivers/iio/accel/adxl380.c
+++ b/drivers/iio/accel/adxl380.c
@@ -417,17 +417,7 @@ static int adxl380_read_chn(struct adxl380_state *st, u8 addr)
 
 static int adxl380_get_odr(struct adxl380_state *st, int *odr)
 {
-	int ret;
-	unsigned int trig_cfg, odr_idx;
-
-	ret = regmap_read(st->regmap, ADXL380_TRIG_CFG_REG, &trig_cfg);
-	if (ret)
-		return ret;
-
-	odr_idx = (FIELD_GET(ADXL380_TRIG_CFG_SINC_RATE_MSK, trig_cfg) << 1) |
-		  (FIELD_GET(ADXL380_TRIG_CFG_DEC_2X_MSK, trig_cfg) & 1);
-
-	*odr = st->chip_info->samp_freq_tbl[odr_idx];
+	*odr = st->chip_info->samp_freq_tbl[st->odr];
 
 	return 0;
 }
@@ -500,6 +490,7 @@ static int adxl380_set_odr(struct adxl380_state *st, u8 odr)
 	if (ret)
 		return ret;
 
+	st->odr = odr;
 	ret = adxl380_set_measure_en(st, true);
 	if (ret)
 		return ret;
-- 
2.39.5

Re: [PATCH 1/2] iio: accel: adxl380: Store sampling frequency index in odr struct member

[Nuno Sá]

On Wed, 2026-01-07 at 13:35 +0100, Francesco Lavra wrote:
> The ADXL380 driver assumes that acceleration samples are always retrieved
> via the high-performance DSM signal path; as a result, the sampling
> frequency value depends exclusively on the decimation filter settings in
> the TRIG_CFG register.
> In preparation for adding support for sampling frequency values that rely
> on the low-power SAR signal path (on which the decimation filters are not
> supported), use the (currently unused) 'odr' member of struct adxl380_state
> to store the sampling frequency value, and when userspace requests the
> current frequency value, retrieve it from the struct instead of calculating
> it from the decimation filter settings.
> 
> Signed-off-by: Francesco Lavra <flavra@baylibre.com>
> ---

Reviewed-by: Nuno Sá <nuno.sa@analog.com>

>  drivers/iio/accel/adxl380.c | 13 ++-----------
>  1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/iio/accel/adxl380.c b/drivers/iio/accel/adxl380.c
> index ce3643c5deb8..bbf1f88ca781 100644
> --- a/drivers/iio/accel/adxl380.c
> +++ b/drivers/iio/accel/adxl380.c
> @@ -417,17 +417,7 @@ static int adxl380_read_chn(struct adxl380_state *st, u8 addr)
>  
>  static int adxl380_get_odr(struct adxl380_state *st, int *odr)
>  {
> -	int ret;
> -	unsigned int trig_cfg, odr_idx;
> -
> -	ret = regmap_read(st->regmap, ADXL380_TRIG_CFG_REG, &trig_cfg);
> -	if (ret)
> -		return ret;
> -
> -	odr_idx = (FIELD_GET(ADXL380_TRIG_CFG_SINC_RATE_MSK, trig_cfg) << 1) |
> -		  (FIELD_GET(ADXL380_TRIG_CFG_DEC_2X_MSK, trig_cfg) & 1);
> -
> -	*odr = st->chip_info->samp_freq_tbl[odr_idx];
> +	*odr = st->chip_info->samp_freq_tbl[st->odr];
>  
>  	return 0;
>  }
> @@ -500,6 +490,7 @@ static int adxl380_set_odr(struct adxl380_state *st, u8 odr)
>  	if (ret)
>  		return ret;
>  
> +	st->odr = odr;
>  	ret = adxl380_set_measure_en(st, true);
>  	if (ret)
>  		return ret;

[PATCH 2/2] iio: accel: adxl380: Add support for 1 kHz sampling frequency

[Francesco Lavra]

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.5

Re: [PATCH 2/2] iio: accel: adxl380: Add support for 1 kHz sampling frequency

[Nuno Sá]

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)? 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á

Re: [PATCH 2/2] iio: accel: adxl380: Add support for 1 kHz sampling frequency

[Francesco Lavra]

[-- Attachment #1: Type: text/plain, Size: 3320 bytes --]

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á
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 2/2] iio: accel: adxl380: Add support for 1 kHz sampling frequency

[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á

Re: [PATCH 2/2] iio: accel: adxl380: Add support for 1 kHz sampling frequency

[Francesco Lavra]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 2/2] iio: accel: adxl380: Add support for 1 kHz sampling frequency

[Nuno Sá]

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á

Re: [PATCH 2/2] iio: accel: adxl380: Add support for 1 kHz sampling frequency

[Jonathan Cameron]

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á
> 
>