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

[Jonathan Cameron <jic23@kernel.org>]

On Fri, 7 Nov 2025 02:30:33 +0200
Petre Rodan <petre.rodan@subdimension.ro> wrote:

> 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.

Does the datasheet document that relationship? Table 4 on the datasheet I looked
at to seems to give settling time but I think is only relevant to low power
modes that might not apply here.

Would be very odd if there is no way to establish the sampling frequency from
the settings configured.

> 
> > > 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?

ABI is fixed the day it is defined and I'm not keen to have what sounds like
a duplicate ABI.  We also need to if even vaguely possible have consistency across sensors.
If you do it on basis of range set, and one sensor oddly provides twice the range
of another, then a 5 on one is a 10 on that other.

Hence the only things where we can do this sort of percentage thing are where
the thing being controlled is a unit less ratio and hence a percentage type
control is the only possible units.

Thanks,

Jonathan


> 
>  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