[PATCH v5 0/3] iio: pressure: dps310: FIFO and triggered buffer support

Rupesh Majhi posted 3 patches 1 month, 1 week ago
There is a newer version of this series
drivers/iio/pressure/Kconfig  |   2 +
drivers/iio/pressure/dps310.c | 718 ++++++++++++++++++++++++++++++----
2 files changed, 646 insertions(+), 74 deletions(-)
[PATCH v5 0/3] iio: pressure: dps310: FIFO and triggered buffer support
Posted by Rupesh Majhi 1 month, 1 week ago
The dps310 has no buffer support today. This series adds it, with the
hardware FIFO used when no external trigger is attached and the FIFO
left disabled in favor of the trigger when one is, so the switch between
the two modes can be reviewed together rather than in two submissions.

Patch 1 fixes the CFG_REG bit definitions and replaces the standalone
fix I sent on 27 July, which Jonathan asked me to fold in here instead:

  Link: https://lore.kernel.org/linux-iio/20260728223009.0cb86996@jic23-huawei/

All three of those defines have been wrong since the driver was added,
but only P_SHIFT has a user and only that one misbehaves, so the patch
carries a Fixes tag for the original driver and one for the commit that
added the first user of P_SHIFT, along with Cc: stable. The FIFO enable
is needed by patch 3.

The three INT_SEL interrupt enables at bits 6 to 4 are still not
defined. Nothing uses them, the driver has no interrupt path, and the
binding has no interrupts property, so adding unused defines to a fix
did not seem worth it. David also asked for the register defines to be
sorted low to high. That is a cleanup series of its own once this lands.

Patch 2 adds the triggered buffer path.

Patch 3 adds the hardware FIFO and the selection between it and an
attached trigger. Those started out as separate patches, but the branch
on iio_device_get_current_mode() is four lines and the FIFO patch is
wrong without it, since postenable would otherwise start the FIFO while
a trigger was driving the buffer. Splitting them would only have left a
broken commit in between, so they are one patch.

Verified on an Infineon DPS310 breakout wired to a BeagleBone Black,
running this series on 7.2.0-rc2. Two modules built from the same tree,
differing only in the three CFG_REG defines corrected here, loaded
seconds apart. Three reads of in_pressure_input per oversampling ratio,
ambient 98.4 kPa and 27.2 degC:

  OSR    before              after
    1    98.433  98.428      98.445  98.446
    8    98.460  98.460      98.477  98.479
   16    -ERANGE             98.566  98.564
   32    -ERANGE             98.428  98.427
   64    -ERANGE             98.464  98.463
  128    98.439  98.440      98.434  98.434

Pressure oversampling 16, 32 and 64 return -ERANGE before the fix.
P_SHIFT is never enabled, so the result register no longer matches the
scale factor the compensation divides by, and
dps310_calculate_pressure() ends up negative. 128 is not affected in
practice. Temperature is unaffected throughout, since TMP_SHIFT_EN was
already defined correctly.

Everything else was checked with checkpatch --strict and a W=1 build,
plus an arm build for aspeed_g5 and a boot under qemu-system-arm -M
rainier-bmc, which covers probe, the sysfs values, raw times scale
matching processed, EBUSY on sysfs reads while the buffer is enabled,
and all three scan mask combinations. QEMU's dps310 model implements
neither the FIFO nor the interrupt, so patch 3 was tested on the
BeagleBone Black above only.

On hardware, patch 3 was checked with both channels enabled, temperature
only and pressure only, at 8 Hz and at 128 Hz. A blocking read returns
in every case, which is the part that needs the timer: with no
interrupt, hwfifo_flush_to_buffer alone would leave a reader asleep on
rb->pollq. At 128 Hz, 100 scans arrive in 0.81 s, so the batching is
real. Timestamps are monotonic throughout and land on the configured
period, 125.0000 ms at 8 Hz, except where a drain collected more than
the rate accounts for and the batch is compressed to stay ordered. With
a sysfs trigger attached the FIFO stays disabled and the trigger drives
the buffer, at the rate trigger_now is written.

Changes since v3 (no v4 was posted):
- the series now includes the FIFO, not just a triggered buffer
- CFG_REG bit fix folded in as patch 1
- scan buffer is a stack local instead of living in struct dps310_data
- available_scan_masks dropped, only enabled channels are pushed
- claim_direct and the mutex use ACQUIRE() scoping
- shared helper for the raw and processed reads
- comment on the pressure channel spec warning against copying the
  raw plus scale approach
- the stale file header claiming only a single temperature read is
  supported goes with patch 3, which is what finally disproves it

