On Sun, Mar 28, 2021 at 8:12 PM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote:
>
> Quoting Gwendal Grignou (2021-03-27 20:36:37)
> > Semtech SX9310 SAR sensor has a debouncer filter: only when N
> > measurements are above/below the far/close threshold an event is
> > sent to the host.
> > By default the debouncer is set to 2 events for the close to far
> > transition and 1 event (no debounce) for far to close.
> > It is a balance speed of detection and false positive avoidance.
> >
> > On some chromebooks, the debouncer is set to a larger number.
> >
> > This patch applies on top of commit 103d6ec82676 ("iio: sx9310: Support ACPI properties")
>
> The near/far debounce settings are already supported via sysfs. Can you
> use those instead of putting this into DT/ACPI? See
> sx9310_read_far_debounce() and associated code.
Stephen, I missed you already proposed these bindings earlier
[https://lore.kernel.org/linux-devicetree/20200906150247.3aaef3a3@archlinux/].
After Jonathan inputs, it is done via sysfs interface
[events/thresh_{falling|rising}_period].
The debounce parameters are in the same class as the other parameters
already present in the DT. They are calculated during tests to meet
FCC requirements, in particular the time it takes to detect a human
body near the antennas.
Depending on the SAR antenna design, it is a balance between lowering
the debouncer "period" to raise an event as soon as possible, and
increasing it to prevent false posible.
In addition to controlling it from sysfs, could it be acceptable to
have it in DT/ACPI as well?
In the meantime, I will make sure semtech,sx9310.yaml matches
in_proximityX_hardwaregain_available and connect to that attribute.
Gwendal.
