Re: [PATCH v2 2/3] iio: pressure: Support ROHM BU1390

From: Matti Vaittinen
Date: Tue Sep 19 2023 - 07:28:40 EST

Next message: Like Xu: "Re: [PATCH v6] KVM: x86/tsc: Don't sync user-written TSC against startup values"
Previous message: Sumit Gupta: "Re: [Patch v2 0/2] Improvements to the Tegra CPUFREQ driver"
In reply to: Matti Vaittinen: "Re: [PATCH v2 2/3] iio: pressure: Support ROHM BU1390"
Next in thread: Jonathan Cameron: "Re: [PATCH v2 2/3] iio: pressure: Support ROHM BU1390"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On 9/18/23 15:56, Matti Vaittinen wrote:

On 9/17/23 13:35, Jonathan Cameron wrote:

On Fri, 15 Sep 2023 09:56:19 +0300
Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:

Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure
pressures ranging from 300 hPa to 1300 hPa with configurable measurement
averaging and internal FIFO. The sensor does also provide temperature
measurements.

Sensor does also contain IIR filter implemented in HW. The data-sheet
says the IIR filter can be configured to be "weak", "middle" or
"strong". Some RMS noise figures are provided in data sheet but no
accurate maths for the filter configurations is provided. Hence, the IIR
filter configuration is not supported by this driver and the filter is
configured to the "middle" setting (at least not for now).

The FIFO measurement mode is only measuring the pressure and not the
temperature. The driver measures temperature when FIFO is flushed and
simply uses the same measured temperature value to all reported
temperatures. This should not be a problem when temperature is not
changing very rapidly (several degrees C / second) but allows users to
get the temperature measurements from sensor without any additional logic.

This driver allows the sensor to be used in two muitually exclusive ways,

1. With trigger (data-ready IRQ).
In this case the FIFO is not used as we get data ready for each collected
sample. Instead, for each data-ready IRQ we read the sample from sensor
and push it to the IIO buffer.

2. With hardware FIFO and watermark IRQ.
In this case the data-ready is not used but we enable watermark IRQ. At
each watermark IRQ we go and read all samples in FIFO and push them to the
IIO buffer.

Signed-off-by: Matti Vaittinen <mazziesaccount@xxxxxxxxx>

...

+
+static const unsigned long bm1390_scan_masks[] = {
+ BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP), 0

Why? Doesn't look hard to support just one or the other?
Normally we only do this sort of limitation when there is a heavily
optimized read routine for a set of channels and it is better
to grab them all and throw away the ones we don't care about.
That doesn't seem to be true here. So if the fifo grabbed both
temp and pressure it would makes sense here, but doesn't seem
like it does.

I have a feeling I have misunderstood how this mask works. I have assumed all the channels with corresponding mask bit _can_ be enabled simultaneously, but I have not understood they _must_ all be enabled. I think I must go back studying this, but if all channels really _must_ be enabled, then you are correct. It actually makes a lot of sense to support the pressure values alone, as, according to the data-sheet, the HW is doing a "MEMS temperature compensation" to the pressure values. So, my assuimption is the temperature data may not be required to be captured.

This also means I should revise the scan masks for the BU27008, BU27010 and BU27034 light sensors as I don't think all the users want all the channels enabled. I wonder how I have not noticed any problems when I tested those things - did I really always enable all the channels...? @_@

Anyways, Thanks.

Hi Jonathan,

There's something in IIO scan_masks / buffer demuxing that I don't quite understand. I noticed following things:

1) Strict available scan mask check seems to be in use only for INDIO_BUFFER_HARDWARE stuff.

https://elixir.bootlin.com/linux/v6.6-rc2/source/drivers/iio/industrialio-buffer.c#L881

So, the:

>>> +static const unsigned long bm1390_scan_masks[] = {
>>> + BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP), 0

is not exclusive for BM1390 as long as it is not setting the INDIO_BUFFER_HARDWARE.

My test seems to agree with the code:

// Only enable the temperature:
root@arm:/sys/bus/iio/devices/iio:device0# echo 1 > scan_elements/in_temp_en

// Run the geneeric buffer without -a:
root@arm:/sys/bus/iio/devices/iio:device0# /iio_generic_buffer -c 20 -N 0 -t bm1390data-rdy-dev0
iio device number being used is 0
iio trigger number being used is 0
/sys/bus/iio/devices/iio:device0 bm1390data-rdy-dev0
23000.000000
23000.000000
23000.000000
23000.000000
23000.000000
23000.000000
23000.000000
23000.000000
23000.000000
22968.750000
23000.000000
23000.000000
23000.000000
23000.000000
23000.000000
23000.000000
23000.000000
23000.000000
23000.000000
23031.250000
23000.000000
23000.000000
root@arm:/sys/bus/iio/devices/iio:device0#