Rupesh Majhi (3):
  iio: pressure: dps310: fix CFG_REG bit definitions
  iio: pressure: dps310: add triggered buffer support
  iio: pressure: dps310: add hardware FIFO support

 drivers/iio/pressure/Kconfig  |   2 +
 drivers/iio/pressure/dps310.c | 718 ++++++++++++++++++++++++++++++----
 2 files changed, 646 insertions(+), 74 deletions(-)

-- 
2.43.0
Re: [PATCH v5 0/3] iio: pressure: dps310: FIFO and triggered buffer support
Posted by Andy Shevchenko 1 month, 1 week ago
On Mon, Aug 17, 2026 at 08:07:22PM +0300, Rupesh Majhi wrote:
> The dps310 has no buffer support today. This series adds it, with the
> hardware FIFO used when no external trigger is attached and the FIFO
> left disabled in favor of the trigger when one is, so the switch between
> the two modes can be reviewed together rather than in two submissions.
> 
> Patch 1 fixes the CFG_REG bit definitions and replaces the standalone
> fix I sent on 27 July, which Jonathan asked me to fold in here instead:
> 
>   Link: https://lore.kernel.org/linux-iio/20260728223009.0cb86996@jic23-huawei/
> 
> All three of those defines have been wrong since the driver was added,
> but only P_SHIFT has a user and only that one misbehaves, so the patch
> carries a Fixes tag for the original driver and one for the commit that
> added the first user of P_SHIFT, along with Cc: stable. The FIFO enable
> is needed by patch 3.
> 
> The three INT_SEL interrupt enables at bits 6 to 4 are still not
> defined. Nothing uses them, the driver has no interrupt path, and the
> binding has no interrupts property, so adding unused defines to a fix
> did not seem worth it. David also asked for the register defines to be
> sorted low to high. That is a cleanup series of its own once this lands.
> 
> Patch 2 adds the triggered buffer path.
> 
> Patch 3 adds the hardware FIFO and the selection between it and an
> attached trigger. Those started out as separate patches, but the branch
> on iio_device_get_current_mode() is four lines and the FIFO patch is
> wrong without it, since postenable would otherwise start the FIFO while
> a trigger was driving the buffer. Splitting them would only have left a
> broken commit in between, so they are one patch.
> 
> Verified on an Infineon DPS310 breakout wired to a BeagleBone Black,
> running this series on 7.2.0-rc2. Two modules built from the same tree,
> differing only in the three CFG_REG defines corrected here, loaded
> seconds apart. Three reads of in_pressure_input per oversampling ratio,
> ambient 98.4 kPa and 27.2 degC:
> 
>   OSR    before              after
>     1    98.433  98.428      98.445  98.446
>     8    98.460  98.460      98.477  98.479
>    16    -ERANGE             98.566  98.564
>    32    -ERANGE             98.428  98.427
>    64    -ERANGE             98.464  98.463
>   128    98.439  98.440      98.434  98.434
> 
> Pressure oversampling 16, 32 and 64 return -ERANGE before the fix.
> P_SHIFT is never enabled, so the result register no longer matches the
> scale factor the compensation divides by, and
> dps310_calculate_pressure() ends up negative. 128 is not affected in
> practice. Temperature is unaffected throughout, since TMP_SHIFT_EN was
> already defined correctly.
> 
> Everything else was checked with checkpatch --strict and a W=1 build,
> plus an arm build for aspeed_g5 and a boot under qemu-system-arm -M
> rainier-bmc, which covers probe, the sysfs values, raw times scale
> matching processed, EBUSY on sysfs reads while the buffer is enabled,
> and all three scan mask combinations. QEMU's dps310 model implements
> neither the FIFO nor the interrupt, so patch 3 was tested on the
> BeagleBone Black above only.
> 
> On hardware, patch 3 was checked with both channels enabled, temperature
> only and pressure only, at 8 Hz and at 128 Hz. A blocking read returns
> in every case, which is the part that needs the timer: with no
> interrupt, hwfifo_flush_to_buffer alone would leave a reader asleep on
> rb->pollq. At 128 Hz, 100 scans arrive in 0.81 s, so the batching is
> real. Timestamps are monotonic throughout and land on the configured
> period, 125.0000 ms at 8 Hz, except where a drain collected more than
> the rate accounts for and the batch is compressed to stay ordered. With
> a sysfs trigger attached the FIFO stays disabled and the trigger drives
> the buffer, at the rate trigger_now is written.

Are the commit messages are written with AI? Please, do it yourself.
They are way too overloaded with unneeded noise and details. Make them
to be straight to the point.

-- 
With Best Regards,
Andy Shevchenko
Re: [PATCH v5 0/3] iio: pressure: dps310: FIFO and triggered buffer support
Posted by Rupert Zoone 1 month, 1 week ago
On Mon, Aug 17, 2026 at 09:47 PM +0300, Andy Shevchenko wrote:
> Are the commit messages are written with AI? Please, do it yourself.

