Message-ID: <CAFXKEHbV-PP8jLiW2+7Jc00Q_DWjoj==a7MOO=nE6_t-2wbCCQ@mail.gmail.com>
Date: Thu, 13 Mar 2025 17:29:08 +0100
From: Lothar Rubusch <l.rubusch@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: lars@...afoo.de, Michael.Hennerich@...log.com, linux-iio@...r.kernel.org, 
	linux-kernel@...r.kernel.org, eraretuya@...il.com
Subject: Re: [PATCH v3 06/15] iio: accel: adxl345: add single tap feature

Hi Jonathan,

I prepared, reorganized and tested a v4 patch set. Given that I see
how busy you must be these days with current increased mail traffic
just in IIO ML when I compare it to some years ago,
I don't want to bother you too much.
Some particular doubts I will inline down below. If possible with your
work flow and to avoid giving you extra work, I'd like to ask you to
read the questions here, but to give your answers right to the
v4 patch set (so, i.e. after having seen the current state of source).
It also should make my points
a bit clearer. Anyway, this is just my idea, since I'm always happy
about any feedback!

On Sun, Mar 2, 2025 at 1:14 PM Jonathan Cameron <jic23@...nel.org> wrote:
>
> On Thu, 20 Feb 2025 10:42:25 +0000
> Lothar Rubusch <l.rubusch@...il.com> wrote:
>
> > Add the single tap feature with a threshold in 62.5mg/LSB points and a
> > scaled duration in us. Keep singletap threshold in regmap cache but
> > the scaled value of duration in us as member variable.
> >
> > Both use IIO channels for individual enable of the x/y/z axis. Initializes
> > threshold and duration with reasonable content. When an interrupt is
> > caught it will be pushed to the according IIO channel.
> >
> > Signed-off-by: Lothar Rubusch <l.rubusch@...il.com>
> > ---
> >  drivers/iio/accel/adxl345_core.c | 364 ++++++++++++++++++++++++++++++-
> >  1 file changed, 362 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/accel/adxl345_core.c b/drivers/iio/accel/adxl345_core.c
> > index 0cee81bc1877..d05593c0d513 100644
> > --- a/drivers/iio/accel/adxl345_core.c
> > +++ b/drivers/iio/accel/adxl345_core.c
> > @@ -8,6 +8,7 @@
> >   */
> >
> >  #include <linux/bitfield.h>
> > +#include <linux/bitops.h>
> >  #include <linux/interrupt.h>
> >  #include <linux/module.h>
> >  #include <linux/property.h>
> > @@ -17,6 +18,7 @@
> >  #include <linux/iio/iio.h>
> >  #include <linux/iio/sysfs.h>
> >  #include <linux/iio/buffer.h>
> > +#include <linux/iio/events.h>
> >  #include <linux/iio/kfifo_buf.h>
> >
> >  #include "adxl345.h"
> > @@ -31,6 +33,33 @@
> >  #define ADXL345_INT1                 0
> >  #define ADXL345_INT2                 1
> >
> > +#define ADXL345_REG_TAP_AXIS_MSK     GENMASK(2, 0)
> This is a bit confusing.  Here we have a mask for axis that
> has 3 bits.
> > +
> > +enum adxl345_axis {
> > +     ADXL345_Z_EN = BIT(0),
> > +     ADXL345_Y_EN = BIT(1),
> > +     ADXL345_X_EN = BIT(2),
> > +     /* Suppress double tap detection if value > tap threshold */
> > +     ADXL345_TAP_SUPPRESS = BIT(3),
> and here an enum that is closely related with 4.

I see your point. There are several registers used in the sensor for
directions. A status register for tap and activity directions, and a
activity/inactivity direction register. For Tap, direction enables are
stored using the suppress bit in the fourth position. All those
locations use actually four bit. Partly the upper four, partly the
lower four. That's why I use here four bit for reading and writing.
The locations 0, 1, 2 then can be used directly. Location 3 only
applies to tap detection.

I'll keep this in v4 patches, and hope to understand you correctly
that this is not a "real" issue?

>
> > +};
> ...
>
> >  enum adxl345_chans {
> > @@ -83,6 +128,7 @@ bool adxl345_is_volatile_reg(struct device *dev, unsigned int reg)
> >       case ADXL345_REG_DATA_AXIS(3):
> >       case ADXL345_REG_DATA_AXIS(4):
> >       case ADXL345_REG_DATA_AXIS(5):
> > +     case ADXL345_REG_ACT_TAP_STATUS:
>
> ah.   I thought this had a full list from earlier patches.
> Move this and any later additions back to patch 4.
>
> >       case ADXL345_REG_FIFO_STATUS:
> >       case ADXL345_REG_INT_SOURCE:
> >               return true;
> > @@ -112,6 +158,117 @@ static int adxl345_set_measure_en(struct adxl345_state *st, bool en)
> >       return regmap_write(st->regmap, ADXL345_REG_POWER_CTL, val);
> >  }
> >
> > +/* tap */
> > +
> > +static int adxl345_write_tap_axis(struct adxl345_state *st,
> > +                               enum adxl345_axis axis, bool en)
> > +{
> > +     st->tap_axis_ctrl = FIELD_GET(ADXL345_REG_TAP_AXIS_MSK,
> > +                                   en ? st->tap_axis_ctrl | axis
> > +                                   : st->tap_axis_ctrl & ~axis);
> > +
> > +     return regmap_update_bits(st->regmap, ADXL345_REG_TAP_AXIS,
> > +                               ADXL345_REG_TAP_AXIS_MSK,
> > +                               FIELD_PREP(ADXL345_REG_TAP_AXIS_MSK,
> > +                                          st->tap_axis_ctrl));
> Given that mask is bottom few bits anyway and you can just define the
> tap axis as separate fields.
>
> See below, but I would push the IIO_MOD values down into here. Put the switch
> per axis in at this level and then use a simple if statement to
> call regmap_clear_bits() / regmap_set_bits() based on enable.
>

Thank you for this hint. I  reimplemented that, though, I was guessing
quite a bit
how you might like to have the source. Please have a look into
upcoming v4 series and let me
know if I got it wrong.

> > +}
>
> ...
>
> > +static int adxl345_is_tap_en(struct adxl345_state *st,
> > +                          enum adxl345_tap_type type, bool *en)
> > +{
> > +     int ret;
> > +     unsigned int regval;
> > +
> > +     ret = regmap_read(st->regmap, ADXL345_REG_INT_ENABLE, &regval);
> > +     if (ret)
> > +             return ret;
> > +
> > +     *en = (adxl345_tap_int_reg[type] & regval) > 0;
>
> Could use 0/1 return rather than passing a paramter for the output.
> I don't mind much either way.
>

Hum. I took this rather as suggestion, and I will keep this as is for
now. I'm a bit unsure, on
the one side I'm using the return value for error handling (return
ret), on the other side there
is the enable. If using enable in the return, this would mix up, but
probably not a big issue.
It feels rather then to me, if the function is really needed, or if I
can put this in another place.
Anyway, I think it could/should be fine like that. Let me know in v4
context, what you think.

