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

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
<[email protected]> 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
>
>