Yes, with AI help. I should have tagged it Assisted-by, and v6 will.

> They are way too overloaded with unneeded noise and details. Make them
> to be straight to the point.

Agreed. I have cut them down.

The testing is my own. I wired a DPS310 to a BeagleBone Black,
reproduced the -ERANGE at oversampling 16, 32 and 64 by swapping the
buggy and fixed defines on the same kernel, and exercised the FIFO and
trigger paths on that board.

I will wait for more review before sending v6.

Thanks,
Rupesh


On Mon, Aug 17, 2026 at 9:47 PM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Mon, Aug 17, 2026 at 08:07:22PM +0300, Rupesh Majhi wrote:
> > The dps310 has no buffer support today. This series adds it, with the
> > hardware FIFO used when no external trigger is attached and the FIFO
> > left disabled in favor of the trigger when one is, so the switch between
> > the two modes can be reviewed together rather than in two submissions.
> >
> > Patch 1 fixes the CFG_REG bit definitions and replaces the standalone
> > fix I sent on 27 July, which Jonathan asked me to fold in here instead:
> >
> >   Link: https://lore.kernel.org/linux-iio/20260728223009.0cb86996@jic23-huawei/
> >
> > All three of those defines have been wrong since the driver was added,
> > but only P_SHIFT has a user and only that one misbehaves, so the patch
> > carries a Fixes tag for the original driver and one for the commit that
> > added the first user of P_SHIFT, along with Cc: stable. The FIFO enable
> > is needed by patch 3.
> >
> > The three INT_SEL interrupt enables at bits 6 to 4 are still not
> > defined. Nothing uses them, the driver has no interrupt path, and the
> > binding has no interrupts property, so adding unused defines to a fix
> > did not seem worth it. David also asked for the register defines to be
> > sorted low to high. That is a cleanup series of its own once this lands.
> >
> > Patch 2 adds the triggered buffer path.
> >
> > Patch 3 adds the hardware FIFO and the selection between it and an
> > attached trigger. Those started out as separate patches, but the branch
> > on iio_device_get_current_mode() is four lines and the FIFO patch is
> > wrong without it, since postenable would otherwise start the FIFO while
> > a trigger was driving the buffer. Splitting them would only have left a
> > broken commit in between, so they are one patch.
> >
> > Verified on an Infineon DPS310 breakout wired to a BeagleBone Black,
> > running this series on 7.2.0-rc2. Two modules built from the same tree,
> > differing only in the three CFG_REG defines corrected here, loaded
> > seconds apart. Three reads of in_pressure_input per oversampling ratio,
> > ambient 98.4 kPa and 27.2 degC:
> >
> >   OSR    before              after
> >     1    98.433  98.428      98.445  98.446
> >     8    98.460  98.460      98.477  98.479
> >    16    -ERANGE             98.566  98.564
> >    32    -ERANGE             98.428  98.427
> >    64    -ERANGE             98.464  98.463
> >   128    98.439  98.440      98.434  98.434
> >
> > Pressure oversampling 16, 32 and 64 return -ERANGE before the fix.
> > P_SHIFT is never enabled, so the result register no longer matches the
> > scale factor the compensation divides by, and
> > dps310_calculate_pressure() ends up negative. 128 is not affected in
> > practice. Temperature is unaffected throughout, since TMP_SHIFT_EN was
> > already defined correctly.
> >
> > Everything else was checked with checkpatch --strict and a W=1 build,
> > plus an arm build for aspeed_g5 and a boot under qemu-system-arm -M
> > rainier-bmc, which covers probe, the sysfs values, raw times scale
> > matching processed, EBUSY on sysfs reads while the buffer is enabled,
> > and all three scan mask combinations. QEMU's dps310 model implements
> > neither the FIFO nor the interrupt, so patch 3 was tested on the
> > BeagleBone Black above only.
> >
> > On hardware, patch 3 was checked with both channels enabled, temperature
> > only and pressure only, at 8 Hz and at 128 Hz. A blocking read returns
> > in every case, which is the part that needs the timer: with no
> > interrupt, hwfifo_flush_to_buffer alone would leave a reader asleep on
> > rb->pollq. At 128 Hz, 100 scans arrive in 0.81 s, so the batching is
> > real. Timestamps are monotonic throughout and land on the configured
> > period, 125.0000 ms at 8 Hz, except where a drain collected more than
> > the rate accounts for and the batch is compressed to stay ordered. With
> > a sysfs trigger attached the FIFO stays disabled and the trigger drives
> > the buffer, at the rate trigger_now is written.
>
> Are the commit messages are written with AI? Please, do it yourself.
> They are way too overloaded with unneeded noise and details. Make them
> to be straight to the point.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>