>
> > +
> > +     return 0;
> > +}
> > +
> > +static int adxl345_set_singletap_en(struct adxl345_state *st,
> I'd push the IIO modifier in here instead of axis.
> > +                                 enum adxl345_axis axis, bool en)
> > +{
> > +     int ret;
> > +
> > +     ret = adxl345_write_tap_axis(st, axis, en);
> And push it into here as well.
>
> > +     if (ret)
> > +             return ret;
> > +
> > +     return _adxl345_set_tap_int(st, ADXL345_SINGLE_TAP, en);
> > +}
> > +
>
> ...
>
> > @@ -197,6 +354,160 @@ static int adxl345_write_raw(struct iio_dev *indio_dev,
> >       return -EINVAL;
> >  }
> >
> > +static int adxl345_read_event_config(struct iio_dev *indio_dev,
> > +                                  const struct iio_chan_spec *chan,
> > +                                  enum iio_event_type type,
> > +                                  enum iio_event_direction dir)
> > +{
> > +     struct adxl345_state *st = iio_priv(indio_dev);
> > +     bool int_en;
> > +     bool axis_en;
> > +     int ret = -EFAULT;
> > +
> > +     switch (type) {
> > +     case IIO_EV_TYPE_GESTURE:
> > +             switch (chan->channel2) {
> > +             case IIO_MOD_X:
> > +                     axis_en = FIELD_GET(ADXL345_X_EN, st->tap_axis_ctrl);
> > +                     break;
> > +             case IIO_MOD_Y:
> > +                     axis_en = FIELD_GET(ADXL345_Y_EN, st->tap_axis_ctrl);
> > +                     break;
> > +             case IIO_MOD_Z:
> > +                     axis_en = FIELD_GET(ADXL345_Z_EN, st->tap_axis_ctrl);
> > +                     break;
> > +             default:
> > +                     axis_en = ADXL345_TAP_SUPPRESS;
> > +                     break;
> > +             }
> I'd check axis_en here.
>                 if (!axis_en)
>                         return false;
> > +
> > +             switch (dir) {
> > +             case IIO_EV_DIR_SINGLETAP:
> > +                     ret = adxl345_is_tap_en(st, ADXL345_SINGLE_TAP, &int_en);
> > +                     if (ret)
> > +                             return ret;
> > +                     return int_en && axis_en;
>
> Then this just becomes return int_en;
>
> > +             default:
> > +                     return -EINVAL;
> > +             }
> > +     default:
> > +             return -EINVAL;
> > +     }
> > +}
> > +
> > +static int adxl345_write_event_config(struct iio_dev *indio_dev,
> > +                                   const struct iio_chan_spec *chan,
> > +                                   enum iio_event_type type,
> > +                                   enum iio_event_direction dir,
> > +                                   int state)
> > +{
> > +     struct adxl345_state *st = iio_priv(indio_dev);
> > +     enum adxl345_axis axis;
> > +
> > +     switch (type) {
> > +     case IIO_EV_TYPE_GESTURE:
> > +             switch (chan->channel2) {
> > +             case IIO_MOD_X:
> > +                     axis = ADXL345_X_EN;
> > +                     break;
> > +             case IIO_MOD_Y:
> > +                     axis = ADXL345_Y_EN;
> > +                     break;
> > +             case IIO_MOD_Z:
> > +                     axis = ADXL345_Z_EN;
> > +                     break;
> > +             default:
> > +                     axis = ADXL345_TAP_SUPPRESS;
>
> How are we getting another axis here?

:)

> > +                     break;
> > +             }
> > +
> > +             switch (dir) {
> > +             case IIO_EV_DIR_SINGLETAP:
> > +                     return adxl345_set_singletap_en(st, axis, state);
>
> As above, pass chan->channel2 into here so we can simplify the eventual
> setting of the the register values.
>
> > +             default:
> > +                     return -EINVAL;
> > +             }
> > +     default:
> > +             return -EINVAL;
> > +     }
> > +}
> > +
> > +static int adxl345_read_event_value(struct iio_dev *indio_dev,
> > +                                 const struct iio_chan_spec *chan,
> > +                                 enum iio_event_type type,
> > +                                 enum iio_event_direction dir,
> > +                                 enum iio_event_info info,
> > +                                 int *val, int *val2)
> > +{
> > +     struct adxl345_state *st = iio_priv(indio_dev);
> > +     unsigned int tap_threshold;
> > +     int ret;
> > +
> > +     switch (type) {
> > +     case IIO_EV_TYPE_GESTURE:
> > +             switch (info) {
> > +             case IIO_EV_INFO_VALUE:
> > +                     /*
> > +                      * The scale factor is 62.5mg/LSB (i.e. 0xFF = 16g) but
> > +                      * not applied here.
>
> Maybe say why.
>

Usually I did scaling for the time values. Time values is something I
can understand someone
rather wants to configure in corresponding time units, such as [ms],
[us] or [s] rather than bit
values. For [mg] values, franckly speaking, I imagine this is a bit overkill.

The threshold quite often is rather expect to be higher or lower,
depending a bit on variation of
the measurements. In the context of this rather "cheap" sensor, I
guess I'm not putting up a
seismic instrument, but rather generic tap detection, freefall or
general activity in a general
purpose context such as gaming, or the like. Let me know if this
assumption here is too lazy.

I added a bit more comment to the source, pls have a look into v4.

> > +                      */
> > +                     ret = regmap_read(st->regmap, ADXL345_REG_THRESH_TAP, &tap_threshold);
>
> Bit of a long line. Aim for sub 80 chars unless readability is greatly
> hurt.
>
> > +                     if (ret)
> > +                             return ret;
> > +                     *val = sign_extend32(tap_threshold, 7);
> > +                     return IIO_VAL_INT;
> > +             case IIO_EV_INFO_TIMEOUT:
> > +                     *val = st->tap_duration_us;
> > +                     *val2 = 1000000;
> > +                     return IIO_VAL_FRACTIONAL;
> > +             default:
> > +                     return -EINVAL;
> > +             }
> > +     default:
> > +             return -EINVAL;
> > +     }
> > +}
> ...
>

Powered by blists - more mailing lists