[PATCH 0/2] iio: driver for Semtech SX9500

[PATCH 0/2] iio: driver for Semtech SX9500

[Vlad Dogaru]

Add a driver for Semtech's SX9500 proximity sensor, but first change the
Kconfig prompt from 'Lightning sensors' to 'Proximity sensors'.

The device does not estimate distance, it only outputs a single bit which
indicates proximity.  We use 0 to mean that an object is close and 1 otherwise,
sort of an uncalibrated distance.  From what I understand in the ABI
specification, this is allowed.

Vlad Dogaru (2):
  iio: rename proximity sensors in kernel config
  iio: driver for Semtech SX9500 proximity solution

 drivers/iio/proximity/Kconfig  |  12 +-
 drivers/iio/proximity/Makefile |   1 +
 drivers/iio/proximity/sx9500.c | 752 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 764 insertions(+), 1 deletion(-)
 create mode 100644 drivers/iio/proximity/sx9500.c

-- 
1.9.1

[PATCH 1/2] iio: rename proximity sensors in kernel config

[Vlad Dogaru]

Up till now, there was only a single sensor in the drivers/iio/proximity
directory, and the config subsection was called 'Lightning sensors'.
This will no longer be true once we introduce a general-purpose
proximity sensor.

Signed-off-by: Vlad Dogaru <vlad.dogaru@intel.com>
---
 drivers/iio/proximity/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index 0c8cdf5..a131ead 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -2,7 +2,7 @@
 # Proximity sensors
 #
 
-menu "Lightning sensors"
+menu "Proximity sensors"
 
 config AS3935
 	tristate "AS3935 Franklin lightning sensor"
-- 
1.9.1

[PATCH 2/2] iio: driver for Semtech SX9500 proximity solution

[Vlad Dogaru]

Supports buffering, IIO events and changing sampling frequency.

Datasheet available at:
http://www.semtech.com/images/datasheet/sx9500_ag.pdf

Signed-off-by: Vlad Dogaru <vlad.dogaru@intel.com>
---
 drivers/iio/proximity/Kconfig  |  10 +
 drivers/iio/proximity/Makefile |   1 +
 drivers/iio/proximity/sx9500.c | 752 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 763 insertions(+)
 create mode 100644 drivers/iio/proximity/sx9500.c

diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index a131ead..3e9bbe2 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -16,4 +16,14 @@ config AS3935
 	  To compile this driver as a module, choose M here: the
 	  module will be called as3935
 
