Re: [PATCH v6 5/6] iio: pressure: dps310: add hardware FIFO support

[Jonathan Cameron <jic23@kernel.org>]

On Thu, 17 Sep 2026 00:02:23 +0300
Rupesh Majhi <zoone.rupert@gmail.com> wrote:

> On Thu, 10 Sep 2026 03:36:36 +0100
> Jonathan Cameron <jic23@kernel.org> wrote:
> 
> > Maybe we just set the minimum allowed watermark to something that
> > in practice always has a temperature (or almost does)? It's kind
> > of true that a watermark below that doesn't work because we end
> > up dropping data.  
> 
> Two temperature entries are prs_rate / tmp_rate pressure entries apart, so
> a batch needs one more than that before it is sure of catching one. The
> FIFO holds 32, so there is no such watermark once the ratio reaches 32.
> That is six of the 64 rate pairs, and one of them is pressure 32 Hz with
> temperature 1 Hz, the case that found this, which would want 33.

Ah.  So if we did go this way we'd need to cap the ratio to be sure of getting
them fast enough to always be available. Doing so doesn't sound too bad...

> 
> So I will hold them locally instead, which is what you asked for first. The
> drain timer runs at half the fill time, so nothing overflows while the
> driver waits, and the hold lasts only until the first temperature of the
> session, bounded by the rate ratio at 128 entries. The first push still
> waits for that temperature, but only once per enable, and no pressure entry
> is dropped. I will re-run the zero output regression against it.

Ok. So we get some lag if that ratio is big. Not ideal but not too bad.
> 
> > Validity flag in the data we push to userspace?  That never works because
> > we don't have a universal encoding for one.  
> 
> I meant driver state, not a channel. Moot now.
> 
> Rupesh

Jonathan