Re: [PATCH v9 1/4] iio: pressure: bmp280: Use sleep and forced mode for oneshot captures

[ASSI <Stromeko@nexgo.de>]

ASSI writes:
[…]

I've been running with this patch for two weeks now and even updated to
another kernel.  Unfortunately Tumbleweed does not provide the sysfs
trigger device, but I could enable a HRT trigger device via configfs.  I
did not get this to work however, for stzartes I have no diea if I need
to enable both the buffer and buffer0 provided via sysfs:

--8<---------------cut here---------------start------------->8---
/sys/bus/iio/devices/iio:device0/buffer:
data_available  direction  enable  length  watermark

/sys/bus/iio/devices/iio:device0/buffer0:
data_available  enable                  in_humidityrelative_index  in_pressure_en     in_pressure_type  in_temp_index  in_timestamp_en     in_timestamp_type  watermark
direction       in_humidityrelative_en  in_humidityrelative_type   in_pressure_index  in_temp_en        in_temp_type   in_timestamp_index  length
--8<---------------cut here---------------end--------------->8---

After setting up the trigger and enabling the channels in scan_elements
I ended up enabling both, which had the effect that the forced readings
via the processed endpoints stopped working for pressure and humidity
(which is probably because the channel config is left in that state
somehow), but no values were ever appearing at the /dev/iio0 endpoint
that got created.  I also didn't manage to disable the buffers again and
got an EBUSY instead.  I needed to remove the driver and re-insert it to
get out of this mode.  Anyway it seems I should not mix triggered and
forced operation anyway as it seems that triggered operation requires
the device to stay in normal mode.

I have one other idea to get back at the short(er) aquisition times I
had previously: since triggered and forced operation can't be mixed, it
would be possible to use the timestamp fields to record the last
aquisition, always aquire all channels and only actually force a new
measurement if some time has elapsed after that, like another full
measurement cycle time based on the current oversampling configuration.
THe other option would be to actually enable the sampling frequency
parameter that must be converted into a t_standby setting for the BMx280
devices, as hinted at in the header file, but not actually implemented
yet (or mis-use that field directly for the standby time).


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