+config SX9500
+	tristate "SX9500 Semtech proximity sensor"
+	select IIO_BUFFER
+	select IIO_TRIGGERED_BUFFER
+	select REGMAP_I2C
+	depends on I2C
+	help
+	  Say Y here to build a driver for Semtech's SX9500 capacitive
+	  proximity/button sensor.
+
 endmenu
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
index 743adee..9818dc5 100644
--- a/drivers/iio/proximity/Makefile
+++ b/drivers/iio/proximity/Makefile
@@ -4,3 +4,4 @@
 
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_AS3935)		+= as3935.o
+obj-$(CONFIG_SX9500)		+= sx9500.o
diff --git a/drivers/iio/proximity/sx9500.c b/drivers/iio/proximity/sx9500.c
new file mode 100644
index 0000000..b20ba3e
--- /dev/null
+++ b/drivers/iio/proximity/sx9500.c
@@ -0,0 +1,752 @@
+/*
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Driver for Semtech's SX9500 capacitive proximity/button solution.
+ * Datasheet available at
+ * <http://www.semtech.com/images/datasheet/sx9500.pdf>.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/irq.h>
+#include <linux/acpi.h>
+#include <linux/gpio/consumer.h>
+#include <linux/regmap.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/buffer.h>
+#include <linux/iio/sysfs.h>
+#include <linux/iio/events.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/triggered_buffer.h>
+#include <linux/iio/trigger_consumer.h>
+
+#define SX9500_DRIVER_NAME		"sx9500"
+#define SX9500_IRQ_NAME			"sx9500_event"
+#define SX9500_GPIO_NAME		"sx9500_gpio"
+
+/* Register definitions. */
+#define SX9500_REG_IRQ_SRC		0x00
+#define SX9500_REG_STAT			0x01
+#define SX9500_REG_IRQ_MSK		0x03
+
+#define SX9500_REG_PROX_CTRL0		0x06
+#define SX9500_REG_PROX_CTRL1		0x07
+#define SX9500_REG_PROX_CTRL2		0x08
+#define SX9500_REG_PROX_CTRL3		0x09
+#define SX9500_REG_PROX_CTRL4		0x0a
+#define SX9500_REG_PROX_CTRL5		0x0b
+#define SX9500_REG_PROX_CTRL6		0x0c
+#define SX9500_REG_PROX_CTRL7		0x0d
+#define SX9500_REG_PROX_CTRL8		0x0e
+
+#define SX9500_REG_SENSOR_SEL		0x20
+#define SX9500_REG_USE_MSB		0x21
+#define SX9500_REG_USE_LSB		0x22
+#define SX9500_REG_AVG_MSB		0x23
+#define SX9500_REG_AVG_LSB		0x24
+#define SX9500_REG_DIFF_MSB		0x25
+#define SX9500_REG_DIFF_LSB		0x26
+#define SX9500_REG_OFFSET_MSB		0x27
+#define SX9500_REG_OFFSET_LSB		0x28
+
+#define SX9500_REG_RESET		0x7f
+
+/* Write this to REG_RESET to do a soft reset. */
+#define SX9500_SOFT_RESET		0xde
+
+#define SX9500_SCAN_PERIOD_MASK		0x70
+
+/*
+ * These serve for identifying IRQ source in the IRQ_SRC register, and
+ * also for masking the IRQs in the IRQ_MSK register.
+ */
+#define SX9500_CLOSE_IRQ		BIT(6)
+#define SX9500_FAR_IRQ			BIT(5)
+#define SX9500_CONVDONE_IRQ		BIT(3)
+
+#define SX9500_PROXSTAT_SHIFT		4
+
+#define SX9500_NUM_CHANNELS		4
+
+struct sx9500_data {
+	struct mutex mutex;
+	struct i2c_client *client;
+	struct iio_trigger *trig;
+	struct regmap *regmap;
+	/*
+	 * Last reading of the proximity status for each channel.  We
+	 * only send an event to user space when this changes.
+	 */
+	u8 prox_stat[SX9500_NUM_CHANNELS];
+	bool event_enabled[SX9500_NUM_CHANNELS];
+	bool trigger_enabled;
+};
+
+static const struct iio_event_spec sx9500_events[] = {
+	{
+		.type = IIO_EV_TYPE_THRESH,
+		.dir = IIO_EV_DIR_EITHER,
+		.mask_separate = BIT(IIO_EV_INFO_ENABLE),
+	},
+};
+
+#define SX9500_CHANNEL(idx)					\
+	{							\
+		.type = IIO_PROXIMITY,				\
+		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),	\
+		.info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ), \
+		.indexed = 1,					\
+		.channel = idx,					\
+		.event_spec = sx9500_events,			\
+		.num_event_specs = 1,				\
+		.scan_index = idx,				\
+		.scan_type = {					\
+			.sign = 'u',				\
+			.realbits = 1,				\
+			.storagebits = 8,			\
+			.shift = 7,				\
+		},						\
+	}
+
+static const struct iio_chan_spec sx9500_channels[] = {
+	SX9500_CHANNEL(0),
+	SX9500_CHANNEL(1),
+	SX9500_CHANNEL(2),
+	SX9500_CHANNEL(3),
+	IIO_CHAN_SOFT_TIMESTAMP(4),
+};
+
+static const struct {
+	int val;
+	int val2;
+	unsigned int bits;
+} sx9500_samp_freq_table[] = {
+	{2, 500000, 0x70},
+	{3, 333333, 0x60},
+	{5, 0, 0x50},
+	{6, 666666, 0x40},
+	{8, 333333, 0x30},
+	{11, 111111, 0x20},
+	{16, 666666, 0x10},
+	{33, 333333, 0x00},
+};
+
+static const struct regmap_range sx9500_writable_reg_ranges[] = {
+	regmap_reg_range(SX9500_REG_IRQ_MSK, SX9500_REG_IRQ_MSK),
+	regmap_reg_range(SX9500_REG_PROX_CTRL0, SX9500_REG_PROX_CTRL8),
+	regmap_reg_range(SX9500_REG_SENSOR_SEL, SX9500_REG_SENSOR_SEL),
+	regmap_reg_range(SX9500_REG_OFFSET_MSB, SX9500_REG_OFFSET_LSB),
+	regmap_reg_range(SX9500_REG_RESET, SX9500_REG_RESET),
+};
+
+static const struct regmap_access_table sx9500_writeable_regs = {
+	.yes_ranges = sx9500_writable_reg_ranges,
+	.n_yes_ranges = ARRAY_SIZE(sx9500_writable_reg_ranges),
+};
+
+/*
+ * All allocated registers are readable, so we just list unallocated
+ * ones.
+ */
+static const struct regmap_range sx9500_non_readable_reg_ranges[] = {
+	regmap_reg_range(SX9500_REG_STAT + 1, SX9500_REG_STAT + 1),
+	regmap_reg_range(SX9500_REG_IRQ_MSK + 1, SX9500_REG_PROX_CTRL0 - 1),
+	regmap_reg_range(SX9500_REG_PROX_CTRL8 + 1, SX9500_REG_SENSOR_SEL - 1),
+	regmap_reg_range(SX9500_REG_OFFSET_LSB + 1, SX9500_REG_RESET - 1),
+};
+
+static const struct regmap_access_table sx9500_readable_regs = {
+	.no_ranges = sx9500_non_readable_reg_ranges,
+	.n_no_ranges = ARRAY_SIZE(sx9500_non_readable_reg_ranges),
+};
+
+static const struct regmap_range sx9500_volatile_reg_ranges[] = {
+	regmap_reg_range(SX9500_REG_IRQ_SRC, SX9500_REG_STAT),
+	regmap_reg_range(SX9500_REG_USE_MSB, SX9500_REG_OFFSET_LSB),
+	regmap_reg_range(SX9500_REG_RESET, SX9500_REG_RESET),
+};
+
+static const struct regmap_access_table sx9500_volatile_regs = {
+	.yes_ranges = sx9500_volatile_reg_ranges,
+	.n_yes_ranges = ARRAY_SIZE(sx9500_volatile_reg_ranges),
+};
+
+static const struct regmap_config sx9500_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+
+	.max_register = SX9500_REG_RESET,
+	.cache_type = REGCACHE_RBTREE,
+
+	.wr_table = &sx9500_writeable_regs,
+	.rd_table = &sx9500_readable_regs,
+	.volatile_table = &sx9500_volatile_regs,
+};
+
+static int sx9500_read_proximity(struct sx9500_data *data,
+				 const struct iio_chan_spec *chan,
+				 int *val)
+{
+	int ret;
+	unsigned int regval;
+
+	mutex_lock(&data->mutex);
+
+	ret = regmap_read(data->regmap, SX9500_REG_STAT, &regval);
+	if (ret < 0)
+		goto out;
+
+	/*
+	 * If bit is set, something is close to the sensor, so we report
+	 * 0 distance.
+	 */
+	*val = !(regval & (1 << (SX9500_PROXSTAT_SHIFT + chan->channel)));
+	ret = IIO_VAL_INT;
+
+out:
+	mutex_unlock(&data->mutex);
+
+	return ret;
+}
+
+static int sx9500_read_samp_freq(struct sx9500_data *data,
+				 int *val, int *val2)
+{
+	int i, ret;
+	unsigned int regval;
+
+	mutex_lock(&data->mutex);
+
+	ret = regmap_read(data->regmap, SX9500_REG_PROX_CTRL0, &regval);
+	if (ret < 0)
+		goto out;
+
+	ret = -EINVAL;
+	for (i = 0; i < ARRAY_SIZE(sx9500_samp_freq_table); i++)
+		if (sx9500_samp_freq_table[i].bits ==
+		    (regval & SX9500_SCAN_PERIOD_MASK)) {
+			*val = sx9500_samp_freq_table[i].val;
+			*val2 = sx9500_samp_freq_table[i].val2;
+			ret = IIO_VAL_INT_PLUS_MICRO;
+			break;
+		}
+
+out:
+	mutex_unlock(&data->mutex);
+
+	return ret;
+}
+
+static int sx9500_read_raw(struct iio_dev *indio_dev,
+			   const struct iio_chan_spec *chan,
+			   int *val, int *val2, long mask)
+{
+	struct sx9500_data *data = iio_priv(indio_dev);
+
+	switch (chan->type) {
+	case IIO_PROXIMITY:
+		switch (mask) {
+		case IIO_CHAN_INFO_RAW:
+			if (iio_buffer_enabled(indio_dev))
+				return -EBUSY;
+			return sx9500_read_proximity(data, chan, val);
+		case IIO_CHAN_INFO_SAMP_FREQ:
+			return sx9500_read_samp_freq(data, val, val2);
+		default:
+			return -EINVAL;
+		}
+	default:
+		return -EINVAL;
+	}
+}
+
+static int sx9500_set_samp_freq(struct sx9500_data *data,
+				int val, int val2)
+{
+	int i, ret, idx;
+
+	idx = -1;
+	for (i = 0; i < ARRAY_SIZE(sx9500_samp_freq_table); i++)
+		if (val == sx9500_samp_freq_table[i].val &&
+		    val2 == sx9500_samp_freq_table[i].val2) {
+			idx = i;
+			break;
+		}
+
+	if (idx == -1)
+		return -EINVAL;
+
+	mutex_lock(&data->mutex);
+
+	ret = regmap_update_bits(data->regmap, SX9500_REG_PROX_CTRL0,
+				 SX9500_SCAN_PERIOD_MASK,
+				 sx9500_samp_freq_table[idx].bits);
+
+	mutex_unlock(&data->mutex);
+
+	return ret;
+}
+
+static int sx9500_write_raw(struct iio_dev *indio_dev,
+			    const struct iio_chan_spec *chan,
+			    int val, int val2, long mask)
+{
+	struct sx9500_data *data = iio_priv(indio_dev);
+
+	switch (chan->type) {
+	case IIO_PROXIMITY:
+		switch (mask) {
+		case IIO_CHAN_INFO_SAMP_FREQ:
+			return sx9500_set_samp_freq(data, val, val2);
+		default:
+			return -EINVAL;
+		}
+	default:
+		return -EINVAL;
+	}
+}
+
+static irqreturn_t sx9500_irq_handler(int irq, void *private)
+{
+	struct iio_dev *indio_dev = private;
+	struct sx9500_data *data = iio_priv(indio_dev);
+
+	if (data->trigger_enabled)
+		iio_trigger_poll(data->trig);
+
+	/*
+	 * Even if no event is enabled, we need to wake the thread to
+	 * clear the interrupt state by reading SX9500_REG_IRQ_SRC.  It
+	 * is not possible to do that here because regmap_read takes a
+	 * mutex.
+	 */
+	return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t sx9500_irq_thread_handler(int irq, void *private)
+{
+	struct iio_dev *indio_dev = private;
+	struct sx9500_data *data = iio_priv(indio_dev);
+	int ret, chan;
+	unsigned int val;
+
+	mutex_lock(&data->mutex);
+
+	ret = regmap_read(data->regmap, SX9500_REG_IRQ_SRC, &val);
+	if (ret < 0) {
+		dev_err(&data->client->dev, "i2c transfer error in irq\n");
+		goto out;
+	}
+
+	if (!(val & (SX9500_CLOSE_IRQ | SX9500_FAR_IRQ)))
+		goto out;
+
+	ret = regmap_read(data->regmap, SX9500_REG_STAT, &val);
+	if (ret < 0) {
+		dev_err(&data->client->dev, "i2c transfer error in irq\n");
+		goto out;
+	}
+
+	val >>= SX9500_PROXSTAT_SHIFT;
+	for (chan = 0; chan < SX9500_NUM_CHANNELS; chan++) {
+		int dir;
+		u64 ev;
+		u8 new_prox = !(val & (1 << chan));
+
+		if (!data->event_enabled[chan])
+			continue;
+		if (new_prox == data->prox_stat[chan])
+			/* No change on this channel. */
+			continue;
+
+		dir = new_prox ? IIO_EV_DIR_RISING :
+			IIO_EV_DIR_FALLING;
+		ev = IIO_UNMOD_EVENT_CODE(IIO_PROXIMITY,
+					  chan,
+					  IIO_EV_TYPE_THRESH,
+					  dir);
+		iio_push_event(indio_dev, ev, iio_get_time_ns());
+		data->prox_stat[chan] = new_prox;
+	}
+
+out:
+	mutex_unlock(&data->mutex);
+
+	return IRQ_HANDLED;
+}
+
+static int sx9500_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 sx9500_data *data = iio_priv(indio_dev);
+
+	if (chan->type != IIO_PROXIMITY)
+		return -EINVAL;
+	if (type != IIO_EV_TYPE_THRESH)
+		return -EINVAL;
+	if (dir != IIO_EV_DIR_EITHER)
+		return -EINVAL;
+
+	return data->event_enabled[chan->channel];
+}
+
+static int sx9500_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 sx9500_data *data = iio_priv(indio_dev);
+	int ret;
+	int i;
+	bool any_active;
+	unsigned int irqmask;
+
+	if (chan->type != IIO_PROXIMITY)
+		return -EINVAL;
+	if (type != IIO_EV_TYPE_THRESH)
+		return -EINVAL;
+	if (dir != IIO_EV_DIR_EITHER)
+		return -EINVAL;
+
+	mutex_lock(&data->mutex);
+
+	data->event_enabled[chan->channel] = state;
+
+	any_active = 0;
+	for (i = 0; i < SX9500_NUM_CHANNELS; i++)
+		if (data->event_enabled[chan->channel]) {
+			any_active = true;
+			break;
+		}
+
+	irqmask = SX9500_CLOSE_IRQ | SX9500_FAR_IRQ;
+	ret = regmap_update_bits(data->regmap, SX9500_REG_IRQ_MSK,
+				 irqmask, any_active ? irqmask : 0);
+
+	mutex_unlock(&data->mutex);
+
+	return ret;
+}
+
+static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
+	"2.500000 3.333333 5 6.666666 8.333333 11.111111 16.666666 33.333333");
+
+static struct attribute *sx9500_attributes[] = {
+	&iio_const_attr_sampling_frequency_available.dev_attr.attr,
+	NULL,
+};
+
+static const struct attribute_group sx9500_attribute_group = {
+	.attrs = sx9500_attributes,
+};
+
+static const struct iio_info sx9500_info = {
+	.driver_module = THIS_MODULE,
+	.attrs = &sx9500_attribute_group,
+	.read_raw = &sx9500_read_raw,
+	.write_raw = &sx9500_write_raw,
+	.read_event_config = &sx9500_read_event_config,
+	.write_event_config = &sx9500_write_event_config,
+};
+
+static int sx9500_set_trigger_state(struct iio_trigger *trig,
+				    bool state)
+{
+	struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
+	struct sx9500_data *data = iio_priv(indio_dev);
+	int ret;
+
+	mutex_lock(&data->mutex);
+
+	ret = regmap_update_bits(data->regmap, SX9500_REG_IRQ_MSK,
+				 SX9500_CONVDONE_IRQ,
+				 state ? SX9500_CONVDONE_IRQ : 0);
+	data->trigger_enabled = state;
+
+	mutex_unlock(&data->mutex);
+
+	return ret;
+}
+
+static const struct iio_trigger_ops sx9500_trigger_ops = {
+	.set_trigger_state = sx9500_set_trigger_state,
+	.owner = THIS_MODULE,
+};
+
+static irqreturn_t sx9500_trigger_handler(int irq, void *private)
+{
+	struct iio_poll_func *pf = private;
+	struct iio_dev *indio_dev = pf->indio_dev;
+	struct sx9500_data *data = iio_priv(indio_dev);
+	u8 buf[SX9500_NUM_CHANNELS];
+	int bit, ret, i;
+	unsigned int val;
+
+	mutex_lock(&data->mutex);
+
+	ret = regmap_read(data->regmap, SX9500_REG_STAT, &val);
+	if (ret < 0)
+		goto out;
+
+	val >>= SX9500_PROXSTAT_SHIFT;
+	i = 0;
+
+	for_each_set_bit(bit, indio_dev->buffer->scan_mask,
+			 indio_dev->masklength)
+		buf[i++] = !(val & (1 << bit));
+
+	iio_push_to_buffers_with_timestamp(indio_dev, buf,
+					   iio_get_time_ns());
+
+out:
+	mutex_unlock(&data->mutex);
+
+	iio_trigger_notify_done(indio_dev->trig);
+
+	return IRQ_HANDLED;
+}
+
+struct sx9500_reg_default {
+	u8 reg;
+	u8 def;
+};
+
+static const struct sx9500_reg_default sx9500_default_regs[] = {
+	{
+		.reg = SX9500_REG_PROX_CTRL1,
+		/* Shield enabled, small range. */
+		.def = 0x43,
+	},
+	{
+		.reg = SX9500_REG_PROX_CTRL2,
+		/* x8 gain, 167kHz frequency, finest resolution. */
+		.def = 0x77,
+	},
+	{
+		.reg = SX9500_REG_PROX_CTRL3,
+		/* Doze enabled, 2x scan period doze, no raw filter. */
+		.def = 0x40,
+	},
+	{
+		.reg = SX9500_REG_PROX_CTRL4,
+		/* Average threshold. */
+		.def = 0x30,
+	},
+	{
+		.reg = SX9500_REG_PROX_CTRL5,
+		/*
+		 * Debouncer off, lowest average negative filter,
+		 * highest average postive filter.
+		 */
+		.def = 0x0f,
+	},
+	{
+		.reg = SX9500_REG_PROX_CTRL6,
+		/* Proximity detection threshold: 400 */
+		.def = 0x0e,
+	},
+	{
+		.reg = SX9500_REG_PROX_CTRL7,
+		/*
+		 * No automatic compensation, compensate each pin
+		 * independently, proximity hysteresis: 32, close
+		 * debouncer off, far debouncer off.
+		 */
+		.def = 0x00,
+	},
+	{
+		.reg = SX9500_REG_PROX_CTRL8,
+		/* No stuck timeout, no periodic compensation. */
+		.def = 0x00,
+	},
+	{
+		.reg = SX9500_REG_PROX_CTRL0,
+		/* Scan period: 30ms, all sensors enabled. */
+		.def = 0x0f,
+	},
+};
+
+static int sx9500_init_device(struct iio_dev *indio_dev)
+{
+	struct sx9500_data *data = iio_priv(indio_dev);
+	int ret, i, num_defaults;
+	unsigned int val;
+
+	ret = regmap_write(data->regmap, SX9500_REG_IRQ_MSK, 0);
+	if (ret < 0)
+		return ret;
+
+	ret = regmap_write(data->regmap, SX9500_REG_RESET,
+			   SX9500_SOFT_RESET);
+	if (ret < 0)
+		return ret;
+
+	ret = regmap_read(data->regmap, SX9500_REG_IRQ_SRC, &val);
+	if (ret < 0)
+		return ret;
+
+	num_defaults = ARRAY_SIZE(sx9500_default_regs);
+	for (i = 0; i < num_defaults; i++) {
+		ret = regmap_write(data->regmap,
+				   sx9500_default_regs[i].reg,
+				   sx9500_default_regs[i].def);
+		if (ret < 0)
+			return ret;
+	}
+
+	return 0;
+}
+
+static int sx9500_gpio_probe(struct i2c_client *client,
+			     struct sx9500_data *data)
+{
+	struct device *dev;
+	struct gpio_desc *gpio;
+	int ret;
+
+	if (!client)
+		return -EINVAL;
+
+	dev = &client->dev;
+
+	/* data ready gpio interrupt pin */
+	gpio = devm_gpiod_get_index(dev, SX9500_GPIO_NAME, 0);
+	if (IS_ERR(gpio)) {
+		dev_err(dev, "acpi gpio get index failed\n");
+		return PTR_ERR(gpio);
+	}
+
+	ret = gpiod_direction_input(gpio);
+	if (ret)
+		return ret;
+
+	ret = gpiod_to_irq(gpio);
+
+	dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret);
+
+	return ret;
+}
+
+static int sx9500_probe(struct i2c_client *client,
+			const struct i2c_device_id *id)
+{
+	int ret;
+	struct iio_dev *indio_dev;
+	struct sx9500_data *data;
+
+	indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
+	if (indio_dev == NULL)
+		return -ENOMEM;
+
+	data = iio_priv(indio_dev);
+	data->client = client;
+	mutex_init(&data->mutex);
+	memset(data->prox_stat, 0, sizeof(data->prox_stat));
+	memset(data->event_enabled, 0, sizeof(data->event_enabled));
+	data->trigger_enabled = false;
+
+	data->regmap = devm_regmap_init_i2c(client, &sx9500_regmap_config);
+	if (IS_ERR(data->regmap))
+		return PTR_ERR(data->regmap);
+
+	sx9500_init_device(indio_dev);
+
+	indio_dev->dev.parent = &client->dev;
+	indio_dev->name = id->name;
+	indio_dev->channels = sx9500_channels;
+	indio_dev->num_channels = ARRAY_SIZE(sx9500_channels);
+	indio_dev->info = &sx9500_info;
+	indio_dev->modes = INDIO_DIRECT_MODE;
+
+	if (client->irq <= 0)
+		client->irq = sx9500_gpio_probe(client, data);
+
+	if (client->irq > 0) {
+		ret = devm_request_threaded_irq(&client->dev, client->irq,
+				sx9500_irq_handler, sx9500_irq_thread_handler,
+				IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+				SX9500_IRQ_NAME, indio_dev);
+		if (ret < 0)
+			return ret;
+
+		data->trig = devm_iio_trigger_alloc(&client->dev,
+				"%s-dev%d", indio_dev->name, indio_dev->id);
+		if (!data->trig)
+			return -ENOMEM;
+
+		data->trig->dev.parent = &client->dev;
+		data->trig->ops = &sx9500_trigger_ops;
+		iio_trigger_set_drvdata(data->trig, indio_dev);
+
+		ret = iio_trigger_register(data->trig);
+		if (ret)
+			return ret;
+	}
+
+	ret = iio_triggered_buffer_setup(indio_dev, NULL,
+					 sx9500_trigger_handler, NULL);
+	if (ret < 0)
+		goto out_trigger_unregister;
+
+	ret = iio_device_register(indio_dev);
+	if (ret < 0)
+		goto out_buffer_cleanup;
+
+	return 0;
+
+out_buffer_cleanup:
+	iio_triggered_buffer_cleanup(indio_dev);
+out_trigger_unregister:
+	iio_trigger_unregister(data->trig);
+
+	return ret;
+}
+
+static int sx9500_remove(struct i2c_client *client)
+{
+	struct iio_dev *indio_dev = i2c_get_clientdata(client);
+	struct sx9500_data *data = iio_priv(indio_dev);
+
+	iio_device_unregister(indio_dev);
+	iio_triggered_buffer_cleanup(indio_dev);
+	iio_trigger_unregister(data->trig);
+
+	return 0;
+}
+
+static const struct acpi_device_id sx9500_acpi_match[] = {
+	{"SSX9500", 0}, /* TODO is there a better ACPI handle? */
+	{ },
+};
+MODULE_DEVICE_TABLE(acpi, sx9500_acpi_match);
+
+static const struct i2c_device_id sx9500_id[] = {
+	{"sx9500", 0},
+	{}
+};
+MODULE_DEVICE_TABLE(i2c, sx9500_id);
+
+static struct i2c_driver sx9500_driver = {
+	.driver = {
+		.name	= SX9500_DRIVER_NAME,
+		.acpi_match_table = ACPI_PTR(sx9500_acpi_match),
+	},
+	.probe		= sx9500_probe,
+	.remove		= sx9500_remove,
+	.id_table	= sx9500_id,
+};
+module_i2c_driver(sx9500_driver);
+
+MODULE_AUTHOR("Vlad Dogaru <vlad.dogaru@intel.com>");
+MODULE_DESCRIPTION("Driver for Semtech SX9500 proximity sensor");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

Re: [PATCH 0/2] iio: driver for Semtech SX9500

[Peter Meerwald]

> The device does not estimate distance, it only outputs a single bit which
> indicates proximity.  We use 0 to mean that an object is close and 1 otherwise,
> sort of an uncalibrated distance.  From what I understand in the ABI
> specification, this is allowed.

perhaps the input subsystem would be a better fit for this driver/device?
what is it typically used for?

regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

Re: [PATCH 0/2] iio: driver for Semtech SX9500

[Jonathan Cameron]

On 17/11/14 15:25, Peter Meerwald wrote:
> 
>> The device does not estimate distance, it only outputs a single bit which
>> indicates proximity.  We use 0 to mean that an object is close and 1 otherwise,
>> sort of an uncalibrated distance.  From what I understand in the ABI
>> specification, this is allowed.
> 
> perhaps the input subsystem would be a better fit for this driver/device?
> what is it typically used for?
> 
> regards, p.
> 
Hi Peter,

Whilst it may be the case that this particular one might have a reasonable
home in input, these are often integrated with ambient light sensors
and as such we already have a quite a few proximity sensors in IIO...

Interestingly there is one obvious proximity sensor in input and that
is a dual ambient light/ proximity part though I can't see any way
of reading the light side of it.  Interesting...

Jonathan

Re: [PATCH 0/2] iio: driver for Semtech SX9500

[Jonathan Cameron]

On 18/11/14 22:02, Jonathan Cameron wrote:
> On 17/11/14 15:25, Peter Meerwald wrote:
>>
>>> The device does not estimate distance, it only outputs a single bit which
>>> indicates proximity.  We use 0 to mean that an object is close and 1 otherwise,
>>> sort of an uncalibrated distance.  From what I understand in the ABI
>>> specification, this is allowed.
>>
>> perhaps the input subsystem would be a better fit for this driver/device?
>> what is it typically used for?
>>
>> regards, p.
>>
> Hi Peter,
> 
> Whilst it may be the case that this particular one might have a reasonable
> home in input, these are often integrated with ambient light sensors
> and as such we already have a quite a few proximity sensors in IIO...
> 
> Interestingly there is one obvious proximity sensor in input and that
> is a dual ambient light/ proximity part though I can't see any way
> of reading the light side of it.  Interesting...
Note that, given it describes itself as a button trip I can entirely see
your point with this one!  I wrote my reply before opening the datasheet.
oops.

The device does seem to provide access to measurements related to
the capacitance sensed so might be rather more flexible than just
a button though.

Re: [PATCH 0/2] iio: driver for Semtech SX9500

[Peter Meerwald]

Hi,

> >>> The device does not estimate distance, it only outputs a single bit which
> >>> indicates proximity.  We use 0 to mean that an object is close and 1 otherwise,
> >>> sort of an uncalibrated distance.  From what I understand in the ABI
> >>> specification, this is allowed.
> >>
> >> perhaps the input subsystem would be a better fit for this driver/device?
> >> what is it typically used for?
> >>
> >> regards, p.
> >>
> > Hi Peter,
> > 
> > Whilst it may be the case that this particular one might have a reasonable
> > home in input, these are often integrated with ambient light sensors
> > and as such we already have a quite a few proximity sensors in IIO...
> > 
> > Interestingly there is one obvious proximity sensor in input and that
> > is a dual ambient light/ proximity part though I can't see any way
> > of reading the light side of it.  Interesting...
> Note that, given it describes itself as a button trip I can entirely see
> your point with this one!  I wrote my reply before opening the datasheet.
> oops.
> 
> The device does seem to provide access to measurements related to
> the capacitance sensed so might be rather more flexible than just
> a button though.

yes, it depends what you want to use it for
if there is some aspect of measurement I think it has a place in IIO

the chip can report proximity values (reg. 0x21)

the proposed driver just seems to be targetted at realizing a button...

regards, p.

-- 

Peter Meerwald
+43-664-2444418 (mobile)

Re: [PATCH 0/2] iio: driver for Semtech SX9500

[Vlad Dogaru]

On Tue, Nov 18, 2014 at 10:12:32PM +0000, Jonathan Cameron wrote:
> On 18/11/14 22:02, Jonathan Cameron wrote:
> > On 17/11/14 15:25, Peter Meerwald wrote:
> >>
> >>> The device does not estimate distance, it only outputs a single bit which
> >>> indicates proximity.  We use 0 to mean that an object is close and 1 otherwise,
> >>> sort of an uncalibrated distance.  From what I understand in the ABI
> >>> specification, this is allowed.
> >>
> >> perhaps the input subsystem would be a better fit for this driver/device?
> >> what is it typically used for?

We have this part listed under "proximity sensors", so I thought it
belongs in iio.  We don't have a device that actually uses the SX9500,
I'm using an evaluation board and an I2C bridge right now :)

> > Whilst it may be the case that this particular one might have a reasonable
> > home in input, these are often integrated with ambient light sensors
> > and as such we already have a quite a few proximity sensors in IIO...
> > 
> > Interestingly there is one obvious proximity sensor in input and that
> > is a dual ambient light/ proximity part though I can't see any way
> > of reading the light side of it.  Interesting...
> Note that, given it describes itself as a button trip I can entirely see
> your point with this one!  I wrote my reply before opening the datasheet.
> oops.
> 
> The device does seem to provide access to measurements related to
> the capacitance sensed so might be rather more flexible than just
> a button though.

I kept away from the measurements because they look like uncalibrated
information.  Then again, so is "0/1", as I mentioned initially.

Would you find it acceptable to expose the raw measures through
in_priximity0_raw, and keep the events as they are?  That way the raw
readings can give some basic indication of distance, while still being
able to use the events for near/far notification.

Thanks,
Vlad

Re: [PATCH 0/2] iio: driver for Semtech SX9500

[Vlad Dogaru]

On Wed, Nov 19, 2014 at 03:57:38PM +0200, Vlad Dogaru wrote:
> On Tue, Nov 18, 2014 at 10:12:32PM +0000, Jonathan Cameron wrote:
> > On 18/11/14 22:02, Jonathan Cameron wrote:
> > > On 17/11/14 15:25, Peter Meerwald wrote:
> > >>
> > >>> The device does not estimate distance, it only outputs a single bit which
> > >>> indicates proximity.  We use 0 to mean that an object is close and 1 otherwise,
> > >>> sort of an uncalibrated distance.  From what I understand in the ABI
> > >>> specification, this is allowed.
> > >>
> > >> perhaps the input subsystem would be a better fit for this driver/device?
> > >> what is it typically used for?
> 
> We have this part listed under "proximity sensors", so I thought it
> belongs in iio.  We don't have a device that actually uses the SX9500,
> I'm using an evaluation board and an I2C bridge right now :)
> 
> > > Whilst it may be the case that this particular one might have a reasonable
> > > home in input, these are often integrated with ambient light sensors
> > > and as such we already have a quite a few proximity sensors in IIO...
> > > 
> > > Interestingly there is one obvious proximity sensor in input and that
> > > is a dual ambient light/ proximity part though I can't see any way
> > > of reading the light side of it.  Interesting...
> > Note that, given it describes itself as a button trip I can entirely see
> > your point with this one!  I wrote my reply before opening the datasheet.
> > oops.
> > 
> > The device does seem to provide access to measurements related to
> > the capacitance sensed so might be rather more flexible than just
> > a button though.
> 
> I kept away from the measurements because they look like uncalibrated
> information.  Then again, so is "0/1", as I mentioned initially.

To add to this:  the device senses proximity, not just touch.  I figured
it would be used in mobile devices, e.g. for shutting off the screen
when talking on the phone.  Moreover, Android supports proximity sensors
that only report "near/far" values.

> Would you find it acceptable to expose the raw measures through
> in_priximity0_raw, and keep the events as they are?  That way the raw
> readings can give some basic indication of distance, while still being
> able to use the events for near/far notification.

Re: [PATCH 1/2] iio: rename proximity sensors in kernel config

[Jonathan Cameron]

On 17/11/14 15:12, Vlad Dogaru wrote:
> Up till now, there was only a single sensor in the drivers/iio/proximity
> directory, and the config subsection was called 'Lightning sensors'.
> This will no longer be true once we introduce a general-purpose
> proximity sensor.
> 
> Signed-off-by: Vlad Dogaru <vlad.dogaru@intel.com>
Hmm.  The lightning sensor is such an oddity I think I'd prefer that
you just add a second menu in this kconfig file for more
conventional proximity sensors.

Thanks,

Jonathan
> ---
>  drivers/iio/proximity/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
> index 0c8cdf5..a131ead 100644
> --- a/drivers/iio/proximity/Kconfig
> +++ b/drivers/iio/proximity/Kconfig
> @@ -2,7 +2,7 @@
>  # Proximity sensors
>  #
>  
> -menu "Lightning sensors"
> +menu "Proximity sensors"
>  
>  config AS3935
>  	tristate "AS3935 Franklin lightning sensor"
>