Re: [PATCH v3 0/5] iio: magnetometer: add driver for QST QMC5883P

[Hardik Phalet <hardik.phalet@pm.me>]

On Mon Apr 20, 2026 at 7:15 PM IST, Jonathan Cameron wrote:
> On Sun, 19 Apr 2026 22:32:09 +0000
> Hardik Phalet <hardik.phalet@pm.me> wrote:
>
>> This series adds an IIO driver for the QST QMC5883P, a 3-axis
>> anisotropic magneto-resistive (AMR) magnetometer with a 16-bit ADC,
>> communicating over I2C. To my knowledge there is no existing
>> upstream driver for this device (see "Prior-art register-map check"
>> below).
>>
>> The driver supports:
>>   - Raw magnetic field readings on X, Y and Z axes
>>   - Four full-scale ranges (+/-2 G, +/-8 G, +/-12 G, +/-30 G),
>>     selectable via IIO_CHAN_INFO_SCALE
>>   - Four output data rates (10, 50, 100, 200 Hz), selectable via
>>     IIO_CHAN_INFO_SAMP_FREQ
>>   - Four oversampling ratios (1, 2, 4, 8), selectable via
>>     IIO_CHAN_INFO_OVERSAMPLING_RATIO
>
> I'm suspicious about this one based on a very quick read of the datasheet.
> Conventional oversampling would involve running the internal sampling
> engine at a multiple of the sampling frequency, and then averaging the
> results.  The datasheet describes this as:
> "Over sample Rate (OSR1) registers are used to control bandwidth of an
>  internal digital filter. Larger OSR value leads to smaller filter bandwidth,
>  less in-band noise and higher power consumption. It could be used to reach a
>  good balance between noise and power. Four over sample ratios can be selected,
>  8,4,2 or 1."
>
> That sounds like a boxcar filter to me not oversampling (which would be
> a combination of box car and reducing the output data rate).
>
> If possible, can you enable the data ready output and put a scope on it
> to see if that changes frequency when OSR or OSR2 are modified.
>
> Trickier to do would be looking at the noise levels whilst playing with
> these filters and see if they at least match with standard filter types.
>
> If we can't figure these out, then it may be a case of picking something
> that works well and hard coding that rather than letting userspace
> change things in a fashion that might not match the ABI.

I could not arrange a oscilloscope. So wrote a small standalone tool that drives
the chip directly over /dev/i2c-N (skipping the driver) on a Pi 4 and
characterised all three fields in CTRL_1 with timing + noise measurements.
Summary:

  Field    Bits     Role per measurement
  ODR      [3:2]    output rate, accurate to ~3% of nominal in Normal Mode
  OSR1     [5:4]    low-pass filter (bandwidth control), no rate change
  OSR2     [7:6]    N-sample averaging, no rate change (real oversampling)

1. DRDY interval vs each field (median of 500 samples per setting,
   ms; SCHED_FIFO, pinned CPU):

   vary ODR (OSR1=1, OSR2=1):
     ODR=10 Hz  -> 100.9 ms       ODR=100 Hz -> 10.30 ms
     ODR=50 Hz  ->  20.5 ms       ODR=200 Hz ->  5.14 ms

   vary OSR1 (ODR=200 Hz, OSR2=1):
     OSR1=1 -> 5.142 ms           OSR1=4 -> 5.139 ms
     OSR1=2 -> 5.143 ms           OSR1=8 -> 5.141 ms

   vary OSR2 (ODR=200 Hz, OSR1=1):
     OSR2=1 -> 5.142 ms           OSR2=4 -> 5.142 ms
     OSR2=2 -> 5.140 ms           OSR2=8 -> 5.141 ms

   ODR is the only knob that changes the rate.

2. Per-axis noise stddev (2000 samples, sensor still, ratios vs N=1):

   vary OSR1:                   vary OSR2:
     OSR1=1 -> 1.000              OSR2=1 -> 1.000
     OSR1=2 -> 0.723              OSR2=2 -> 0.706
     OSR1=4 -> 0.544              OSR2=4 -> 0.494
     OSR1=8 -> 0.416              OSR2=8 -> 0.333

   Reference for N-sample averaging (1/sqrt(N)):
     1.000 / 0.707 / 0.500 / 0.354

   OSR2 matches within measurement noise; OSR1 trails the curve,
   which is the expected signature of a bandwidth-limiting filter
   on non-white input noise.

So to my understanding, OSR2 is true oversampling. OSR1 is a filter.

v4 plan, pending your input on (c):

  (a) Add an OSR2 regmap_field and expose it as
      IIO_CHAN_INFO_OVERSAMPLING_RATIO with values {1, 2, 4, 8}.
  (b) Drop the OVERSAMPLING_RATIO mapping on OSR1.
  (c) For OSR1, two options:
        i)  expose as IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY.
            The public datasheet does not give cutoff frequencies,
            so I'd have to either characterise them empirically and
            document them in the driver, or use placeholder values
            derived from the OSR1 setting alone (which feels wrong).
        ii) hard-code OSR1=1 in chip_init and not expose it. Loses
            the noise-vs-bandwidth tradeoff but keeps the ABI clean.
      Slight preference for (ii) unless you'd rather see the filter
      knob exposed.
  (d) Keep ODR mapped to IIO_CHAN_INFO_SAMP_FREQ as in v3.

One other finding worth mentioning: the datasheet's setup examples
(sec 7.1, 7.2, 7.3) all write 0x06 to register 0x29 before entering
an active mode, with the comment "Define the sign for X Y and Z axis".
This register is not listed in the documented register map but the
write is required for axes Y and Z to come out with the documented
orientation. v4 will add this write to chip_init().

If you have other measurements you'd like to see before v4, happy to
run them.

>
>>   - Runtime PM with a 2 s autosuspend delay
>>   - System suspend/resume delegated to the runtime callbacks

Best regards,
Hardik