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

[Jonathan Cameron <jic23@kernel.org>]

On Tue, 12 Aug 2025 21:53:00 +0200
ASSI <Stromeko@nexgo.de> wrote:

> Jonathan Cameron writes:
> > 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.  
> 
> From the device point of view the setting _is_ 0Hz.  That you are going
> to read it back-to-back is not something it can know.

We can argue this for ever and there is lots of precedence
of treating on demand sensor sampling frequency as 1/period.
(though seems we haven't documented that which isn't great - see reference
later).

> 
> There is one more problem with your idea: since that parameter is the
> only way to switch between modes, implementing it you way would mean
> that MODE_NORMAL+t_stby=0 would map to the same frequency as MODE_FORCED
> and then we're back to square one that there is no parameter to tell us
> which mode we want.

That's a fair point that I'd missed. I was kind of assuming there was
a power up time that made the (pseudo)frequency for MODE_FORCED a
good bit less than the the MODE_NORMAL case which thinking  more on it
would have put it in the middle of the MODE_NORMAL cases so not
helpful either.

> 
> > Main problem is no standard userspace code is going to understand
> > a value of 0Hz as that effectively means no readings ever.  
> 
> I am "userspace" and I well enough that I'm going to get one sample per
> read.

You are writer of one specific bit of userspace code. 
If you look at a generic application like the stuff ADI builds on top
of IIO then that is going to be a very odd value to see.

> 
> >>   
> >> > 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.  
> 
> Beside any other driver (which I've not looked at), you're willing to
> break an existing one?  Because no existing userspace that use this
> driver will be working past that change.

Existing code doesn't use sampling frequency and works, though slowly
after that power saving related change.  It was the wrong default
choice but we missed it at the time - probably because both the author
and reviewers were thinking slow reads where the only thing likely
to be required by users of this device (see later). We should have
stuck to the periodic sampling unless we detected (runtime pm
autosuspend probably) that we were not doing frequent reads.

> 
> > 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.  
> 
> I've actually looked at that and found it lacking.  That just makes
> MODE_FORCED a permanent thing that totally ignores that the sensor is
> supposed to be operated in free-running MODE_NORMAL in many
> applications.

An additional feature would be to detect repeated reads
and deciding to to autoswitch out of mode forced (probably on second read
of a channel within a short period).

> MODE_FORCED really is for things like wheather stations
> where it gets woken up onece every few minutes.  As long as there is no
> separate attribute or module parameter to switch between operation
> modes, this would be removing exactly the functionality that I want to
> use.

Ok.  I misunderstood this.  It's not that you want to grab
all the channels quickly (but only do that infrequently) it's that you
want to do measurement of rapidly changing pressure?  That's fair enough
as a use case, I just wasn't expecting to see it for this part (vs the
ones that have pipe connectors or similar)

> 
> > 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.  
> 
> I haven't been able to get this to work, I've never got a reading out of
> the buffer.  I'll try again once the distribution I#m using has enabled
> sysfs triggers, which are easier to test with hopefully.
Ok. Lets park that one for now.  This isn't a case where we have to get
readings at the same time for multiple channels to be useful, they just
need for your usecase not to be too far apart. So buffered support isn't
urgent.

Given the situation I'll accept the slight oddity of a 0Hz sampling_frequency.
It may confuse some software but as long as the default is sensible
sampling frequency isn't (I believe) that commonly tweaked for sysfs
reads anyway.  Tends to be much more relevant with high speed buffered
capture.

Hmm. Seems I let an exception for this in once before. Sorry had forgotten
that until I was wondering what docs update we need.

https://elixir.bootlin.com/linux/v6.16/source/Documentation/ABI/testing/sysfs-bus-iio#L112

So can you add a note to that doc covering this case (can be a follow up
patch if everything else is fine for v2)?

Sometimes these corner cases take a bit of arguing out. Thanks for
your patience!

Thanks,

Jonathan




> 
> 
> Achim.