Re: [bmp280 v1 3/6] iio: pressure: bmp280: implement sampling_frequency for BMx280

[Jonathan Cameron <jic23@kernel.org>]

On Sun, 10 Aug 2025 21:12:25 +0200
ASSI <Stromeko@nexgo.de> wrote:

> Jonathan Cameron writes:
> > Call it BMP280_ODR_MODE_FORCED rather than making it 0HZ related?
> > Using the value 0 for the sysfs interface doesn't make much sense though.  
> 
> Technically 0Hz is correct, though:  it dosn't cycle at all until we
> tell it to do a single measurement.

For cases where we 'trigger' an event we normally use sampling frequency
to be 1/(total time to capture a set of readings)  Idea being it's
the frequency at which you get results if you immediately trigger
another one.  Doing that here doesn't correspond to 0Hz.

Main problem is no standard userspace code is going to understand
a value of 0Hz as that effectively means no readings ever.

> 
> > Even if it is a pain to work out, we should estimate what it means to
> > use force mode wrt to how fast a single sample can be obtain.  
> 
> MODE_FORCED just doesn't work well ffor devices that do mukltiple
> measurements at once that then need to be read one by one.  At least not
> by using the sysfs read request as the trigger for the measurement,
> which is what the earlier patch did that went into v6.13

I understand it works poorly under at least some circumstances. It's
just the issue of 0Hz not being a way people would expect to control this
or how any other driver does it.

> 
> > It may be that is such that we don't bother with the other slow sampling
> > frequency modes if they are slower as they aren't useful vs only reading
> > when we want to.  
> 
> The way these devices work is that you can read the result of the
> last measurement as often as you want and in any order, even while
> there's another measurement is in progress; and you can chose to have
> free-running measurements or host triggered ones.  It's the current sysfs
> implementation that enforces a rigidity that wasn't there before the
> driver was changed to make the device sleep between measurements.

Okay, with that in mind...

Another approach might be to stash the timestamp of the last 'forced'
event and if it is 'sufficiently' recent just go with the readings of
other channels grabbed at that time. If it's not we pay the cost of
another read cycle.  That's close to doing a runtime pm autosuspend
on many other sensors where we take the view that if no one asked
for a while, we will pay the cost of a new power up and hence put the
sensor to sleep.

Hooking a single forced capture up to a hrtimer trigger would also
be somewhat similar to this but the interface to userspace is
rather more different so perhaps not the right way to think about it
here.

Jonathan


> 
> 
> Regards,
> Achim.