In above case the temperature values and only the temperature values were shown. I must admit I did not spend enough time with the iio_generic_buffer.c or IIO demuxing code to really understand all the details (I got headache very quickly ;) ). I still believe the iio_generic_buffer expects to see only the enabled channel data in the buffer - so, it seems to me the kernel is also only adding the enabled channel data to the buffer. Also, judging the values, the demuxing is correctly extracting the temperature data from data the driver pushes here:

iio_push_to_buffers_with_timestamp(idev, &data->buf, data->timestamp);

The bm1390 driver as sent in v2 does not do demuxing but always pushes whole chunk of data and trusts IIO to do demuxing.

2) I noticed the 'available_scan_masks' was marked as an optional field. So, I think that if there is no restrictions to which of the channels can be enabled, then we can omit setting it. This is what I tried.

It appears that when we do not populate the 'available_scan_masks' with the:
>>> +static const unsigned long bm1390_scan_masks[] = {
>>> + BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP), 0

things change. When I tested enabling only temperature and ran the iio_generic_buffer -c 20 -N 0 -t bm1390data-rdy-dev0 - the reported values seemed completely random.

When I initialized the pressure data in driver:
data->buf.pressure = 1;
before doing the:
iio_push_to_buffers_with_timestamp(idev, &data->buf, data->timestamp);

I saw following:

root@arm:/# cd /sys/bus/iio/devices/iio\:device0
root@arm:/sys/bus/iio/devices/iio:device0# echo 1 > scan_elements/in_temp_en
root@arm:/sys/bus/iio/devices/iio:device0# /iio_generic_buffer -c 20 -N 0 -t bm1390data-rdy-dev0
iio device number being used is 0
iio trigger number being used is 0
/sys/bus/iio/devices/iio:device0 bm1390data-rdy-dev0
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
8000.000000
root@arm:/sys/bus/iio/devices/iio:device0# cat in_temp_scale
31.250000

If we calculate 8000/31.250000 we will get value 256. This looks like value '1' in BE16 format.

Based on this experimenting (and headache obtained from reading the demuxing code) - the IIO framework does not do channel demuxing if the 'available_scan_masks' is not given? To me this was somewhat unexpected.

Finally, when the watermark IRQ is used, we can't omit reading the pressure data because clearing the WMI is done based on the pressure data in FIFO.

So, I would propose we do:

static const unsigned long bm1390_scan_masks[] = {
BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP),
BIT(BM1390_CHAN_PRESSURE), 0

which better reflects what the hardware is capable of - and, unless I am missing something, also allows us to offload the buffer demuxing to the IIO.

Still, as mentioned in 1), the

>>> +static const unsigned long bm1390_scan_masks[] = {
>>> + BIT(BM1390_CHAN_PRESSURE) | BIT(BM1390_CHAN_TEMP), 0

does not seem to prevent enabling only the temperature channel - so in the driver buffer handler we still must unconditionally read the pressure data regardles the active_scan_mask.

+     * called as a result of a read operation from userspace and hence
+     * before the watermark interrupt was triggered, take a timestamp
+     * now. We can fall anywhere in between two samples so the error in this
+     * case is at most one sample period.
+     * We need to have the IRQ disabled or we risk of messing-up
+     * the timestamps. If we are ran from IRQ, then the
+     * IRQF_ONESHOT has us covered - but if we are ran by the
+     * user-space read we need to disable the IRQ to be on a safe
+     * side. We do this usng synchronous disable so that if the
+     * IRQ thread is being ran on other CPU we wait for it to be
+     * finished.

That irq disable is potentially expensive.
Why not just pass the current timestamp into the __bm1390_fifo_flush >
The locks should prevent other races I think..

Gah. I hate you Jonathan ;) (Not really!)

Actually, thank you (as always) for pointing this out. I don't instantly see why it wouldn't work, but going throught the IRQ races is never trivial (for me). It's work I've learned not to do at afternoon as my brains work better at the morning :) So, I will still go through this as a first thing tomorrow when I start my work day...

After staring this for a while, I see no reason why we couldn't do as you suggested. Thanks! It really improves this :)

Yours,
-- Matti

--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

Next message: Like Xu: "Re: [PATCH v6] KVM: x86/tsc: Don't sync user-written TSC against startup values"
Previous message: Sumit Gupta: "Re: [Patch v2 0/2] Improvements to the Tegra CPUFREQ driver"
In reply to: Matti Vaittinen: "Re: [PATCH v2 2/3] iio: pressure: Support ROHM BU1390"
Next in thread: Jonathan Cameron: "Re: [PATCH v2 2/3] iio: pressure: Support ROHM BU1390"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]