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

[ASSI <Stromeko@nexgo.de>]

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.

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.

> 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.

>> 
>> > 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.

> 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.  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.

> 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.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+