mbox series

[v4,0/5] Support ROHM BM1390 pressure sensor

Message ID cover.1695727471.git.mazziesaccount@gmail.com
Headers
Series Support ROHM BM1390 pressure sensor |

Message

Matti Vaittinen Sept. 27, 2023, 8:18 a.m. UTC 
  ROHM BM1390 Pressure sensor (BM1390GLV-Z) can measure pressures ranging
from 300 hPa to 1300 hPa with configurable measurement averaging and an
internal FIFO. The sensor does also provide temperature measurements
although, according to the data sheet, sensor performs internal
temperature compensation for the MEMS.

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.

I actually asked if we can define 3db frequencies corresponding to these
IIR filter settings - and I received values 0.452Hz, 0.167Hz, and 0.047Hz
but I am not at all sure we understood each others with the HW
colleagues... Hence, the IIR filter configuration is not supported by this
driver and the filter is just configured to the "middle" setting.
(at least for now)

It would also be possible to not use IIR filter but just do some simple
averaging. I wonder if it would make sense to implement the OVERSAMPLING
value setting so that if this value is written, IIR filter is disabled and
number of samples to be averaged is set to value requested by
OVERSAMPLING. The data-sheet has a mention that if IIR is used, the
number of averaged samples must be set to a fixed value.

The FIFO measurement mode (in sensor hardware) 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.

Revision history:
Major changes here, please see the head room of individual patches for
more detailed list.
v3 => v4:
	rebased back on v6.6-rc1
	dropped patch implementing the exact match search for
	available_scan_mask
	tools: iio_generic_buffer: comment on aligning logic
	bm1390 driver:
	 - cleanups and fixes
         - own info struct for case where IRQ is omitted and FIFO not
           supported
	 - fix support for using other triggers. (not really tested but
	   should work)

v2 => v3:
	rebased on v6.6-rc2
	added three IIO fixup patches so numbering of patches changed
	dt-bindings/MAINTAINERS: No changes
	bm1390 driver:
	 - various cleanups and fixes
	 - do not disable IRQ
	 - fix temperature reading when FIFO is used
	 - separate buffer and trigger initialization

v1 => v2:
	rebased on v6.6-rc1
	dt-bindings:
	  - fix compatible in the example
	sensor driver:
	  - drop unnecessary write_raw callback
	  - plenty of small improvements and fixes
	MAINTAINERS:
	  - No changes

Matti Vaittinen (5):
  tools: iio: iio_generic_buffer ensure alignment
  iio: improve doc for available_scan_mask
  dt-bindings: Add ROHM BM1390 pressure sensor
  iio: pressure: Support ROHM BU1390
  MAINTAINERS: Add ROHM BM1390

 .../bindings/iio/pressure/rohm,bm1390.yaml    |  52 +
 MAINTAINERS                                   |   6 +
 drivers/iio/pressure/Kconfig                  |   9 +
 drivers/iio/pressure/Makefile                 |   1 +
 drivers/iio/pressure/rohm-bm1390.c            | 934 ++++++++++++++++++
 include/linux/iio/iio.h                       |   4 +-
 tools/iio/iio_generic_buffer.c                |  18 +-
 7 files changed, 1022 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/pressure/rohm,bm1390.yaml
 create mode 100644 drivers/iio/pressure/rohm-bm1390.c


base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d

Comments

Andy Shevchenko Sept. 27, 2023, 12:27 p.m. UTC | #1 
On Wed, Sep 27, 2023 at 11:26:07AM +0300, Matti Vaittinen wrote:
> The iio_generic_buffer can return garbage values when the total size of
> scan data is not a multiple of the largest element in the scan. This can be
> demonstrated by reading a scan, consisting, for example of one 4-byte and
> one 2-byte element, where the 4-byte element is first in the buffer.
> 
> The IIO generic buffer code does not take into account the last two
> padding bytes that are needed to ensure that the 4-byte data for next
> scan is correctly aligned.
> 
> Add the padding bytes required to align the next sample with the scan size.

...

> +	/*
> +	 * We wan't the data in next sample to also be properly aligned so

Pardon me, won't or want, I didn't get?..

> +	 * we'll add padding at the end if needed.
> +	 *
> +	 * Please note, this code does ensure alignment to maximum channel
> +	 * size. It works only as long as the channel sizes are 1, 2, 4 or 8
> +	 * bytes. Also, on 32 bit platforms it might be enough to align also

32-bit

> +	 * the 8 byte elements to 4 byte boundary - which this code is not

8-byte
4-byte

> +	 * doing.
> +	 */