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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

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