The rate at which accelerometer or gyroscope sensor samples are fed
to the hardware FIFO (batch data rate, or BDR) does not have to
coincide with the sensor sampling frequency (output data rate, or
ODR); the only requirement is for the BDR to not be greater than
the ODR. Having a BDR lower than the ODR is useful in cases where
an application requires a high sampling rate for accurate detection
of motion events (e.g. wakeup events), but wants to read sensor
sample values from the device buffer at a lower data rate.
To support the above use case, add a sampling_frequency sysfs
attribute to the buffer directory of st_lsm6dsx IIO devices, which
controls the BDR for a given sensor independently from the "main"
sampling_frequency attribute (which controls the ODR); introduce a
new `bdr` field in struct st_lsm6dsx_sensor to keep track of the
current BDR value, and use this field instead of the `odr` field in
the code that deals with the FIFO data rate. In the sensor hub
driver, make the bdr value always mirror the odr value, since there
is no separate configuration setting to control the BDR for data
produced by the sensor hub functionality.
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
---
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h | 2 +
.../iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 64 ++++++++++++++++---
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 9 ++-
drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c | 4 +-
4 files changed, 66 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
index bd366c6e282a..dc4aeea3a3b8 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
@@ -366,6 +366,7 @@ enum st_lsm6dsx_fifo_mode {
* @hw: Pointer to instance of struct st_lsm6dsx_hw.
* @gain: Configured sensor sensitivity.
* @odr: Output data rate of the sensor [mHz].
+ * @bdr: Batch data rate [mHz]
* @samples_to_discard: Number of samples to discard for filters settling time.
* @watermark: Sensor watermark level.
* @decimator: Sensor decimation factor.
@@ -380,6 +381,7 @@ struct st_lsm6dsx_sensor {
u32 gain;
u32 odr;
+ u32 bdr;
u16 samples_to_discard;
u16 watermark;
diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
index 8a9d2593576a..5912ea76d493 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
@@ -56,6 +56,7 @@
#include <linux/iio/kfifo_buf.h>
#include <linux/iio/iio.h>
#include <linux/iio/buffer.h>
+#include <linux/iio/sysfs.h>
#include <linux/regmap.h>
#include <linux/bitfield.h>
@@ -105,7 +106,7 @@ static int
st_lsm6dsx_get_decimator_val(struct st_lsm6dsx_sensor *sensor, u32 max_odr)
{
const int max_size = ARRAY_SIZE(st_lsm6dsx_decimator_table);
- u32 decimator = max_odr / sensor->odr;
+ u32 decimator = max_odr / sensor->bdr;
int i;
if (decimator > 1)
@@ -136,14 +137,14 @@ static void st_lsm6dsx_get_max_min_odr(struct st_lsm6dsx_hw *hw,
if (!(hw->enable_mask & BIT(sensor->id)))
continue;
- *max_odr = max_t(u32, *max_odr, sensor->odr);
- *min_odr = min_t(u32, *min_odr, sensor->odr);
+ *max_odr = max_t(u32, *max_odr, sensor->bdr);
+ *min_odr = min_t(u32, *min_odr, sensor->bdr);
}
}
static u8 st_lsm6dsx_get_sip(struct st_lsm6dsx_sensor *sensor, u32 min_odr)
{
- u8 sip = sensor->odr / min_odr;
+ u8 sip = sensor->bdr / min_odr;
return sip > 1 ? round_down(sip, 2) : sip;
}
@@ -231,7 +232,7 @@ static int st_lsm6dsx_set_fifo_odr(struct st_lsm6dsx_sensor *sensor,
if (enable) {
int err;
- err = st_lsm6dsx_check_odr(sensor, sensor->odr,
+ err = st_lsm6dsx_check_odr(sensor, sensor->bdr,
&data);
if (err < 0)
return err;
@@ -713,7 +714,7 @@ st_lsm6dsx_update_samples_to_discard(struct st_lsm6dsx_sensor *sensor)
data = &hw->settings->samples_to_discard[sensor->id];
for (i = 0; i < ST_LSM6DSX_ODR_LIST_SIZE; i++) {
- if (data->val[i].milli_hz == sensor->odr) {
+ if (data->val[i].milli_hz == sensor->bdr) {
sensor->samples_to_discard = data->val[i].samples;
return;
}
@@ -799,6 +800,52 @@ static const struct iio_buffer_setup_ops st_lsm6dsx_buffer_ops = {
.postdisable = st_lsm6dsx_buffer_postdisable,
};
+static ssize_t st_lsm6dsx_bdr_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct st_lsm6dsx_sensor *sensor = iio_priv(dev_to_iio_dev(dev));
+ u32 bdr = sensor->bdr;
+
+ return sysfs_emit(buf, "%d.%03d\n", bdr / 1000, bdr % 1000);
+}
+
+static ssize_t st_lsm6dsx_bdr_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_dev *iio_dev = dev_to_iio_dev(dev);
+ struct st_lsm6dsx_sensor *sensor = iio_priv(iio_dev);
+ int integer, fract;
+ int ret;
+ u32 bdr;
+ u8 data;
+
+ ret = iio_str_to_fixpoint(buf, 100, &integer, &fract);
+ if (ret)
+ return ret;
+ bdr = integer * 1000 + fract;
+ ret = st_lsm6dsx_check_odr(sensor, bdr, &data);
+ if (ret < 0)
+ return ret;
+ bdr = ret;
+ if (!iio_device_claim_direct(iio_dev))
+ return -EBUSY;
+ /* the batch data rate must not exceed the sensor output data rate */
+ if (bdr <= sensor->odr)
+ sensor->bdr = bdr;
+ else
+ ret = -EINVAL;
+ iio_device_release_direct(iio_dev);
+ return (ret < 0) ? ret : len;
+}
+
+static IIO_DEV_ATTR_SAMP_FREQ(0664, st_lsm6dsx_bdr_show, st_lsm6dsx_bdr_store);
+
+static const struct iio_dev_attr *st_lsm6dsx_buffer_attrs[] = {
+ &iio_dev_attr_sampling_frequency,
+ NULL
+};
+
int st_lsm6dsx_fifo_setup(struct st_lsm6dsx_hw *hw)
{
int i, ret;
@@ -807,8 +854,9 @@ int st_lsm6dsx_fifo_setup(struct st_lsm6dsx_hw *hw)
if (!hw->iio_devs[i])
continue;
- ret = devm_iio_kfifo_buffer_setup(hw->dev, hw->iio_devs[i],
- &st_lsm6dsx_buffer_ops);
+ ret = devm_iio_kfifo_buffer_setup_ext(hw->dev, hw->iio_devs[i],
+ &st_lsm6dsx_buffer_ops,
+ st_lsm6dsx_buffer_attrs);
if (ret)
return ret;
}
diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
index c65ad49829e7..e4922578329e 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
@@ -1847,10 +1847,13 @@ static int st_lsm6dsx_write_raw(struct iio_dev *iio_dev,
val = val * 1000 + val2 / 1000;
val = st_lsm6dsx_check_odr(sensor, val, &data);
- if (val < 0)
+ if (val < 0) {
err = val;
- else
+ } else {
sensor->odr = val;
+ /* the batch data rate must not exceed the sensor ODR */
+ sensor->bdr = min_t(u32, sensor->bdr, sensor->odr);
+ }
break;
}
default:
@@ -2383,7 +2386,7 @@ static struct iio_dev *st_lsm6dsx_alloc_iiodev(struct st_lsm6dsx_hw *hw,
sensor = iio_priv(iio_dev);
sensor->id = id;
sensor->hw = hw;
- sensor->odr = hw->settings->odr_table[id].odr_avl[0].milli_hz;
+ sensor->odr = sensor->bdr = hw->settings->odr_table[id].odr_avl[0].milli_hz;
sensor->gain = hw->settings->fs_table[id].fs_avl[0].gain;
sensor->watermark = 1;
diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c
index 3c5e65dc0f97..01d73002e888 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c
@@ -639,7 +639,7 @@ __st_lsm6dsx_shub_write_raw(struct iio_dev *iio_dev,
return odr;
sensor->ext_info.slv_odr = val;
- sensor->odr = odr;
+ sensor->odr = sensor->bdr = odr;
return 0;
}
case IIO_CHAN_INFO_SCALE:
@@ -745,7 +745,7 @@ st_lsm6dsx_shub_alloc_iiodev(struct st_lsm6dsx_hw *hw,
sensor = iio_priv(iio_dev);
sensor->id = id;
sensor->hw = hw;
- sensor->odr = hw->settings->odr_table[ref_id].odr_avl[0].milli_hz;
+ sensor->odr = sensor->bdr = hw->settings->odr_table[ref_id].odr_avl[0].milli_hz;
sensor->ext_info.slv_odr = info->odr_table.odr_avl[0].milli_hz;
sensor->gain = info->fs_table.fs_avl[0].gain;
sensor->ext_info.settings = info;
--
2.39.5On Thu, 9 Oct 2025 19:36:09 +0200
Francesco Lavra <flavra@baylibre.com> wrote:
> The rate at which accelerometer or gyroscope sensor samples are fed
> to the hardware FIFO (batch data rate, or BDR) does not have to
> coincide with the sensor sampling frequency (output data rate, or
> ODR); the only requirement is for the BDR to not be greater than
> the ODR. Having a BDR lower than the ODR is useful in cases where
> an application requires a high sampling rate for accurate detection
> of motion events (e.g. wakeup events), but wants to read sensor
> sample values from the device buffer at a lower data rate.
> To support the above use case, add a sampling_frequency sysfs
> attribute to the buffer directory of st_lsm6dsx IIO devices, which
> controls the BDR for a given sensor independently from the "main"
> sampling_frequency attribute (which controls the ODR); introduce a
> new `bdr` field in struct st_lsm6dsx_sensor to keep track of the
> current BDR value, and use this field instead of the `odr` field in
> the code that deals with the FIFO data rate. In the sensor hub
> driver, make the bdr value always mirror the odr value, since there
> is no separate configuration setting to control the BDR for data
> produced by the sensor hub functionality.
>
> Signed-off-by: Francesco Lavra <flavra@baylibre.com>
A few additional trivial things from me. In general this looks fine.
Whilst that buffer/sampling_frequency isn't common it's been part
of the ABI for a while for this sort of thing.
My only slight concern is backwards compatibility.
Perhaps you can add something on what happens if main sampling_frequency
is modified by a user who doesn't know anything about buffer/sampling_frequency?
Given that's a new interface and the ABI always allows a write to one
value to change any other maybe we have to say the main sampling frequency
write updates the buffer one and a write to the buffer one after that is needed
to set it to a different value?
That is a bit ugly but it is backwards compatible I think.
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> index 8a9d2593576a..5912ea76d493 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> @@ -56,6 +56,7 @@
> #include <linux/iio/kfifo_buf.h>
> #include <linux/iio/iio.h>
> #include <linux/iio/buffer.h>
> +#include <linux/iio/sysfs.h>
> #include <linux/regmap.h>
> #include <linux/bitfield.h>
>
> @@ -105,7 +106,7 @@ static int
> st_lsm6dsx_get_decimator_val(struct st_lsm6dsx_sensor *sensor, u32 max_odr)
> {
> const int max_size = ARRAY_SIZE(st_lsm6dsx_decimator_table);
> - u32 decimator = max_odr / sensor->odr;
> + u32 decimator = max_odr / sensor->bdr;
No idea why there is a bonus space after = but good to cleanup whilst you are
here.
> int i;
> +static ssize_t st_lsm6dsx_bdr_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct iio_dev *iio_dev = dev_to_iio_dev(dev);
> + struct st_lsm6dsx_sensor *sensor = iio_priv(iio_dev);
> + int integer, fract;
> + int ret;
> + u32 bdr;
> + u8 data;
> +
> + ret = iio_str_to_fixpoint(buf, 100, &integer, &fract);
> + if (ret)
> + return ret;
Add blank line after this sort of error handling return. Slightly helps
with readability.
> + bdr = integer * 1000 + fract;
> + ret = st_lsm6dsx_check_odr(sensor, bdr, &data);
> + if (ret < 0)
> + return ret;
Here as well.
> + bdr = ret;
Probably here as well.
> + if (!iio_device_claim_direct(iio_dev))
> + return -EBUSY;
> + /* the batch data rate must not exceed the sensor output data rate */
> + if (bdr <= sensor->odr)
> + sensor->bdr = bdr;
> + else
> + ret = -EINVAL;
> + iio_device_release_direct(iio_dev);
Add one before the final return.
> + return (ret < 0) ? ret : len;
> +}
On Fri, 2025-10-10 at 18:44 +0100, Jonathan Cameron wrote:
> On Thu, 9 Oct 2025 19:36:09 +0200
> Francesco Lavra <flavra@baylibre.com> wrote:
>
> > The rate at which accelerometer or gyroscope sensor samples are fed
> > to the hardware FIFO (batch data rate, or BDR) does not have to
> > coincide with the sensor sampling frequency (output data rate, or
> > ODR); the only requirement is for the BDR to not be greater than
> > the ODR. Having a BDR lower than the ODR is useful in cases where
> > an application requires a high sampling rate for accurate detection
> > of motion events (e.g. wakeup events), but wants to read sensor
> > sample values from the device buffer at a lower data rate.
> > To support the above use case, add a sampling_frequency sysfs
> > attribute to the buffer directory of st_lsm6dsx IIO devices, which
> > controls the BDR for a given sensor independently from the "main"
> > sampling_frequency attribute (which controls the ODR); introduce a
> > new `bdr` field in struct st_lsm6dsx_sensor to keep track of the
> > current BDR value, and use this field instead of the `odr` field in
> > the code that deals with the FIFO data rate. In the sensor hub
> > driver, make the bdr value always mirror the odr value, since there
> > is no separate configuration setting to control the BDR for data
> > produced by the sensor hub functionality.
> >
> > Signed-off-by: Francesco Lavra <flavra@baylibre.com>
>
> A few additional trivial things from me. In general this looks fine.
> Whilst that buffer/sampling_frequency isn't common it's been part
> of the ABI for a while for this sort of thing.
>
> My only slight concern is backwards compatibility.
> Perhaps you can add something on what happens if main sampling_frequency
> is modified by a user who doesn't know anything about
> buffer/sampling_frequency?
>
> Given that's a new interface and the ABI always allows a write to one
> value to change any other maybe we have to say the main sampling
> frequency
> write updates the buffer one and a write to the buffer one after that is
> needed
> to set it to a different value?
>
> That is a bit ugly but it is backwards compatible I think.
Yes, for backwards compatibility it makes sense to update the buffer
frequency whenever the main frequency is set. Will do.
OK also for the cosmetic changes below.
> > diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> > b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> > index 8a9d2593576a..5912ea76d493 100644
> > --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> > +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> > @@ -56,6 +56,7 @@
> > #include <linux/iio/kfifo_buf.h>
> > #include <linux/iio/iio.h>
> > #include <linux/iio/buffer.h>
> > +#include <linux/iio/sysfs.h>
> > #include <linux/regmap.h>
> > #include <linux/bitfield.h>
> >
> > @@ -105,7 +106,7 @@ static int
> > st_lsm6dsx_get_decimator_val(struct st_lsm6dsx_sensor *sensor, u32
> > max_odr)
> > {
> > const int max_size = ARRAY_SIZE(st_lsm6dsx_decimator_table);
> > - u32 decimator = max_odr / sensor->odr;
> > + u32 decimator = max_odr / sensor->bdr;
>
> No idea why there is a bonus space after = but good to cleanup whilst you
> are
> here.
>
> > int i;
>
> > +static ssize_t st_lsm6dsx_bdr_store(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t len)
> > +{
> > + struct iio_dev *iio_dev = dev_to_iio_dev(dev);
> > + struct st_lsm6dsx_sensor *sensor = iio_priv(iio_dev);
> > + int integer, fract;
> > + int ret;
> > + u32 bdr;
> > + u8 data;
> > +
> > + ret = iio_str_to_fixpoint(buf, 100, &integer, &fract);
> > + if (ret)
> > + return ret;
>
> Add blank line after this sort of error handling return. Slightly helps
> with readability.
>
> > + bdr = integer * 1000 + fract;
> > + ret = st_lsm6dsx_check_odr(sensor, bdr, &data);
> > + if (ret < 0)
> > + return ret;
> Here as well.
> > + bdr = ret;
>
> Probably here as well.
>
> > + if (!iio_device_claim_direct(iio_dev))
> > + return -EBUSY;
> > + /* the batch data rate must not exceed the sensor output data
> > rate */
> > + if (bdr <= sensor->odr)
> > + sensor->bdr = bdr;
> > + else
> > + ret = -EINVAL;
> > + iio_device_release_direct(iio_dev);
> Add one before the final return.
> > + return (ret < 0) ? ret : len;
> > +}
On Thu, Oct 9, 2025 at 8:36 PM Francesco Lavra <flavra@baylibre.com> wrote: > > The rate at which accelerometer or gyroscope sensor samples are fed > to the hardware FIFO (batch data rate, or BDR) does not have to > coincide with the sensor sampling frequency (output data rate, or > ODR); the only requirement is for the BDR to not be greater than > the ODR. Having a BDR lower than the ODR is useful in cases where > an application requires a high sampling rate for accurate detection > of motion events (e.g. wakeup events), but wants to read sensor > sample values from the device buffer at a lower data rate. > To support the above use case, add a sampling_frequency sysfs > attribute to the buffer directory of st_lsm6dsx IIO devices, which > controls the BDR for a given sensor independently from the "main" > sampling_frequency attribute (which controls the ODR); introduce a > new `bdr` field in struct st_lsm6dsx_sensor to keep track of the > current BDR value, and use this field instead of the `odr` field in > the code that deals with the FIFO data rate. In the sensor hub > driver, make the bdr value always mirror the odr value, since there > is no separate configuration setting to control the BDR for data > produced by the sensor hub functionality. ... > - *max_odr = max_t(u32, *max_odr, sensor->odr); > - *min_odr = min_t(u32, *min_odr, sensor->odr); > + *max_odr = max_t(u32, *max_odr, sensor->bdr); > + *min_odr = min_t(u32, *min_odr, sensor->bdr); Can we get rid of '_t' parts at some point? Or IOW what is the good justification for typed macros here? ... > + ret = iio_str_to_fixpoint(buf, 100, &integer, &fract); > + if (ret) > + return ret; > + bdr = integer * 1000 + fract; MILLI? -- With Best Regards, Andy Shevchenko
On Fri, 2025-10-10 at 17:55 +0300, Andy Shevchenko wrote: > On Thu, Oct 9, 2025 at 8:36 PM Francesco Lavra <flavra@baylibre.com> > wrote: > > > > The rate at which accelerometer or gyroscope sensor samples are fed > > to the hardware FIFO (batch data rate, or BDR) does not have to > > coincide with the sensor sampling frequency (output data rate, or > > ODR); the only requirement is for the BDR to not be greater than > > the ODR. Having a BDR lower than the ODR is useful in cases where > > an application requires a high sampling rate for accurate detection > > of motion events (e.g. wakeup events), but wants to read sensor > > sample values from the device buffer at a lower data rate. > > To support the above use case, add a sampling_frequency sysfs > > attribute to the buffer directory of st_lsm6dsx IIO devices, which > > controls the BDR for a given sensor independently from the "main" > > sampling_frequency attribute (which controls the ODR); introduce a > > new `bdr` field in struct st_lsm6dsx_sensor to keep track of the > > current BDR value, and use this field instead of the `odr` field in > > the code that deals with the FIFO data rate. In the sensor hub > > driver, make the bdr value always mirror the odr value, since there > > is no separate configuration setting to control the BDR for data > > produced by the sensor hub functionality. > > ... > > > - *max_odr = max_t(u32, *max_odr, sensor->odr); > > - *min_odr = min_t(u32, *min_odr, sensor->odr); > > + *max_odr = max_t(u32, *max_odr, sensor->bdr); > > + *min_odr = min_t(u32, *min_odr, sensor->bdr); > > Can we get rid of '_t' parts at some point? Or IOW what is the good > justification for typed macros here? I think they are not justified here, I will get take this opportunity to get rid of them. > ... > > > + ret = iio_str_to_fixpoint(buf, 100, &integer, &fract); > > + if (ret) > > + return ret; > > + bdr = integer * 1000 + fract; > > MILLI? If you mean replacing fract with milli, will do.
On Fri, Oct 10, 2025 at 08:44:50PM +0200, Francesco Lavra wrote: > On Fri, 2025-10-10 at 17:55 +0300, Andy Shevchenko wrote: > > On Thu, Oct 9, 2025 at 8:36 PM Francesco Lavra <flavra@baylibre.com> > > wrote: ... > > > + ret = iio_str_to_fixpoint(buf, 100, &integer, &fract); > > > + if (ret) > > > + return ret; > > > + bdr = integer * 1000 + fract; > > > > MILLI? > > If you mean replacing fract with milli, will do. I meant 1000 --> MILLI(?) or whatever SI prefix suits better? -- With Best Regards, Andy Shevchenko
> The rate at which accelerometer or gyroscope sensor samples are fed
> to the hardware FIFO (batch data rate, or BDR) does not have to
> coincide with the sensor sampling frequency (output data rate, or
> ODR); the only requirement is for the BDR to not be greater than
> the ODR. Having a BDR lower than the ODR is useful in cases where
> an application requires a high sampling rate for accurate detection
> of motion events (e.g. wakeup events), but wants to read sensor
> sample values from the device buffer at a lower data rate.
can you please provide more details here? Are you using the hw fifo to read
data? If we configure the hw fifo according to the BDR (even assuming the
watermark is set 1) the hw will generate interrupts according to the BDR
(bdr < odr).
> To support the above use case, add a sampling_frequency sysfs
> attribute to the buffer directory of st_lsm6dsx IIO devices, which
> controls the BDR for a given sensor independently from the "main"
> sampling_frequency attribute (which controls the ODR); introduce a
> new `bdr` field in struct st_lsm6dsx_sensor to keep track of the
> current BDR value, and use this field instead of the `odr` field in
> the code that deals with the FIFO data rate. In the sensor hub
> driver, make the bdr value always mirror the odr value, since there
> is no separate configuration setting to control the BDR for data
> produced by the sensor hub functionality.
>
> Signed-off-by: Francesco Lavra <flavra@baylibre.com>
> ---
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h | 2 +
> .../iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c | 64 ++++++++++++++++---
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 9 ++-
> drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c | 4 +-
> 4 files changed, 66 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> index bd366c6e282a..dc4aeea3a3b8 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
> @@ -366,6 +366,7 @@ enum st_lsm6dsx_fifo_mode {
> * @hw: Pointer to instance of struct st_lsm6dsx_hw.
> * @gain: Configured sensor sensitivity.
> * @odr: Output data rate of the sensor [mHz].
> + * @bdr: Batch data rate [mHz]
> * @samples_to_discard: Number of samples to discard for filters settling time.
> * @watermark: Sensor watermark level.
> * @decimator: Sensor decimation factor.
> @@ -380,6 +381,7 @@ struct st_lsm6dsx_sensor {
>
> u32 gain;
> u32 odr;
> + u32 bdr;
>
> u16 samples_to_discard;
> u16 watermark;
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> index 8a9d2593576a..5912ea76d493 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c
> @@ -56,6 +56,7 @@
> #include <linux/iio/kfifo_buf.h>
> #include <linux/iio/iio.h>
> #include <linux/iio/buffer.h>
> +#include <linux/iio/sysfs.h>
> #include <linux/regmap.h>
> #include <linux/bitfield.h>
>
> @@ -105,7 +106,7 @@ static int
> st_lsm6dsx_get_decimator_val(struct st_lsm6dsx_sensor *sensor, u32 max_odr)
> {
> const int max_size = ARRAY_SIZE(st_lsm6dsx_decimator_table);
> - u32 decimator = max_odr / sensor->odr;
> + u32 decimator = max_odr / sensor->bdr;
> int i;
>
> if (decimator > 1)
> @@ -136,14 +137,14 @@ static void st_lsm6dsx_get_max_min_odr(struct st_lsm6dsx_hw *hw,
> if (!(hw->enable_mask & BIT(sensor->id)))
> continue;
>
> - *max_odr = max_t(u32, *max_odr, sensor->odr);
> - *min_odr = min_t(u32, *min_odr, sensor->odr);
> + *max_odr = max_t(u32, *max_odr, sensor->bdr);
> + *min_odr = min_t(u32, *min_odr, sensor->bdr);
> }
> }
>
> static u8 st_lsm6dsx_get_sip(struct st_lsm6dsx_sensor *sensor, u32 min_odr)
> {
> - u8 sip = sensor->odr / min_odr;
> + u8 sip = sensor->bdr / min_odr;
>
> return sip > 1 ? round_down(sip, 2) : sip;
> }
> @@ -231,7 +232,7 @@ static int st_lsm6dsx_set_fifo_odr(struct st_lsm6dsx_sensor *sensor,
> if (enable) {
> int err;
>
> - err = st_lsm6dsx_check_odr(sensor, sensor->odr,
> + err = st_lsm6dsx_check_odr(sensor, sensor->bdr,
> &data);
> if (err < 0)
> return err;
> @@ -713,7 +714,7 @@ st_lsm6dsx_update_samples_to_discard(struct st_lsm6dsx_sensor *sensor)
>
> data = &hw->settings->samples_to_discard[sensor->id];
> for (i = 0; i < ST_LSM6DSX_ODR_LIST_SIZE; i++) {
> - if (data->val[i].milli_hz == sensor->odr) {
> + if (data->val[i].milli_hz == sensor->bdr) {
> sensor->samples_to_discard = data->val[i].samples;
> return;
> }
> @@ -799,6 +800,52 @@ static const struct iio_buffer_setup_ops st_lsm6dsx_buffer_ops = {
> .postdisable = st_lsm6dsx_buffer_postdisable,
> };
>
> +static ssize_t st_lsm6dsx_bdr_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct st_lsm6dsx_sensor *sensor = iio_priv(dev_to_iio_dev(dev));
> + u32 bdr = sensor->bdr;
> +
> + return sysfs_emit(buf, "%d.%03d\n", bdr / 1000, bdr % 1000);
> +}
> +
> +static ssize_t st_lsm6dsx_bdr_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t len)
> +{
> + struct iio_dev *iio_dev = dev_to_iio_dev(dev);
> + struct st_lsm6dsx_sensor *sensor = iio_priv(iio_dev);
> + int integer, fract;
> + int ret;
> + u32 bdr;
> + u8 data;
> +
> + ret = iio_str_to_fixpoint(buf, 100, &integer, &fract);
> + if (ret)
> + return ret;
nit: new line here.
> + bdr = integer * 1000 + fract;
> + ret = st_lsm6dsx_check_odr(sensor, bdr, &data);
> + if (ret < 0)
> + return ret;
nit: new line here.
> + bdr = ret;
> + if (!iio_device_claim_direct(iio_dev))
> + return -EBUSY;
I guess you can check it at the beginning of the routine.
> + /* the batch data rate must not exceed the sensor output data rate */
> + if (bdr <= sensor->odr)
> + sensor->bdr = bdr;
> + else
> + ret = -EINVAL;
nit: new line here.
> + iio_device_release_direct(iio_dev);
nit: new line here.
> + return (ret < 0) ? ret : len;
nit: we do not need brackets here.
> +}
> +
> +static IIO_DEV_ATTR_SAMP_FREQ(0664, st_lsm6dsx_bdr_show, st_lsm6dsx_bdr_store);
> +
> +static const struct iio_dev_attr *st_lsm6dsx_buffer_attrs[] = {
> + &iio_dev_attr_sampling_frequency,
> + NULL
> +};
> +
> int st_lsm6dsx_fifo_setup(struct st_lsm6dsx_hw *hw)
> {
> int i, ret;
> @@ -807,8 +854,9 @@ int st_lsm6dsx_fifo_setup(struct st_lsm6dsx_hw *hw)
> if (!hw->iio_devs[i])
> continue;
>
> - ret = devm_iio_kfifo_buffer_setup(hw->dev, hw->iio_devs[i],
> - &st_lsm6dsx_buffer_ops);
> + ret = devm_iio_kfifo_buffer_setup_ext(hw->dev, hw->iio_devs[i],
> + &st_lsm6dsx_buffer_ops,
> + st_lsm6dsx_buffer_attrs);
> if (ret)
> return ret;
> }
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> index c65ad49829e7..e4922578329e 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c
> @@ -1847,10 +1847,13 @@ static int st_lsm6dsx_write_raw(struct iio_dev *iio_dev,
>
> val = val * 1000 + val2 / 1000;
> val = st_lsm6dsx_check_odr(sensor, val, &data);
> - if (val < 0)
> + if (val < 0) {
> err = val;
> - else
> + } else {
> sensor->odr = val;
> + /* the batch data rate must not exceed the sensor ODR */
> + sensor->bdr = min_t(u32, sensor->bdr, sensor->odr);
> + }
> break;
> }
> default:
> @@ -2383,7 +2386,7 @@ static struct iio_dev *st_lsm6dsx_alloc_iiodev(struct st_lsm6dsx_hw *hw,
> sensor = iio_priv(iio_dev);
> sensor->id = id;
> sensor->hw = hw;
> - sensor->odr = hw->settings->odr_table[id].odr_avl[0].milli_hz;
> + sensor->odr = sensor->bdr = hw->settings->odr_table[id].odr_avl[0].milli_hz;
please add a new line to set sensor->bdr here.
> sensor->gain = hw->settings->fs_table[id].fs_avl[0].gain;
> sensor->watermark = 1;
>
> diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c
> index 3c5e65dc0f97..01d73002e888 100644
> --- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c
> +++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_shub.c
> @@ -639,7 +639,7 @@ __st_lsm6dsx_shub_write_raw(struct iio_dev *iio_dev,
> return odr;
>
> sensor->ext_info.slv_odr = val;
> - sensor->odr = odr;
> + sensor->odr = sensor->bdr = odr;
> return 0;
> }
> case IIO_CHAN_INFO_SCALE:
> @@ -745,7 +745,7 @@ st_lsm6dsx_shub_alloc_iiodev(struct st_lsm6dsx_hw *hw,
> sensor = iio_priv(iio_dev);
> sensor->id = id;
> sensor->hw = hw;
> - sensor->odr = hw->settings->odr_table[ref_id].odr_avl[0].milli_hz;
> + sensor->odr = sensor->bdr = hw->settings->odr_table[ref_id].odr_avl[0].milli_hz;
please add a new line to set sensor->bdr here.
> sensor->ext_info.slv_odr = info->odr_table.odr_avl[0].milli_hz;
> sensor->gain = info->fs_table.fs_avl[0].gain;
> sensor->ext_info.settings = info;
> --
> 2.39.5
>
On Fri, 2025-10-10 at 00:30 +0200, Lorenzo Bianconi wrote: > > The rate at which accelerometer or gyroscope sensor samples are fed > > to the hardware FIFO (batch data rate, or BDR) does not have to > > coincide with the sensor sampling frequency (output data rate, or > > ODR); the only requirement is for the BDR to not be greater than > > the ODR. Having a BDR lower than the ODR is useful in cases where > > an application requires a high sampling rate for accurate detection > > of motion events (e.g. wakeup events), but wants to read sensor > > sample values from the device buffer at a lower data rate. > > can you please provide more details here? Are you using the hw fifo to > read > data? If we configure the hw fifo according to the BDR (even assuming the > watermark is set 1) the hw will generate interrupts according to the BDR > (bdr < odr). Yes, I'm using the hw fifo to read data. The use case is to enable event detection (which works best at high sampling rates) and sensor data streaming at the same time, without requiring the data stream to be at the same rate as the sensor sampling rate. So the amount of I2C (or SPI) traffic (as well as the rate of periodic interrupts) required by the data stream is kept to a minimum without sacrificing the accuracy of event detection.
> On Fri, 2025-10-10 at 00:30 +0200, Lorenzo Bianconi wrote: > > > The rate at which accelerometer or gyroscope sensor samples are fed > > > to the hardware FIFO (batch data rate, or BDR) does not have to > > > coincide with the sensor sampling frequency (output data rate, or > > > ODR); the only requirement is for the BDR to not be greater than > > > the ODR. Having a BDR lower than the ODR is useful in cases where > > > an application requires a high sampling rate for accurate detection > > > of motion events (e.g. wakeup events), but wants to read sensor > > > sample values from the device buffer at a lower data rate. > > > > can you please provide more details here? Are you using the hw fifo to > > read > > data? If we configure the hw fifo according to the BDR (even assuming the > > watermark is set 1) the hw will generate interrupts according to the BDR > > (bdr < odr). > > Yes, I'm using the hw fifo to read data. The use case is to enable event > detection (which works best at high sampling rates) and sensor data > streaming at the same time, without requiring the data stream to be at the > same rate as the sensor sampling rate. So the amount of I2C (or SPI) > traffic (as well as the rate of periodic interrupts) required by the data > stream is kept to a minimum without sacrificing the accuracy of event > detection. I guess you can get the same result (reduce sensor data interrupt rate keeping high odr value) configuring the hw fifo watermark. Does it work for you? Regards, Lorenzo > >
On Fri, 2025-10-10 at 10:13 +0200, Lorenzo Bianconi wrote: > > On Fri, 2025-10-10 at 00:30 +0200, Lorenzo Bianconi wrote: > > > > The rate at which accelerometer or gyroscope sensor samples are fed > > > > to the hardware FIFO (batch data rate, or BDR) does not have to > > > > coincide with the sensor sampling frequency (output data rate, or > > > > ODR); the only requirement is for the BDR to not be greater than > > > > the ODR. Having a BDR lower than the ODR is useful in cases where > > > > an application requires a high sampling rate for accurate detection > > > > of motion events (e.g. wakeup events), but wants to read sensor > > > > sample values from the device buffer at a lower data rate. > > > > > > can you please provide more details here? Are you using the hw fifo > > > to > > > read > > > data? If we configure the hw fifo according to the BDR (even assuming > > > the > > > watermark is set 1) the hw will generate interrupts according to the > > > BDR > > > (bdr < odr). > > > > Yes, I'm using the hw fifo to read data. The use case is to enable > > event > > detection (which works best at high sampling rates) and sensor data > > streaming at the same time, without requiring the data stream to be at > > the > > same rate as the sensor sampling rate. So the amount of I2C (or SPI) > > traffic (as well as the rate of periodic interrupts) required by the > > data > > stream is kept to a minimum without sacrificing the accuracy of event > > detection. > > I guess you can get the same result (reduce sensor data interrupt rate > keeping high odr value) configuring the hw fifo watermark. > Does it work for you? Setting the hw fifo watermark to a high value reduces the rate of interrupts, but doesn't do much to reduce the amount of I2C traffic, so the issue would still be there.
On Oct 10, Francesco Lavra wrote: > On Fri, 2025-10-10 at 10:13 +0200, Lorenzo Bianconi wrote: > > > On Fri, 2025-10-10 at 00:30 +0200, Lorenzo Bianconi wrote: > > > > > The rate at which accelerometer or gyroscope sensor samples are fed > > > > > to the hardware FIFO (batch data rate, or BDR) does not have to > > > > > coincide with the sensor sampling frequency (output data rate, or > > > > > ODR); the only requirement is for the BDR to not be greater than > > > > > the ODR. Having a BDR lower than the ODR is useful in cases where > > > > > an application requires a high sampling rate for accurate detection > > > > > of motion events (e.g. wakeup events), but wants to read sensor > > > > > sample values from the device buffer at a lower data rate. > > > > > > > > can you please provide more details here? Are you using the hw fifo > > > > to > > > > read > > > > data? If we configure the hw fifo according to the BDR (even assuming > > > > the > > > > watermark is set 1) the hw will generate interrupts according to the > > > > BDR > > > > (bdr < odr). > > > > > > Yes, I'm using the hw fifo to read data. The use case is to enable > > > event > > > detection (which works best at high sampling rates) and sensor data > > > streaming at the same time, without requiring the data stream to be at > > > the > > > same rate as the sensor sampling rate. So the amount of I2C (or SPI) > > > traffic (as well as the rate of periodic interrupts) required by the > > > data > > > stream is kept to a minimum without sacrificing the accuracy of event > > > detection. > > > > I guess you can get the same result (reduce sensor data interrupt rate > > keeping high odr value) configuring the hw fifo watermark. > > Does it work for you? > > Setting the hw fifo watermark to a high value reduces the rate of > interrupts, but doesn't do much to reduce the amount of I2C traffic, so the > issue would still be there. ack, now I got the goal of the series. I think the series is mostly fine. I guess hwfifo_odr instead of bdr is more meaningful, what do you think? Naming is always hard. Regards, Lorenzo
On 10/10/25 8:15 AM, Lorenzo Bianconi wrote: > On Oct 10, Francesco Lavra wrote: >> On Fri, 2025-10-10 at 10:13 +0200, Lorenzo Bianconi wrote: >>>> On Fri, 2025-10-10 at 00:30 +0200, Lorenzo Bianconi wrote: >>>>>> The rate at which accelerometer or gyroscope sensor samples are fed >>>>>> to the hardware FIFO (batch data rate, or BDR) does not have to >>>>>> coincide with the sensor sampling frequency (output data rate, or >>>>>> ODR); the only requirement is for the BDR to not be greater than >>>>>> the ODR. Having a BDR lower than the ODR is useful in cases where >>>>>> an application requires a high sampling rate for accurate detection >>>>>> of motion events (e.g. wakeup events), but wants to read sensor >>>>>> sample values from the device buffer at a lower data rate. >>>>> >>>>> can you please provide more details here? Are you using the hw fifo >>>>> to >>>>> read >>>>> data? If we configure the hw fifo according to the BDR (even assuming >>>>> the >>>>> watermark is set 1) the hw will generate interrupts according to the >>>>> BDR >>>>> (bdr < odr). >>>> >>>> Yes, I'm using the hw fifo to read data. The use case is to enable >>>> event >>>> detection (which works best at high sampling rates) and sensor data >>>> streaming at the same time, without requiring the data stream to be at >>>> the >>>> same rate as the sensor sampling rate. So the amount of I2C (or SPI) >>>> traffic (as well as the rate of periodic interrupts) required by the >>>> data >>>> stream is kept to a minimum without sacrificing the accuracy of event >>>> detection. >>> >>> I guess you can get the same result (reduce sensor data interrupt rate >>> keeping high odr value) configuring the hw fifo watermark. >>> Does it work for you? >> >> Setting the hw fifo watermark to a high value reduces the rate of >> interrupts, but doesn't do much to reduce the amount of I2C traffic, so the >> issue would still be there. > > ack, now I got the goal of the series. I think the series is mostly fine. > I guess hwfifo_odr instead of bdr is more meaningful, what do you think? > Naming is always hard. > > Regards, > Lorenzo In the IIO subsystem, we prefer to include the units in the variable/ field name as well, e.g. hw_fifo_odr_mHz.
On Oct 10, David Lechner wrote: > On 10/10/25 8:15 AM, Lorenzo Bianconi wrote: > > On Oct 10, Francesco Lavra wrote: > >> On Fri, 2025-10-10 at 10:13 +0200, Lorenzo Bianconi wrote: > >>>> On Fri, 2025-10-10 at 00:30 +0200, Lorenzo Bianconi wrote: > >>>>>> The rate at which accelerometer or gyroscope sensor samples are fed > >>>>>> to the hardware FIFO (batch data rate, or BDR) does not have to > >>>>>> coincide with the sensor sampling frequency (output data rate, or > >>>>>> ODR); the only requirement is for the BDR to not be greater than > >>>>>> the ODR. Having a BDR lower than the ODR is useful in cases where > >>>>>> an application requires a high sampling rate for accurate detection > >>>>>> of motion events (e.g. wakeup events), but wants to read sensor > >>>>>> sample values from the device buffer at a lower data rate. > >>>>> > >>>>> can you please provide more details here? Are you using the hw fifo > >>>>> to > >>>>> read > >>>>> data? If we configure the hw fifo according to the BDR (even assuming > >>>>> the > >>>>> watermark is set 1) the hw will generate interrupts according to the > >>>>> BDR > >>>>> (bdr < odr). > >>>> > >>>> Yes, I'm using the hw fifo to read data. The use case is to enable > >>>> event > >>>> detection (which works best at high sampling rates) and sensor data > >>>> streaming at the same time, without requiring the data stream to be at > >>>> the > >>>> same rate as the sensor sampling rate. So the amount of I2C (or SPI) > >>>> traffic (as well as the rate of periodic interrupts) required by the > >>>> data > >>>> stream is kept to a minimum without sacrificing the accuracy of event > >>>> detection. > >>> > >>> I guess you can get the same result (reduce sensor data interrupt rate > >>> keeping high odr value) configuring the hw fifo watermark. > >>> Does it work for you? > >> > >> Setting the hw fifo watermark to a high value reduces the rate of > >> interrupts, but doesn't do much to reduce the amount of I2C traffic, so the > >> issue would still be there. > > > > ack, now I got the goal of the series. I think the series is mostly fine. > > I guess hwfifo_odr instead of bdr is more meaningful, what do you think? > > Naming is always hard. > > > > Regards, > > Lorenzo > > In the IIO subsystem, we prefer to include the units in the variable/ > field name as well, e.g. hw_fifo_odr_mHz. ack, but please avoid camel case :)
On Fri, Oct 10, 2025 at 7:22 PM Lorenzo Bianconi <lorenzo@kernel.org> wrote: > On Oct 10, David Lechner wrote: > > On 10/10/25 8:15 AM, Lorenzo Bianconi wrote: ... > > In the IIO subsystem, we prefer to include the units in the variable/ > > field name as well, e.g. hw_fifo_odr_mHz. > > ack, but please avoid camel case :) Don't mix up a camel case with units. Or do you have a way to distinguish milli from mega, please? -- With Best Regards, Andy Shevchenko
On Fri, 2025-10-10 at 19:23 +0300, Andy Shevchenko wrote: > On Fri, Oct 10, 2025 at 7:22 PM Lorenzo Bianconi <lorenzo@kernel.org> > wrote: > > On Oct 10, David Lechner wrote: > > > On 10/10/25 8:15 AM, Lorenzo Bianconi wrote: > > ... > > > > In the IIO subsystem, we prefer to include the units in the variable/ > > > field name as well, e.g. hw_fifo_odr_mHz. > > > > ack, but please avoid camel case :) > > Don't mix up a camel case with units. > Or do you have a way to distinguish milli from mega, please? OK, I will use hwfifo_odr_mHz
© 2016 - 2025 Red Hat, Inc.