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

[David Lechner <dlechner@baylibre.com>]

On 6/28/25 1:45 PM, ASSI wrote:
> Vasileios Amoiridis writes:
>> The idea is that the sensor is by default in sleep mode, wakes up in
>> forced mode when a oneshot capture is requested, or in normal mode
>> when the buffer is enabled. The difference lays in the fact that in
>> forced mode, the sensor does only one conversion and goes back to sleep
>> while in normal mode, the sensor does continuous measurements with the
>> frequency that was set in the ODR registers.
>>
>> The bmpX_chip_config() functions which are responsible for applying
>> the requested configuration to the sensor, are modified accordingly
>> in order to set the sensor by default in sleep mode.
> 
> Since this change went into 6.13, I've been unable to update the kernel
> since it breaks usermode quite badly for me.  I am using sysfs to read a
> BME280 sensor every second (oversampling is set to 1, so there should be
> no trouble at all to read at that rate) and most of the time the
> measurement doesn't complete and I get back an error message instead of
> the expected reading.  The journal is full of these:
> 
> Jun 28 08:19:16 Otto kernel: bmp280 1-0076: Measurement cycle didn't complete.
> Jun 28 08:19:16 Otto kernel: bmp280 1-0076: Measurement cycle didn't complete.
> Jun 28 08:19:16 Otto kernel: bmp280 1-0076: Measurement cycle didn't complete.
> 
> The exact same thing happens if I stop the process that's reading the
> sensor every second and do a manual read at much longer intervals, so
> it's indeed not the read rate, but rather that the driver apparently
> doesn't wait long enough for the measurement to complete.  There is an
> indication that the wait time is just slightly too short as I have a
> somewhat higher success rate at reading every second when the load is
> higher.  Addtionally the read time for all three values from the sensor
> went from ~7ms to ~28ms with much stronger tailing to longer read times
> than before.  This sensor is in daisy-chain with a DS3231M RTC and hangs
> off the DDC of the unsused VGA port provided by an Intel IGP.
> 
> I've not found a way to switch the operations mode via sysfs and/or
> enable the ring buffer, which may or may not solve the problem depending
> on which mode is used when the trigger arrives.  That's mainly because I
> couldn't find a complete example of how to use this facility and I've
> likely done some of the steps in the wrong order or missed one.  I've
> enabled the scan elements, but trying to enable the buffer tells me
> "write error: Invalid argument".  For starters, the system I'm on
> (openSUSE Tumbleweed) doesn't seem to have IIO trigger support enabled
> via either configfs or sysfs.  But in any case I think oneshot capturing
> from userland should still work, I just haven't found out how.
> 
> So is there some description of how to get the sysfs functionality as
> before and/or switch the operations mode to avoid this failure?  The
> easiest would be if the BME280_MEAS_OFFSET value was configurable, but
> it's a #DEFINE at the moment.
> 
> 
> Regards,
> Achim.

If this change broke your code, we need to fix it in the kernel, so
thanks for reporting the regression.

It looks like the wait time calculations in bmp280_wait_conv() don't
match up with the datasheet [1] that I found.

[1]: https://cdn-shop.adafruit.com/datasheets/BST-BMP280-DS001-11.pdf

There, table 13 says that if pressure and temperature oversampling
are bot set to x1, then it could take up to 6.4 ms to complete the
measurement.

However, in the code, we have:

```
#define BMP280_MEAS_OFFSET		1250
#define BMP280_MEAS_DUR			2300
#define BMP280_PRESS_HUMID_MEAS_OFFSET	575
```

and 

```
	/* Check if we are using a BME280 device */
	if (data->oversampling_humid)
		meas_time_us = BMP280_PRESS_HUMID_MEAS_OFFSET +
				BIT(data->oversampling_humid) * BMP280_MEAS_DUR;

	else
		meas_time_us = 0;

	/* Pressure measurement time */
	meas_time_us += BMP280_PRESS_HUMID_MEAS_OFFSET +
			BIT(data->oversampling_press) * BMP280_MEAS_DUR;

	/* Temperature measurement time */
	meas_time_us += BIT(data->oversampling_temp) * BMP280_MEAS_DUR;

	/* Waiting time according to the BM(P/E)2 Sensor API */
	fsleep(meas_time_us);
```

Assuming BIT(*oversampling*) is 1 for x1 oversampling, we get

meas_time_us = (0) + (575 + 1 * 2300) + (1 * 2300) = 5175
               ^     ^                  ^
               |     |                  |
               |     |                  temperature
               |     pressure
               humidity

5175 microseconds is less than the 6.4 milliseconds max time, so
that would explain the error that is seen since the error is
triggered by the status bit that says the chip is still busy taking
the measurement.

BMP280_MEAS_OFFSET is unused in the code. But 6400 - 5175 is 1225
which is very close to 1250. So I think the intention was to include
that it the calculation like this:

---
diff --git a/drivers/iio/pressure/bmp280-core.c b/drivers/iio/pressure/bmp280-core.c
index 74505c9ec1a0..50c869e3d5c9 100644
--- a/drivers/iio/pressure/bmp280-core.c
+++ b/drivers/iio/pressure/bmp280-core.c
@@ -1042,14 +1042,13 @@ static int bmp280_wait_conv(struct bmp280_data *data)
 	unsigned int reg, meas_time_us;
 	int ret;
 
+	meas_time_us = BMP280_MEAS_OFFSET;
+
 	/* Check if we are using a BME280 device */
 	if (data->oversampling_humid)
-		meas_time_us = BMP280_PRESS_HUMID_MEAS_OFFSET +
+		meas_time_us += BMP280_PRESS_HUMID_MEAS_OFFSET +
 				BIT(data->oversampling_humid) * BMP280_MEAS_DUR;
 
-	else
-		meas_time_us = 0;
-
 	/* Pressure measurement time */
 	meas_time_us += BMP280_PRESS_HUMID_MEAS_OFFSET +
 			BIT(data->oversampling_press) * BMP280_MEAS_DUR;
---

Hopefully you can compile your own kernel and test this. If that fixes it
we can turn it into a proper patch.