Re: [PATCH 3/6] iio: accel: bma220: add tap detection

[Petre Rodan <petre.rodan@subdimension.ro>]

[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]

On Sun, Nov 02, 2025 at 12:20:53PM +0000, Jonathan Cameron wrote:
> On Sat, 1 Nov 2025 09:56:42 +0200
> Petre Rodan <petre.rodan@subdimension.ro> wrote:
> 
> > Hello Jonathan,
> > 
> > thank you for the review.
> > 
> > On Sat, Oct 18, 2025 at 06:16:32PM +0100, Jonathan Cameron wrote:
> > > > +			ret = regmap_read(data->regmap, BMA220_REG_CONF3, &reg_val);
> > > > +			if (ret)
> > > > +				return ret;
> > > > +			*val = FIELD_GET(BMA220_TT_DUR_MSK, reg_val);  
> > > 
> > > This needs to be in second if you are using duration. Is the register really in seconds?  
> > 
> > this IC has a very small number of bits that configure
> > duration/hysteresis/threshold levels. it's between 2 and 6 for each
> > of them. in the case of high and low G events the duration is not
> > even directly defined as a time interval, but as a count of samples
> > that are over a threshold value.
> 
> The ABI is in seconds, so you have to deal with scaling wrt to the sampling
> frequency at the time.  I know it can be a pain to do, but consistent userspace
> is the aim and so we need to match the ABI.

on this bma220 chip, when someone modifies the cut off frequency of the filter then the ic automatically adjusts the sampling rate. and this sample rate is not exposed on any of the registers.
since duration parameters are defined as a count of samples and the sample rate looks to be unknown I don't see how I could adapt to an API that is based on a unit of seconds.

> > I was hoping that simply passing along a unitless value between 0 and
> > parameter_max would be enough to customize all the event parameters.
> > this does mean that the driver makes the assumption that the user is
> > familiar with the device datasheet and knows the number of bits every
> > parameter has been allocated. should the driver provide a conversion
> > table for tt_duration just like for _scale_table and
> > _lpf_3dB_freq_Hz_table?
> 
> Exactly.

I was thinking today of a more analog-feeling API, one in which a variable that can take values linearly between min and max can be set to a percentage of it's scale. think of stereo systems - most of us don't want to set a precise amount of decibels of attenuation when operating the volume knob, we just want to set it lower or higher until a condition matches. in this API the primary unit of measurement would not be dBs but notches or ticks - calculated based on min, max and the native resolution of the control (how many bits are allocated for it in the ic's memory map). this has also the benefit of translating nicely when the control is rendered as a widget in a GUI. think about a 0 to 11 volume knob.
is there anything like this already implemented? is there any merit to this idea?

 I will shelve the event part of this driver for another time, just got some Honeywell pressure sensors that need a new driver.

best regards,
peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]