Commit 4c18a890 authored by Gwendal Grignou's avatar Gwendal Grignou Committed by Jonathan Cameron

iio:proximity:sx9324: Add SX9324 support

Semtech SAR sensor SX9324 is an evolution of the SX9310:
It has 4 phases that can be configured to capture and process data
from any of 3 CS pins and provide independent detection:
proximity, table proximity or body proximity.

Gather antenna data:
  echo sx9324-dev3 > trigger/current_trigger
  echo 1 > scan_elements/in_proximity0_en
  echo 1 > buffer/enable
  od -v -An --endian=big -t d2 -w2 /dev/iio\:device3
  (at 10Hz, the default).

Trigger events:
Setting:
  thresh_falling_period: 2 (events)
  thresh_rising_period: 2 (events)
  in_proximity0_thresh_either_value: 300
  in_proximity0_thresh_either_hysteresis: 72

using iio_event_monitor /dev/iio\:deviceX, approaching my hand to the
antenna pad, I see:
...
Event: time: 1634763907532035297, type: proximity, channel: 0, evtype:
thresh, direction: falling
Event: time: 1634763910138104640, type: proximity, channel: 0, evtype:
thresh, direction: rising
...

Datasheet: https://edit.wpgdadawant.com/uploads/news_file/program/2019/30184/tech_files/program_30184_suggest_other_file.pdfSigned-off-by: default avatarGwendal Grignou <gwendal@chromium.org>
Reviewed-by: default avatarStephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20220101203817.290512-4-gwendal@chromium.orgSigned-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
parent caa8ce7f
What: /sys/bus/iio/devices/iio:deviceX/in_proximity<id>_setup
Date: November 2021
KernelVersion: 5.17
Contact: Gwendal Grignou <gwendal@chromium.org>
Description:
SX9324 has 3 inputs, CS0, CS1 and CS2. Hardware layout
defines if the input is
+ not connected (HZ),
+ grounded (GD),
+ connected to an antenna where it can act as a base
(DS - data shield), or measured input (MI).
The sensor rotates measurement across 4 phases
(PH0, PH1, PH2, PH3), where the inputs are configured
and then measured.
By default, during the first phase, [PH0], CS0 is measured,
while CS1 and CS2 are used as shields.
`cat in_proximity0_setup` returns "MI,DS,DS".
[PH1], CS1 is measured, CS0 and CS2 are shield:
`cat in_proximity1_setup` returns "DS,MI,DS".
[PH2], CS2 is measured, CS0 and CS1 are shield:
`cat in_proximity1_setup` returns "DS,DS,MI".
[PH3], CS1 and CS2 are measured (combo mode):
`cat in_proximity1_setup` returns "DS,MI,MI".
Note, these are the chip default. Hardware layout will most
likely dictate different output. The entry is read-only.
...@@ -131,6 +131,20 @@ config SX9310 ...@@ -131,6 +131,20 @@ config SX9310
To compile this driver as a module, choose M here: the To compile this driver as a module, choose M here: the
module will be called sx9310. module will be called sx9310.
config SX9324
tristate "SX9324 Semtech proximity sensor"
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
select REGMAP_I2C
select SX_COMMON
depends on I2C
help
Say Y here to build a driver for Semtech's SX9324
proximity/button sensor.
To compile this driver as a module, choose M here: the
module will be called sx9324.
config SX9500 config SX9500
tristate "SX9500 Semtech proximity sensor" tristate "SX9500 Semtech proximity sensor"
select IIO_BUFFER select IIO_BUFFER
......
...@@ -14,6 +14,7 @@ obj-$(CONFIG_RFD77402) += rfd77402.o ...@@ -14,6 +14,7 @@ obj-$(CONFIG_RFD77402) += rfd77402.o
obj-$(CONFIG_SRF04) += srf04.o obj-$(CONFIG_SRF04) += srf04.o
obj-$(CONFIG_SRF08) += srf08.o obj-$(CONFIG_SRF08) += srf08.o
obj-$(CONFIG_SX9310) += sx9310.o obj-$(CONFIG_SX9310) += sx9310.o
obj-$(CONFIG_SX9324) += sx9324.o
obj-$(CONFIG_SX_COMMON) += sx_common.o obj-$(CONFIG_SX_COMMON) += sx_common.o
obj-$(CONFIG_SX9500) += sx9500.o obj-$(CONFIG_SX9500) += sx9500.o
obj-$(CONFIG_VCNL3020) += vcnl3020.o obj-$(CONFIG_VCNL3020) += vcnl3020.o
......
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment