* [PATCH v1 0/3] Added LTR501 Interrupt support @ 2015-04-01 2:55 Kuppuswamy Sathyanarayanan 2015-04-01 2:55 ` [PATCH v1 1/3] iio: ltr501: Add interrupt support Kuppuswamy Sathyanarayanan ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: Kuppuswamy Sathyanarayanan @ 2015-04-01 2:55 UTC (permalink / raw) To: jic23, pmeerw; +Cc: linux-iio, srinivas.pandruvada, sathyanarayanan.kuppuswamy This patchset adds interrupt support for LTR501 chip. Also added acpi enumaration support. Please let me know your review comments. v1: 1. Added support to enable ALS & PS intterupts based on threshold settings. 2. Added support to control intrrupt rate. 3. Added acpi enumeration support. Kuppuswamy Sathyanarayanan (3): iio: ltr501: Add interrupt support iio: ltr501: Add interrupt rate control support iio: ltr501: Add ACPI enumeration support drivers/iio/light/ltr501.c | 395 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 392 insertions(+), 3 deletions(-) -- 1.9.1 ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v1 1/3] iio: ltr501: Add interrupt support 2015-04-01 2:55 [PATCH v1 0/3] Added LTR501 Interrupt support Kuppuswamy Sathyanarayanan @ 2015-04-01 2:55 ` Kuppuswamy Sathyanarayanan 2015-04-01 2:55 ` [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support Kuppuswamy Sathyanarayanan ` (2 subsequent siblings) 3 siblings, 0 replies; 21+ messages in thread From: Kuppuswamy Sathyanarayanan @ 2015-04-01 2:55 UTC (permalink / raw) To: jic23, pmeerw; +Cc: linux-iio, srinivas.pandruvada, sathyanarayanan.kuppuswamy This patch adds interrupt support for Liteon 501 chip. Interrupt will be generated whenever ALS or proximity data exceeds values given in upper and lower threshold register settings. Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> --- drivers/iio/light/ltr501.c | 302 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 299 insertions(+), 3 deletions(-) diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c index 62b7072..16c3f7a 100644 --- a/drivers/iio/light/ltr501.c +++ b/drivers/iio/light/ltr501.c @@ -9,7 +9,7 @@ * * 7-bit I2C slave address 0x23 * - * TODO: interrupt, threshold, measurement rate, IR LED characteristics + * TODO: measurement rate, IR LED characteristics */ #include <linux/module.h> @@ -18,6 +18,7 @@ #include <linux/delay.h> #include <linux/iio/iio.h> +#include <linux/iio/events.h> #include <linux/iio/sysfs.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/buffer.h> @@ -33,6 +34,11 @@ #define LTR501_ALS_DATA0 0x8a /* 16-bit, little endian */ #define LTR501_ALS_PS_STATUS 0x8c #define LTR501_PS_DATA 0x8d /* 16-bit, little endian */ +#define LTR501_INTR 0x8f /* output mode, polarity, mode */ +#define LTR501_PS_THRESH_UP 0x90 /* 11 bit, ps upper threshold */ +#define LTR501_PS_THRESH_LOW 0x92 /* 11 bit, ps lower threshold */ +#define LTR501_ALS_THRESH_UP 0x97 /* 16 bit, ALS upper threshold */ +#define LTR501_ALS_THRESH_LOW 0x99 /* 16 bit, ALS lower threshold */ #define LTR501_ALS_CONTR_SW_RESET BIT(2) #define LTR501_CONTR_PS_GAIN_MASK (BIT(3) | BIT(2)) @@ -40,10 +46,28 @@ #define LTR501_CONTR_ALS_GAIN_MASK BIT(3) #define LTR501_CONTR_ACTIVE BIT(1) +#define LTR501_STATUS_ALS_INTR BIT(3) #define LTR501_STATUS_ALS_RDY BIT(2) +#define LTR501_STATUS_PS_INTR BIT(1) #define LTR501_STATUS_PS_RDY BIT(0) +#define LTR501_INTR_OUTPUT_MODE_MASK BIT(3) +#define LTR501_INTR_OUTPUT_MODE_LATCHED ~BIT(3) +#define LTR501_INTR_OUTPUT_MODE_DIRECT BIT(3) +#define LTR501_INTR_POLARITY_MASK BIT(2) +#define LTR501_INTR_POLARITY_LOGIC_0 ~BIT(2) +#define LTR501_INTR_POLARITY_LOGIC_1 BIT(2) +#define LTR501_INTR_MODE_MASK (BIT(1) | BIT(0)) +#define LTR501_INTR_MODE_NONE 0 +#define LTR501_INTR_MODE_PS_MASK BIT(0) +#define LTR501_INTR_MODE_PS BIT(0) +#define LTR501_INTR_MODE_ALS_MASK BIT(1) +#define LTR501_INTR_MODE_ALS BIT(1) +#define LTR501_INTR_MODE_ALS_PS 3 + #define LTR501_PS_DATA_MASK 0x7ff +#define LTR501_PS_THRESH_MASK 0x7ff +#define LTR501_ALS_THRESH_MASK 0xffff struct ltr501_data { struct i2c_client *client; @@ -70,6 +94,20 @@ static int ltr501_drdy(struct ltr501_data *data, u8 drdy_mask) return -EIO; } +static int ltr501_set_intr_reg(struct ltr501_data *data, u8 mask, u8 val) +{ + int ret; + u8 new_val; + + ret = i2c_smbus_read_byte_data(data->client, LTR501_INTR); + if (ret < 0) + return ret; + + new_val = (ret & ~mask) | (val & mask); + + return i2c_smbus_write_byte_data(data->client, LTR501_INTR, new_val); +} + static int ltr501_read_als(struct ltr501_data *data, __le16 buf[2]) { int ret = ltr501_drdy(data, LTR501_STATUS_ALS_RDY); @@ -88,6 +126,43 @@ static int ltr501_read_ps(struct ltr501_data *data) return i2c_smbus_read_word_data(data->client, LTR501_PS_DATA); } +static const struct iio_event_spec ltr501_als_event_spec[] = { + { + .type = IIO_EV_TYPE_THRESH, + .dir = IIO_EV_DIR_RISING, + .mask_separate = BIT(IIO_EV_INFO_VALUE), + }, + { + .type = IIO_EV_TYPE_THRESH, + .dir = IIO_EV_DIR_FALLING, + .mask_separate = BIT(IIO_EV_INFO_VALUE), + }, + { + .type = IIO_EV_TYPE_THRESH, + .dir = IIO_EV_DIR_EITHER, + .mask_separate = BIT(IIO_EV_INFO_ENABLE), + }, + +}; + +static const struct iio_event_spec ltr501_pxs_event_spec[] = { + { + .type = IIO_EV_TYPE_THRESH, + .dir = IIO_EV_DIR_RISING, + .mask_separate = BIT(IIO_EV_INFO_VALUE), + }, + { + .type = IIO_EV_TYPE_THRESH, + .dir = IIO_EV_DIR_FALLING, + .mask_separate = BIT(IIO_EV_INFO_VALUE), + }, + { + .type = IIO_EV_TYPE_THRESH, + .dir = IIO_EV_DIR_EITHER, + .mask_separate = BIT(IIO_EV_INFO_ENABLE), + }, +}; + #define LTR501_INTENSITY_CHANNEL(_idx, _addr, _mod, _shared) { \ .type = IIO_INTENSITY, \ .modified = 1, \ @@ -101,7 +176,9 @@ static int ltr501_read_ps(struct ltr501_data *data) .realbits = 16, \ .storagebits = 16, \ .endianness = IIO_CPU, \ - } \ + }, \ + .event_spec = ltr501_als_event_spec,\ + .num_event_specs = ARRAY_SIZE(ltr501_als_event_spec),\ } static const struct iio_chan_spec ltr501_channels[] = { @@ -120,6 +197,8 @@ static const struct iio_chan_spec ltr501_channels[] = { .storagebits = 16, .endianness = IIO_CPU, }, + .event_spec = ltr501_pxs_event_spec, + .num_event_specs = ARRAY_SIZE(ltr501_pxs_event_spec), }, IIO_CHAN_SOFT_TIMESTAMP(3), }; @@ -235,6 +314,167 @@ static int ltr501_write_raw(struct iio_dev *indio_dev, return -EINVAL; } +static int ltr501_read_thresh(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 ltr501_data *data = iio_priv(indio_dev); + int ret = -EINVAL; + + switch (chan->type) { + case IIO_INTENSITY: + mutex_lock(&data->lock_als); + switch (dir) { + case IIO_EV_DIR_RISING: + ret = i2c_smbus_read_word_data(data->client, + LTR501_ALS_THRESH_UP); + break; + case IIO_EV_DIR_FALLING: + ret = i2c_smbus_read_word_data(data->client, + LTR501_ALS_THRESH_LOW); + break; + default: + break; + } + mutex_unlock(&data->lock_als); + *val = ret & LTR501_ALS_THRESH_MASK; + break; + case IIO_PROXIMITY: + mutex_lock(&data->lock_ps); + switch (dir) { + case IIO_EV_DIR_RISING: + ret = i2c_smbus_read_word_data(data->client, + LTR501_PS_THRESH_UP); + break; + case IIO_EV_DIR_FALLING: + ret = i2c_smbus_read_word_data(data->client, + LTR501_PS_THRESH_LOW); + break; + default: + break; + } + mutex_unlock(&data->lock_ps); + *val = ret & LTR501_PS_THRESH_MASK; + break; + default: + break; + } + + return ret < 0 ? ret : IIO_VAL_INT; +} + +static int ltr501_write_thresh(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 ltr501_data *data = iio_priv(indio_dev); + u16 new_val = 0; + int ret = -EINVAL; + + switch (chan->type) { + case IIO_INTENSITY: + mutex_lock(&data->lock_als); + new_val = val & LTR501_ALS_THRESH_MASK; + switch (dir) { + case IIO_EV_DIR_RISING: + ret = i2c_smbus_write_word_data(data->client, + LTR501_ALS_THRESH_UP, + new_val); + break; + case IIO_EV_DIR_FALLING: + ret = i2c_smbus_write_word_data(data->client, + LTR501_ALS_THRESH_LOW, + new_val); + break; + default: + break; + } + mutex_unlock(&data->lock_als); + break; + case IIO_PROXIMITY: + switch (dir) { + mutex_lock(&data->lock_ps); + new_val = val & LTR501_PS_THRESH_MASK; + case IIO_EV_DIR_RISING: + ret = i2c_smbus_write_word_data(data->client, + LTR501_PS_THRESH_UP, + new_val); + break; + case IIO_EV_DIR_FALLING: + ret = i2c_smbus_write_word_data(data->client, + LTR501_PS_THRESH_LOW, + new_val); + break; + default: + break; + } + mutex_unlock(&data->lock_ps); + break; + + default: + break; + } + + return ret < 0 ? ret : IIO_VAL_INT; +} + +static int ltr501_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 ltr501_data *data = iio_priv(indio_dev); + int ret = -EINVAL; + + switch (chan->type) { + case IIO_INTENSITY: + mutex_lock(&data->lock_als); + ret = i2c_smbus_read_byte_data(data->client, LTR501_INTR); + mutex_unlock(&data->lock_als); + return ret < 0 ? ret : ret & LTR501_INTR_MODE_ALS_MASK; + case IIO_PROXIMITY: + mutex_lock(&data->lock_ps); + ret = i2c_smbus_read_byte_data(data->client, LTR501_INTR); + mutex_unlock(&data->lock_ps); + return ret < 0 ? ret : ret & LTR501_INTR_MODE_PS_MASK; + default: + break; + } + + return ret; +} + +static int ltr501_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 ltr501_data *data = iio_priv(indio_dev); + int ret = -EINVAL; + + switch (chan->type) { + case IIO_INTENSITY: + mutex_lock(&data->lock_als); + ret = ltr501_set_intr_reg(data, LTR501_INTR_MODE_ALS_MASK, + (state ? LTR501_INTR_MODE_ALS : + LTR501_INTR_MODE_NONE)); + mutex_unlock(&data->lock_als); + break; + case IIO_PROXIMITY: + mutex_lock(&data->lock_ps); + ret = ltr501_set_intr_reg(data, LTR501_INTR_MODE_PS_MASK, + (state ? LTR501_INTR_MODE_PS : + LTR501_INTR_MODE_NONE)); + mutex_unlock(&data->lock_ps); + break; + default: + break; + } + + return ret < 0 ? ret : IIO_VAL_INT; +} + static IIO_CONST_ATTR(in_proximity_scale_available, "1 0.25 0.125 0.0625"); static IIO_CONST_ATTR(in_intensity_scale_available, "1 0.005"); @@ -248,10 +488,21 @@ static const struct attribute_group ltr501_attribute_group = { .attrs = ltr501_attributes, }; +static const struct iio_info ltr501_info_no_irq = { + .read_raw = ltr501_read_raw, + .write_raw = ltr501_write_raw, + .attrs = <r501_attribute_group, + .driver_module = THIS_MODULE, +}; + static const struct iio_info ltr501_info = { .read_raw = ltr501_read_raw, .write_raw = ltr501_write_raw, .attrs = <r501_attribute_group, + .read_event_value = <r501_read_thresh, + .write_event_value = <r501_write_thresh, + .read_event_config = <r501_read_event_config, + .write_event_config = <r501_write_event_config, .driver_module = THIS_MODULE, }; @@ -315,6 +566,36 @@ done: return IRQ_HANDLED; } +static irqreturn_t ltr501_interrupt_handler(int irq, void *private) +{ + struct iio_dev *dev_info = private; + struct ltr501_data *data = iio_priv(dev_info); + int ret; + + ret = i2c_smbus_read_byte_data(data->client, LTR501_ALS_PS_STATUS); + if (ret < 0) { + dev_err(&data->client->dev, + "irq read int reg failed\n"); + return IRQ_HANDLED; + } + + if (ret & LTR501_STATUS_ALS_INTR) + iio_push_event(dev_info, + IIO_UNMOD_EVENT_CODE(IIO_INTENSITY, 0, + IIO_EV_TYPE_THRESH, + IIO_EV_DIR_EITHER), + iio_get_time_ns()); + + if (ret & LTR501_STATUS_PS_INTR) + iio_push_event(dev_info, + IIO_UNMOD_EVENT_CODE(IIO_PROXIMITY, 0, + IIO_EV_TYPE_THRESH, + IIO_EV_DIR_EITHER), + iio_get_time_ns()); + + return IRQ_HANDLED; +} + static int ltr501_init(struct ltr501_data *data) { int ret; @@ -357,7 +638,6 @@ static int ltr501_probe(struct i2c_client *client, return -ENODEV; indio_dev->dev.parent = &client->dev; - indio_dev->info = <r501_info; indio_dev->channels = ltr501_channels; indio_dev->num_channels = ARRAY_SIZE(ltr501_channels); indio_dev->name = LTR501_DRV_NAME; @@ -367,6 +647,22 @@ static int ltr501_probe(struct i2c_client *client, if (ret < 0) return ret; + if (client->irq > 0) { + indio_dev->info = <r501_info; + ret = devm_request_threaded_irq(&client->dev, client->irq, + NULL, ltr501_interrupt_handler, + IRQF_TRIGGER_FALLING | + IRQF_ONESHOT, + "ltr501_thresh_event", + indio_dev); + if (ret) { + dev_err(&client->dev, "request irq (%d) failed\n", + client->irq); + return ret; + } + } else + indio_dev->info = <r501_info_no_irq; + ret = iio_triggered_buffer_setup(indio_dev, NULL, ltr501_trigger_handler, NULL); if (ret) -- 1.9.1 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 2:55 [PATCH v1 0/3] Added LTR501 Interrupt support Kuppuswamy Sathyanarayanan 2015-04-01 2:55 ` [PATCH v1 1/3] iio: ltr501: Add interrupt support Kuppuswamy Sathyanarayanan @ 2015-04-01 2:55 ` Kuppuswamy Sathyanarayanan 2015-04-01 14:04 ` Daniel Baluta 2015-04-01 2:55 ` [PATCH v1 3/3] iio: ltr501: Add ACPI enumeration support Kuppuswamy Sathyanarayanan 2015-04-01 13:02 ` [PATCH v1 0/3] Added LTR501 Interrupt support Daniel Baluta 3 siblings, 1 reply; 21+ messages in thread From: Kuppuswamy Sathyanarayanan @ 2015-04-01 2:55 UTC (permalink / raw) To: jic23, pmeerw; +Cc: linux-iio, srinivas.pandruvada, sathyanarayanan.kuppuswamy Added rate control support for ALS and proximity threshold interrupts. Setting <n> to ALS intr_persist sysfs node would generate interrupt whenever ALS data cross either upper or lower threshold limits <n> number of times. Similarly setting <m> to proximity intr_persist sysfs node would genere interrupt whenever proximity data falls outside threshold limit <m> number of times. Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> --- drivers/iio/light/ltr501.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c index 16c3f7a..e8f5019 100644 --- a/drivers/iio/light/ltr501.c +++ b/drivers/iio/light/ltr501.c @@ -39,6 +39,7 @@ #define LTR501_PS_THRESH_LOW 0x92 /* 11 bit, ps lower threshold */ #define LTR501_ALS_THRESH_UP 0x97 /* 16 bit, ALS upper threshold */ #define LTR501_ALS_THRESH_LOW 0x99 /* 16 bit, ALS lower threshold */ +#define LTR501_INTR_PRST 0x9e /* ps thresh, als thresh */ #define LTR501_ALS_CONTR_SW_RESET BIT(2) #define LTR501_CONTR_PS_GAIN_MASK (BIT(3) | BIT(2)) @@ -65,6 +66,9 @@ #define LTR501_INTR_MODE_ALS BIT(1) #define LTR501_INTR_MODE_ALS_PS 3 +#define LTR501_INTR_PRST_ALS_MASK 0x0f +#define LTR501_INTR_PRST_PS_MASK 0xf0 + #define LTR501_PS_DATA_MASK 0x7ff #define LTR501_PS_THRESH_MASK 0x7ff #define LTR501_ALS_THRESH_MASK 0xffff @@ -126,6 +130,75 @@ static int ltr501_read_ps(struct ltr501_data *data) return i2c_smbus_read_word_data(data->client, LTR501_PS_DATA); } +static ssize_t ltr501_read_intr_prst(struct iio_dev *indio_dev, + uintptr_t private, + const struct iio_chan_spec *chan, + char *buf) +{ + struct ltr501_data *data = iio_priv(indio_dev); + int ret = -EINVAL; + + switch (chan->type) { + case IIO_INTENSITY: + mutex_lock(&data->lock_als); + ret = i2c_smbus_read_byte_data(data->client, LTR501_INTR_PRST); + mutex_unlock(&data->lock_als); + return ret < 0 ? ret : sprintf(buf, "%u\n", + ret & LTR501_INTR_PRST_ALS_MASK); + case IIO_PROXIMITY: + mutex_lock(&data->lock_ps); + ret = i2c_smbus_read_byte_data(data->client, LTR501_INTR_PRST); + mutex_unlock(&data->lock_ps); + return ret < 0 ? ret : sprintf(buf, "%u\n", + (ret & LTR501_INTR_PRST_PS_MASK) >> 4); + default: + break; + } + + return ret; +} + +static ssize_t ltr501_write_intr_prst(struct iio_dev *indio_dev, + uintptr_t private, + const struct iio_chan_spec *chan, + const char *buf, size_t len) +{ + struct ltr501_data *data = iio_priv(indio_dev); + int ret = -EINVAL; + u8 new_val; + + ret = kstrtou8(buf, 10, &new_val); + if (ret) + return ret; + + ret = i2c_smbus_read_byte_data(data->client, LTR501_INTR_PRST); + if (ret < 0) + return ret; + + switch (chan->type) { + case IIO_INTENSITY: + mutex_lock(&data->lock_als); + new_val = (ret & ~LTR501_INTR_PRST_ALS_MASK) | + (new_val & LTR501_INTR_PRST_ALS_MASK); + ret = i2c_smbus_write_byte_data(data->client, + LTR501_INTR_PRST, new_val); + mutex_unlock(&data->lock_als); + break; + case IIO_PROXIMITY: + mutex_lock(&data->lock_ps); + new_val = (ret & ~LTR501_INTR_PRST_PS_MASK) | + ((new_val << 4) & LTR501_INTR_PRST_PS_MASK); + ret = i2c_smbus_write_byte_data(data->client, + LTR501_INTR_PRST, new_val); + mutex_unlock(&data->lock_ps); + break; + default: + break; + } + + return ret < 0 ? ret : len; +} + static const struct iio_event_spec ltr501_als_event_spec[] = { { .type = IIO_EV_TYPE_THRESH, @@ -163,6 +236,16 @@ static const struct iio_event_spec ltr501_pxs_event_spec[] = { }, }; +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { + { + .name = "intr_persist", + .read = ltr501_read_intr_prst, + .write = ltr501_write_intr_prst, + .shared = IIO_SHARED_BY_TYPE, + }, + {}, +}; + #define LTR501_INTENSITY_CHANNEL(_idx, _addr, _mod, _shared) { \ .type = IIO_INTENSITY, \ .modified = 1, \ @@ -179,6 +262,7 @@ static const struct iio_event_spec ltr501_pxs_event_spec[] = { }, \ .event_spec = ltr501_als_event_spec,\ .num_event_specs = ARRAY_SIZE(ltr501_als_event_spec),\ + .ext_info = ltr501_ext_info,\ } static const struct iio_chan_spec ltr501_channels[] = { @@ -199,6 +283,7 @@ static const struct iio_chan_spec ltr501_channels[] = { }, .event_spec = ltr501_pxs_event_spec, .num_event_specs = ARRAY_SIZE(ltr501_pxs_event_spec), + .ext_info = ltr501_ext_info, }, IIO_CHAN_SOFT_TIMESTAMP(3), }; -- 1.9.1 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 2:55 ` [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support Kuppuswamy Sathyanarayanan @ 2015-04-01 14:04 ` Daniel Baluta 2015-04-01 14:39 ` Lars-Peter Clausen 2015-04-01 17:33 ` sathyanarayanan kuppuswamy 0 siblings, 2 replies; 21+ messages in thread From: Daniel Baluta @ 2015-04-01 14:04 UTC (permalink / raw) To: Kuppuswamy Sathyanarayanan Cc: Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On Wed, Apr 1, 2015 at 5:55 AM, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: > Added rate control support for ALS and proximity > threshold interrupts. > > Setting <n> to ALS intr_persist sysfs node would > generate interrupt whenever ALS data cross either > upper or lower threshold limits <n> number of times. > Similarly setting <m> to proximity intr_persist sysfs > node would genere interrupt whenever proximity data falls > outside threshold limit <m> number of times. > <snip> > +static ssize_t ltr501_read_intr_prst(struct iio_dev *indio_dev, > + uintptr_t private, > + const struct iio_chan_spec *chan, > + char *buf) > +{ > + struct ltr501_data *data = iio_priv(indio_dev); > + int ret = -EINVAL; > + > + switch (chan->type) { > + case IIO_INTENSITY: > + mutex_lock(&data->lock_als); > + ret = i2c_smbus_read_byte_data(data->client, LTR501_INTR_PRST); > + mutex_unlock(&data->lock_als); I am not sure I understand why is the mutex needed here? AFAIK I2C transactions are serialized. <snip> > +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { > + { > + .name = "intr_persist", > + .read = ltr501_read_intr_prst, > + .write = ltr501_write_intr_prst, > + .shared = IIO_SHARED_BY_TYPE, > + }, > + {}, > +}; > + Would be nice to standardize persistence attribute (IIO_CHAN_INFO_PERSISTENCE). thanks, Daniel. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 14:04 ` Daniel Baluta @ 2015-04-01 14:39 ` Lars-Peter Clausen 2015-04-01 15:02 ` Daniel Baluta 2015-04-01 17:33 ` sathyanarayanan kuppuswamy 1 sibling, 1 reply; 21+ messages in thread From: Lars-Peter Clausen @ 2015-04-01 14:39 UTC (permalink / raw) To: Daniel Baluta, Kuppuswamy Sathyanarayanan Cc: Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On 04/01/2015 04:04 PM, Daniel Baluta wrote: [...] > >> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >> + { >> + .name = "intr_persist", >> + .read = ltr501_read_intr_prst, >> + .write = ltr501_write_intr_prst, >> + .shared = IIO_SHARED_BY_TYPE, >> + }, >> + {}, >> +}; >> + > Would be nice to standardize persistence attribute (IIO_CHAN_INFO_PERSISTENCE). If I understand the behavior correctly it causes that the event needs to be triggered at least n times before the event is reported by the chip. In my opinion 'persistence' is not a good term for that. I'm not sure what a better term is but I think it should go more in the direction of ratelimit or something. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 14:39 ` Lars-Peter Clausen @ 2015-04-01 15:02 ` Daniel Baluta 2015-04-01 15:15 ` Lars-Peter Clausen 0 siblings, 1 reply; 21+ messages in thread From: Daniel Baluta @ 2015-04-01 15:02 UTC (permalink / raw) To: Lars-Peter Clausen Cc: Kuppuswamy Sathyanarayanan, Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On Wed, Apr 1, 2015 at 5:39 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: > On 04/01/2015 04:04 PM, Daniel Baluta wrote: > [...] >> >> >>> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >>> + { >>> + .name = "intr_persist", >>> + .read = ltr501_read_intr_prst, >>> + .write = ltr501_write_intr_prst, >>> + .shared = IIO_SHARED_BY_TYPE, >>> + }, >>> + {}, >>> +}; >>> + >> >> Would be nice to standardize persistence attribute >> (IIO_CHAN_INFO_PERSISTENCE). > > > If I understand the behavior correctly it causes that the event needs to be > triggered at least n times before the event is reported by the chip. In my > opinion 'persistence' is not a good term for that. I'm not sure what a > better term is but I think it should go more in the direction of ratelimit > or something. I've seen this term used for many devices: * TSL25911 ambient light sensor [1] [ One set of thresholds can be configured to trigger an interrupt only when the ambient light exceeds them for a configurable amount of time (persistence) ] * TAOS TCS34725 ambient light sensor [2] [ The interrupt persistence filter allows the user to define the number of consecutive out-of-threshold events necessary before generating an interrupt. ] * Avago SAPDS-9950, Sensortek STK3310 I think the TSL25911 datasheet best describes this parameter, as the amount of time that ambient light should exceed a threshold until an interrupt is generated. thanks, Daniel. [1] http://www.adafruit.com/datasheets/TSL25911_Datasheet_EN_v1.pdf [2] http://www.adafruit.com/datasheets/TCS34725.pdf ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 15:02 ` Daniel Baluta @ 2015-04-01 15:15 ` Lars-Peter Clausen 2015-04-01 17:45 ` sathyanarayanan kuppuswamy 2015-04-01 20:19 ` Jonathan Cameron 0 siblings, 2 replies; 21+ messages in thread From: Lars-Peter Clausen @ 2015-04-01 15:15 UTC (permalink / raw) To: Daniel Baluta Cc: Kuppuswamy Sathyanarayanan, Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On 04/01/2015 05:02 PM, Daniel Baluta wrote: > On Wed, Apr 1, 2015 at 5:39 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: >> On 04/01/2015 04:04 PM, Daniel Baluta wrote: >> [...] >>> >>> >>>> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >>>> + { >>>> + .name = "intr_persist", >>>> + .read = ltr501_read_intr_prst, >>>> + .write = ltr501_write_intr_prst, >>>> + .shared = IIO_SHARED_BY_TYPE, >>>> + }, >>>> + {}, >>>> +}; >>>> + >>> >>> Would be nice to standardize persistence attribute >>> (IIO_CHAN_INFO_PERSISTENCE). >> >> >> If I understand the behavior correctly it causes that the event needs to be >> triggered at least n times before the event is reported by the chip. In my >> opinion 'persistence' is not a good term for that. I'm not sure what a >> better term is but I think it should go more in the direction of ratelimit >> or something. > > I've seen this term used for many devices: > > * TSL25911 ambient light sensor [1] > > [ One set of thresholds can be configured to trigger an interrupt only when > the ambient light exceeds them for a configurable amount of time (persistence) > ] > > * TAOS TCS34725 ambient light sensor [2] > [ > The interrupt persistence filter allows the user to define the number > of consecutive > out-of-threshold events necessary before generating an interrupt. > ] > > * Avago SAPDS-9950, Sensortek STK3310 > > I think the TSL25911 datasheet best describes this parameter, as the > amount of time > that ambient light should exceed a threshold until an interrupt is generated. Ok, that makes more sense. I misunderstood the initial description as that the signal would have to go first above the threshold then below the threshold, and this for a number of times. Whereas it needs to exceed the threshold for a certain amount of time before the event is triggered. If it goes below the threshold before the persistence interval no event is triggered and the counter is reset. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 15:15 ` Lars-Peter Clausen @ 2015-04-01 17:45 ` sathyanarayanan kuppuswamy 2015-04-01 17:48 ` Lars-Peter Clausen 2015-04-01 20:19 ` Jonathan Cameron 1 sibling, 1 reply; 21+ messages in thread From: sathyanarayanan kuppuswamy @ 2015-04-01 17:45 UTC (permalink / raw) To: Lars-Peter Clausen, Daniel Baluta Cc: Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On 04/01/2015 08:15 AM, Lars-Peter Clausen wrote: > On 04/01/2015 05:02 PM, Daniel Baluta wrote: >> On Wed, Apr 1, 2015 at 5:39 PM, Lars-Peter Clausen <lars@metafoo.de> >> wrote: >>> On 04/01/2015 04:04 PM, Daniel Baluta wrote: >>> [...] >>>> >>>> >>>>> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >>>>> + { >>>>> + .name = "intr_persist", >>>>> + .read = ltr501_read_intr_prst, >>>>> + .write = ltr501_write_intr_prst, >>>>> + .shared = IIO_SHARED_BY_TYPE, >>>>> + }, >>>>> + {}, >>>>> +}; >>>>> + >>>> >>>> Would be nice to standardize persistence attribute >>>> (IIO_CHAN_INFO_PERSISTENCE). >>> >>> >>> If I understand the behavior correctly it causes that the event >>> needs to be >>> triggered at least n times before the event is reported by the chip. >>> In my >>> opinion 'persistence' is not a good term for that. I'm not sure what a >>> better term is but I think it should go more in the direction of >>> ratelimit >>> or something. >> >> I've seen this term used for many devices: >> >> * TSL25911 ambient light sensor [1] >> >> [ One set of thresholds can be configured to trigger an interrupt >> only when >> the ambient light exceeds them for a configurable amount of time >> (persistence) >> ] >> >> * TAOS TCS34725 ambient light sensor [2] >> [ >> The interrupt persistence filter allows the user to define the number >> of consecutive >> out-of-threshold events necessary before generating an interrupt. >> ] >> >> * Avago SAPDS-9950, Sensortek STK3310 >> >> I think the TSL25911 datasheet best describes this parameter, as the >> amount of time >> that ambient light should exceed a threshold until an interrupt is >> generated. > > Ok, that makes more sense. I misunderstood the initial description as > that the signal would have to go first above the threshold then below > the threshold, and this for a number of times. Whereas it needs to > exceed the threshold for a certain amount of time before the event is > triggered. If it goes below the threshold before the persistence > interval no event is triggered and the counter is reset. Yes, it needs to cross the threshold n number of times before a event is generated. > > -- Sathyanarayanan Kuppuswamy Android kernel developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 17:45 ` sathyanarayanan kuppuswamy @ 2015-04-01 17:48 ` Lars-Peter Clausen 2015-04-01 19:06 ` sathyanarayanan kuppuswamy 0 siblings, 1 reply; 21+ messages in thread From: Lars-Peter Clausen @ 2015-04-01 17:48 UTC (permalink / raw) To: sathyanarayanan.kuppuswamy, Daniel Baluta Cc: Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On 04/01/2015 07:45 PM, sathyanarayanan kuppuswamy wrote: > > > On 04/01/2015 08:15 AM, Lars-Peter Clausen wrote: >> On 04/01/2015 05:02 PM, Daniel Baluta wrote: >>> On Wed, Apr 1, 2015 at 5:39 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: >>>> On 04/01/2015 04:04 PM, Daniel Baluta wrote: >>>> [...] >>>>> >>>>> >>>>>> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >>>>>> + { >>>>>> + .name = "intr_persist", >>>>>> + .read = ltr501_read_intr_prst, >>>>>> + .write = ltr501_write_intr_prst, >>>>>> + .shared = IIO_SHARED_BY_TYPE, >>>>>> + }, >>>>>> + {}, >>>>>> +}; >>>>>> + >>>>> >>>>> Would be nice to standardize persistence attribute >>>>> (IIO_CHAN_INFO_PERSISTENCE). >>>> >>>> >>>> If I understand the behavior correctly it causes that the event needs to be >>>> triggered at least n times before the event is reported by the chip. In my >>>> opinion 'persistence' is not a good term for that. I'm not sure what a >>>> better term is but I think it should go more in the direction of ratelimit >>>> or something. >>> >>> I've seen this term used for many devices: >>> >>> * TSL25911 ambient light sensor [1] >>> >>> [ One set of thresholds can be configured to trigger an interrupt only when >>> the ambient light exceeds them for a configurable amount of time >>> (persistence) >>> ] >>> >>> * TAOS TCS34725 ambient light sensor [2] >>> [ >>> The interrupt persistence filter allows the user to define the number >>> of consecutive >>> out-of-threshold events necessary before generating an interrupt. >>> ] >>> >>> * Avago SAPDS-9950, Sensortek STK3310 >>> >>> I think the TSL25911 datasheet best describes this parameter, as the >>> amount of time >>> that ambient light should exceed a threshold until an interrupt is >>> generated. >> >> Ok, that makes more sense. I misunderstood the initial description as that >> the signal would have to go first above the threshold then below the >> threshold, and this for a number of times. Whereas it needs to exceed the >> threshold for a certain amount of time before the event is triggered. If >> it goes below the threshold before the persistence interval no event is >> triggered and the counter is reset. > > Yes, it needs to cross the threshold n number of times before a event is > generated. Wait. It needs to cross the threshold or it needs to stay above the threshold? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 17:48 ` Lars-Peter Clausen @ 2015-04-01 19:06 ` sathyanarayanan kuppuswamy 2015-04-01 19:22 ` sathyanarayanan kuppuswamy 0 siblings, 1 reply; 21+ messages in thread From: sathyanarayanan kuppuswamy @ 2015-04-01 19:06 UTC (permalink / raw) To: Lars-Peter Clausen, Daniel Baluta Cc: Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On 04/01/2015 10:48 AM, Lars-Peter Clausen wrote: > On 04/01/2015 07:45 PM, sathyanarayanan kuppuswamy wrote: >> >> >> On 04/01/2015 08:15 AM, Lars-Peter Clausen wrote: >>> On 04/01/2015 05:02 PM, Daniel Baluta wrote: >>>> On Wed, Apr 1, 2015 at 5:39 PM, Lars-Peter Clausen >>>> <lars@metafoo.de> wrote: >>>>> On 04/01/2015 04:04 PM, Daniel Baluta wrote: >>>>> [...] >>>>>> >>>>>> >>>>>>> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >>>>>>> + { >>>>>>> + .name = "intr_persist", >>>>>>> + .read = ltr501_read_intr_prst, >>>>>>> + .write = ltr501_write_intr_prst, >>>>>>> + .shared = IIO_SHARED_BY_TYPE, >>>>>>> + }, >>>>>>> + {}, >>>>>>> +}; >>>>>>> + >>>>>> >>>>>> Would be nice to standardize persistence attribute >>>>>> (IIO_CHAN_INFO_PERSISTENCE). >>>>> >>>>> >>>>> If I understand the behavior correctly it causes that the event >>>>> needs to be >>>>> triggered at least n times before the event is reported by the >>>>> chip. In my >>>>> opinion 'persistence' is not a good term for that. I'm not sure >>>>> what a >>>>> better term is but I think it should go more in the direction of >>>>> ratelimit >>>>> or something. >>>> >>>> I've seen this term used for many devices: >>>> >>>> * TSL25911 ambient light sensor [1] >>>> >>>> [ One set of thresholds can be configured to trigger an interrupt >>>> only when >>>> the ambient light exceeds them for a configurable amount of time >>>> (persistence) >>>> ] >>>> >>>> * TAOS TCS34725 ambient light sensor [2] >>>> [ >>>> The interrupt persistence filter allows the user to define the number >>>> of consecutive >>>> out-of-threshold events necessary before generating an interrupt. >>>> ] >>>> >>>> * Avago SAPDS-9950, Sensortek STK3310 >>>> >>>> I think the TSL25911 datasheet best describes this parameter, as the >>>> amount of time >>>> that ambient light should exceed a threshold until an interrupt is >>>> generated. >>> >>> Ok, that makes more sense. I misunderstood the initial description >>> as that >>> the signal would have to go first above the threshold then below the >>> threshold, and this for a number of times. Whereas it needs to >>> exceed the >>> threshold for a certain amount of time before the event is >>> triggered. If >>> it goes below the threshold before the persistence interval no event is >>> triggered and the counter is reset. >> >> Yes, it needs to cross the threshold n number of times before a event is >> generated. > > Wait. It needs to cross the threshold or it needs to stay above the > threshold? Following is the logic for this chip. If ( data > Upper_threshold or data < Lower_threshold) generate_event() > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Sathyanarayanan Kuppuswamy Android kernel developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 19:06 ` sathyanarayanan kuppuswamy @ 2015-04-01 19:22 ` sathyanarayanan kuppuswamy 2015-04-09 10:16 ` Jonathan Cameron 0 siblings, 1 reply; 21+ messages in thread From: sathyanarayanan kuppuswamy @ 2015-04-01 19:22 UTC (permalink / raw) To: Lars-Peter Clausen, Daniel Baluta Cc: Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On 04/01/2015 12:06 PM, sathyanarayanan kuppuswamy wrote: > > > On 04/01/2015 10:48 AM, Lars-Peter Clausen wrote: >> On 04/01/2015 07:45 PM, sathyanarayanan kuppuswamy wrote: >>> >>> >>> On 04/01/2015 08:15 AM, Lars-Peter Clausen wrote: >>>> On 04/01/2015 05:02 PM, Daniel Baluta wrote: >>>>> On Wed, Apr 1, 2015 at 5:39 PM, Lars-Peter Clausen >>>>> <lars@metafoo.de> wrote: >>>>>> On 04/01/2015 04:04 PM, Daniel Baluta wrote: >>>>>> [...] >>>>>>> >>>>>>> >>>>>>>> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >>>>>>>> + { >>>>>>>> + .name = "intr_persist", >>>>>>>> + .read = ltr501_read_intr_prst, >>>>>>>> + .write = ltr501_write_intr_prst, >>>>>>>> + .shared = IIO_SHARED_BY_TYPE, >>>>>>>> + }, >>>>>>>> + {}, >>>>>>>> +}; >>>>>>>> + >>>>>>> >>>>>>> Would be nice to standardize persistence attribute >>>>>>> (IIO_CHAN_INFO_PERSISTENCE). >>>>>> >>>>>> >>>>>> If I understand the behavior correctly it causes that the event >>>>>> needs to be >>>>>> triggered at least n times before the event is reported by the >>>>>> chip. In my >>>>>> opinion 'persistence' is not a good term for that. I'm not sure >>>>>> what a >>>>>> better term is but I think it should go more in the direction of >>>>>> ratelimit >>>>>> or something. >>>>> >>>>> I've seen this term used for many devices: >>>>> >>>>> * TSL25911 ambient light sensor [1] >>>>> >>>>> [ One set of thresholds can be configured to trigger an interrupt >>>>> only when >>>>> the ambient light exceeds them for a configurable amount of time >>>>> (persistence) >>>>> ] >>>>> >>>>> * TAOS TCS34725 ambient light sensor [2] >>>>> [ >>>>> The interrupt persistence filter allows the user to define the number >>>>> of consecutive >>>>> out-of-threshold events necessary before generating an interrupt. >>>>> ] >>>>> >>>>> * Avago SAPDS-9950, Sensortek STK3310 >>>>> >>>>> I think the TSL25911 datasheet best describes this parameter, as the >>>>> amount of time >>>>> that ambient light should exceed a threshold until an interrupt is >>>>> generated. >>>> >>>> Ok, that makes more sense. I misunderstood the initial description >>>> as that >>>> the signal would have to go first above the threshold then below the >>>> threshold, and this for a number of times. Whereas it needs to >>>> exceed the >>>> threshold for a certain amount of time before the event is >>>> triggered. If >>>> it goes below the threshold before the persistence interval no >>>> event is >>>> triggered and the counter is reset. >>> >>> Yes, it needs to cross the threshold n number of times before a >>> event is >>> generated. >> >> Wait. It needs to cross the threshold or it needs to stay above the >> threshold? > Following is the logic for this chip. > > If ( data > Upper_threshold or data < Lower_threshold) > generate_event() Missed to add <n> times logic If ( data > Upper_threshold or data < Lower_threshold) { increment_count; if (count >= n) { generate_event() reset_count() } } >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- Sathyanarayanan Kuppuswamy Android kernel developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 19:22 ` sathyanarayanan kuppuswamy @ 2015-04-09 10:16 ` Jonathan Cameron 2015-04-09 22:35 ` sathyanarayanan kuppuswamy 0 siblings, 1 reply; 21+ messages in thread From: Jonathan Cameron @ 2015-04-09 10:16 UTC (permalink / raw) To: sathyanarayanan.kuppuswamy, Lars-Peter Clausen, Daniel Baluta Cc: Peter Meerwald, linux-iio, Srinivas Pandruvada On 01/04/15 20:22, sathyanarayanan kuppuswamy wrote: > > > On 04/01/2015 12:06 PM, sathyanarayanan kuppuswamy wrote: >> >> >> On 04/01/2015 10:48 AM, Lars-Peter Clausen wrote: >>> On 04/01/2015 07:45 PM, sathyanarayanan kuppuswamy wrote: >>>> >>>> >>>> On 04/01/2015 08:15 AM, Lars-Peter Clausen wrote: >>>>> On 04/01/2015 05:02 PM, Daniel Baluta wrote: >>>>>> On Wed, Apr 1, 2015 at 5:39 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: >>>>>>> On 04/01/2015 04:04 PM, Daniel Baluta wrote: >>>>>>> [...] >>>>>>>> >>>>>>>> >>>>>>>>> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >>>>>>>>> + { >>>>>>>>> + .name = "intr_persist", >>>>>>>>> + .read = ltr501_read_intr_prst, >>>>>>>>> + .write = ltr501_write_intr_prst, >>>>>>>>> + .shared = IIO_SHARED_BY_TYPE, >>>>>>>>> + }, >>>>>>>>> + {}, >>>>>>>>> +}; >>>>>>>>> + >>>>>>>> >>>>>>>> Would be nice to standardize persistence attribute >>>>>>>> (IIO_CHAN_INFO_PERSISTENCE). >>>>>>> >>>>>>> >>>>>>> If I understand the behavior correctly it causes that the event needs to be >>>>>>> triggered at least n times before the event is reported by the chip. In my >>>>>>> opinion 'persistence' is not a good term for that. I'm not sure what a >>>>>>> better term is but I think it should go more in the direction of ratelimit >>>>>>> or something. >>>>>> >>>>>> I've seen this term used for many devices: >>>>>> >>>>>> * TSL25911 ambient light sensor [1] >>>>>> >>>>>> [ One set of thresholds can be configured to trigger an interrupt only when >>>>>> the ambient light exceeds them for a configurable amount of time >>>>>> (persistence) >>>>>> ] >>>>>> >>>>>> * TAOS TCS34725 ambient light sensor [2] >>>>>> [ >>>>>> The interrupt persistence filter allows the user to define the number >>>>>> of consecutive >>>>>> out-of-threshold events necessary before generating an interrupt. >>>>>> ] >>>>>> >>>>>> * Avago SAPDS-9950, Sensortek STK3310 >>>>>> >>>>>> I think the TSL25911 datasheet best describes this parameter, as the >>>>>> amount of time >>>>>> that ambient light should exceed a threshold until an interrupt is >>>>>> generated. >>>>> >>>>> Ok, that makes more sense. I misunderstood the initial description as that >>>>> the signal would have to go first above the threshold then below the >>>>> threshold, and this for a number of times. Whereas it needs to exceed the >>>>> threshold for a certain amount of time before the event is triggered. If >>>>> it goes below the threshold before the persistence interval no event is >>>>> triggered and the counter is reset. >>>> >>>> Yes, it needs to cross the threshold n number of times before a event is >>>> generated. >>> >>> Wait. It needs to cross the threshold or it needs to stay above the threshold? >> Following is the logic for this chip. >> >> If ( data > Upper_threshold or data < Lower_threshold) >> generate_event() > > Missed to add <n> times logic > > If ( data > Upper_threshold or data < Lower_threshold) { > increment_count; > if (count >= n) { > generate_event() > reset_count() > } > } > So level rather than edge triggered. Definitely what we put _period in for in the first place. Admittedly persistence might have been a better name, but too late now! (dratted ABI compatibility) J >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-09 10:16 ` Jonathan Cameron @ 2015-04-09 22:35 ` sathyanarayanan kuppuswamy 2015-04-10 5:51 ` Jonathan Cameron 0 siblings, 1 reply; 21+ messages in thread From: sathyanarayanan kuppuswamy @ 2015-04-09 22:35 UTC (permalink / raw) To: Jonathan Cameron, Lars-Peter Clausen, Daniel Baluta Cc: Peter Meerwald, linux-iio, Srinivas Pandruvada Comments inline. On 04/09/2015 03:16 AM, Jonathan Cameron wrote: > On 01/04/15 20:22, sathyanarayanan kuppuswamy wrote: >> >> On 04/01/2015 12:06 PM, sathyanarayanan kuppuswamy wrote: >>> >>> On 04/01/2015 10:48 AM, Lars-Peter Clausen wrote: >>>> On 04/01/2015 07:45 PM, sathyanarayanan kuppuswamy wrote: >>>>> >>>>> On 04/01/2015 08:15 AM, Lars-Peter Clausen wrote: >>>>>> On 04/01/2015 05:02 PM, Daniel Baluta wrote: >>>>>>> On Wed, Apr 1, 2015 at 5:39 PM, Lars-Peter Clausen <lars@metafoo.de> wrote: >>>>>>>> On 04/01/2015 04:04 PM, Daniel Baluta wrote: >>>>>>>> [...] >>>>>>>>> >>>>>>>>>> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >>>>>>>>>> + { >>>>>>>>>> + .name = "intr_persist", >>>>>>>>>> + .read = ltr501_read_intr_prst, >>>>>>>>>> + .write = ltr501_write_intr_prst, >>>>>>>>>> + .shared = IIO_SHARED_BY_TYPE, >>>>>>>>>> + }, >>>>>>>>>> + {}, >>>>>>>>>> +}; >>>>>>>>>> + >>>>>>>>> Would be nice to standardize persistence attribute >>>>>>>>> (IIO_CHAN_INFO_PERSISTENCE). >>>>>>>> >>>>>>>> If I understand the behavior correctly it causes that the event needs to be >>>>>>>> triggered at least n times before the event is reported by the chip. In my >>>>>>>> opinion 'persistence' is not a good term for that. I'm not sure what a >>>>>>>> better term is but I think it should go more in the direction of ratelimit >>>>>>>> or something. >>>>>>> I've seen this term used for many devices: >>>>>>> >>>>>>> * TSL25911 ambient light sensor [1] >>>>>>> >>>>>>> [ One set of thresholds can be configured to trigger an interrupt only when >>>>>>> the ambient light exceeds them for a configurable amount of time >>>>>>> (persistence) >>>>>>> ] >>>>>>> >>>>>>> * TAOS TCS34725 ambient light sensor [2] >>>>>>> [ >>>>>>> The interrupt persistence filter allows the user to define the number >>>>>>> of consecutive >>>>>>> out-of-threshold events necessary before generating an interrupt. >>>>>>> ] >>>>>>> >>>>>>> * Avago SAPDS-9950, Sensortek STK3310 >>>>>>> >>>>>>> I think the TSL25911 datasheet best describes this parameter, as the >>>>>>> amount of time >>>>>>> that ambient light should exceed a threshold until an interrupt is >>>>>>> generated. >>>>>> Ok, that makes more sense. I misunderstood the initial description as that >>>>>> the signal would have to go first above the threshold then below the >>>>>> threshold, and this for a number of times. Whereas it needs to exceed the >>>>>> threshold for a certain amount of time before the event is triggered. If >>>>>> it goes below the threshold before the persistence interval no event is >>>>>> triggered and the counter is reset. >>>>> Yes, it needs to cross the threshold n number of times before a event is >>>>> generated. >>>> Wait. It needs to cross the threshold or it needs to stay above the threshold? >>> Following is the logic for this chip. >>> >>> If ( data > Upper_threshold or data < Lower_threshold) >>> generate_event() >> Missed to add <n> times logic >> >> If ( data > Upper_threshold or data < Lower_threshold) { >> increment_count; >> if (count >= n) { >> generate_event() >> reset_count() >> } >> } >> > So level rather than edge triggered. Definitely what we put _period > in for in the first place. Admittedly persistence might have been a better > name, but too late now! (dratted ABI compatibility) > > J But we cannot use period for this use case. According to _period ABI description, It specifies the period of time for which the condition must be true for getting a valid event. But here, we are checking for number of times a condition must be true for generating a valid event. Description: Period of time (in seconds) for which the condition must be met before an event is generated. If direction is not specified then this period applies to both directions. >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> > -- Sathyanarayanan Kuppuswamy Android kernel developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-09 22:35 ` sathyanarayanan kuppuswamy @ 2015-04-10 5:51 ` Jonathan Cameron 2015-04-22 15:59 ` Lars-Peter Clausen 0 siblings, 1 reply; 21+ messages in thread From: Jonathan Cameron @ 2015-04-10 5:51 UTC (permalink / raw) To: sathyanarayanan.kuppuswamy, Lars-Peter Clausen, Daniel Baluta Cc: Peter Meerwald, linux-iio, Srinivas Pandruvada On 9 April 2015 23:35:03 BST, sathyanarayanan kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: >Comments inline. > >On 04/09/2015 03:16 AM, Jonathan Cameron wrote: >> On 01/04/15 20:22, sathyanarayanan kuppuswamy wrote: >>> >>> On 04/01/2015 12:06 PM, sathyanarayanan kuppuswamy wrote: >>>> >>>> On 04/01/2015 10:48 AM, Lars-Peter Clausen wrote: >>>>> On 04/01/2015 07:45 PM, sathyanarayanan kuppuswamy wrote: >>>>>> >>>>>> On 04/01/2015 08:15 AM, Lars-Peter Clausen wrote: >>>>>>> On 04/01/2015 05:02 PM, Daniel Baluta wrote: >>>>>>>> On Wed, Apr 1, 2015 at 5:39 PM, Lars-Peter Clausen ><lars@metafoo.de> wrote: >>>>>>>>> On 04/01/2015 04:04 PM, Daniel Baluta wrote: >>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>>> +static const struct iio_chan_spec_ext_info >ltr501_ext_info[] = { >>>>>>>>>>> + { >>>>>>>>>>> + .name = "intr_persist", >>>>>>>>>>> + .read = ltr501_read_intr_prst, >>>>>>>>>>> + .write = ltr501_write_intr_prst, >>>>>>>>>>> + .shared = IIO_SHARED_BY_TYPE, >>>>>>>>>>> + }, >>>>>>>>>>> + {}, >>>>>>>>>>> +}; >>>>>>>>>>> + >>>>>>>>>> Would be nice to standardize persistence attribute >>>>>>>>>> (IIO_CHAN_INFO_PERSISTENCE). >>>>>>>>> >>>>>>>>> If I understand the behavior correctly it causes that the >event needs to be >>>>>>>>> triggered at least n times before the event is reported by the >chip. In my >>>>>>>>> opinion 'persistence' is not a good term for that. I'm not >sure what a >>>>>>>>> better term is but I think it should go more in the direction >of ratelimit >>>>>>>>> or something. >>>>>>>> I've seen this term used for many devices: >>>>>>>> >>>>>>>> * TSL25911 ambient light sensor [1] >>>>>>>> >>>>>>>> [ One set of thresholds can be configured to trigger an >interrupt only when >>>>>>>> the ambient light exceeds them for a configurable amount of >time >>>>>>>> (persistence) >>>>>>>> ] >>>>>>>> >>>>>>>> * TAOS TCS34725 ambient light sensor [2] >>>>>>>> [ >>>>>>>> The interrupt persistence filter allows the user to define the >number >>>>>>>> of consecutive >>>>>>>> out-of-threshold events necessary before generating an >interrupt. >>>>>>>> ] >>>>>>>> >>>>>>>> * Avago SAPDS-9950, Sensortek STK3310 >>>>>>>> >>>>>>>> I think the TSL25911 datasheet best describes this parameter, >as the >>>>>>>> amount of time >>>>>>>> that ambient light should exceed a threshold until an interrupt >is >>>>>>>> generated. >>>>>>> Ok, that makes more sense. I misunderstood the initial >description as that >>>>>>> the signal would have to go first above the threshold then below >the >>>>>>> threshold, and this for a number of times. Whereas it needs to >exceed the >>>>>>> threshold for a certain amount of time before the event is >triggered. If >>>>>>> it goes below the threshold before the persistence interval no >event is >>>>>>> triggered and the counter is reset. >>>>>> Yes, it needs to cross the threshold n number of times before a >event is >>>>>> generated. >>>>> Wait. It needs to cross the threshold or it needs to stay above >the threshold? >>>> Following is the logic for this chip. >>>> >>>> If ( data > Upper_threshold or data < Lower_threshold) >>>> generate_event() >>> Missed to add <n> times logic >>> >>> If ( data > Upper_threshold or data < Lower_threshold) { >>> increment_count; >>> if (count >= n) { >>> generate_event() >>> reset_count() >>> } >>> } >>> >> So level rather than edge triggered. Definitely what we put _period >> in for in the first place. Admittedly persistence might have been a >better >> name, but too late now! (dratted ABI compatibility) >> >> J >But we cannot use period for this use case. According to _period ABI >description, >It specifies the period of time for which the condition must be true >for >getting a >valid event. But here, we are checking for number of times a condition >must be >true for generating a valid event. But we are checking that condition at a known sampling rate I assume? Hence period = persistence x 1/sampling frequency? > >Description: > Period of time (in seconds) for which the condition must be > met before an event is generated. If direction is not > specified then this period applies to both directions. > >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe >linux-iio" in >>>>> the body of a message to majordomo@vger.kernel.org >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-10 5:51 ` Jonathan Cameron @ 2015-04-22 15:59 ` Lars-Peter Clausen 2015-04-22 20:58 ` Jonathan Cameron 0 siblings, 1 reply; 21+ messages in thread From: Lars-Peter Clausen @ 2015-04-22 15:59 UTC (permalink / raw) To: Jonathan Cameron, sathyanarayanan.kuppuswamy, Daniel Baluta Cc: Peter Meerwald, linux-iio, Srinivas Pandruvada On 04/10/2015 07:51 AM, Jonathan Cameron wrote: [...] >>> So level rather than edge triggered. Definitely what we put _period >>> in for in the first place. Admittedly persistence might have been a >> better >>> name, but too late now! (dratted ABI compatibility) >>> >>> J >> But we cannot use period for this use case. According to _period ABI >> description, >> It specifies the period of time for which the condition must be true >> for >> getting a >> valid event. But here, we are checking for number of times a condition >> must be >> true for generating a valid event. > But we are checking that condition at a known sampling rate I assume? > Hence > period = persistence x 1/sampling frequency? Sorry for highjacking this thread. So period is for the time interval it has the event has to be asserted before it is registered. What would we call the same thing but for the de-assertion of the event? The event has to be de-asserted for X amount of time before it gets propagated. Thanks, - Lars ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-22 15:59 ` Lars-Peter Clausen @ 2015-04-22 20:58 ` Jonathan Cameron 0 siblings, 0 replies; 21+ messages in thread From: Jonathan Cameron @ 2015-04-22 20:58 UTC (permalink / raw) To: Lars-Peter Clausen, sathyanarayanan.kuppuswamy, Daniel Baluta Cc: Peter Meerwald, linux-iio, Srinivas Pandruvada On 22/04/15 16:59, Lars-Peter Clausen wrote: > On 04/10/2015 07:51 AM, Jonathan Cameron wrote: > [...] >>>> So level rather than edge triggered. Definitely what we put _period >>>> in for in the first place. Admittedly persistence might have been a >>> better >>>> name, but too late now! (dratted ABI compatibility) >>>> >>>> J >>> But we cannot use period for this use case. According to _period ABI >>> description, >>> It specifies the period of time for which the condition must be true >>> for >>> getting a >>> valid event. But here, we are checking for number of times a condition >>> must be >>> true for generating a valid event. >> But we are checking that condition at a known sampling rate I assume? >> Hence >> period = persistence x 1/sampling frequency? > > Sorry for highjacking this thread. > > So period is for the time interval it has the event has to be asserted before it is registered. What would we call the same thing but for the de-assertion of the event? The event has to be de-asserted for X amount of time before it gets propagated. Err, offperiod? resetperiod? space? (on the basis of mark-space description of square waves?) It's kind of temporal hysteresis, or a debounce filter I suppose. Period isn't great for the existing interface. > > Thanks, > - Lars > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 15:15 ` Lars-Peter Clausen 2015-04-01 17:45 ` sathyanarayanan kuppuswamy @ 2015-04-01 20:19 ` Jonathan Cameron 1 sibling, 0 replies; 21+ messages in thread From: Jonathan Cameron @ 2015-04-01 20:19 UTC (permalink / raw) To: Lars-Peter Clausen, Daniel Baluta Cc: Kuppuswamy Sathyanarayanan, Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On 1 April 2015 16:15:33 BST, Lars-Peter Clausen <lars@metafoo.de> wrote: >On 04/01/2015 05:02 PM, Daniel Baluta wrote: >> On Wed, Apr 1, 2015 at 5:39 PM, Lars-Peter Clausen <lars@metafoo.de> >wrote: >>> On 04/01/2015 04:04 PM, Daniel Baluta wrote: >>> [...] >>>> >>>> >>>>> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >>>>> + { >>>>> + .name = "intr_persist", >>>>> + .read = ltr501_read_intr_prst, >>>>> + .write = ltr501_write_intr_prst, >>>>> + .shared = IIO_SHARED_BY_TYPE, >>>>> + }, >>>>> + {}, >>>>> +}; >>>>> + >>>> >>>> Would be nice to standardize persistence attribute >>>> (IIO_CHAN_INFO_PERSISTENCE). >>> >>> >>> If I understand the behavior correctly it causes that the event >needs to be >>> triggered at least n times before the event is reported by the chip. >In my >>> opinion 'persistence' is not a good term for that. I'm not sure what >a >>> better term is but I think it should go more in the direction of >ratelimit >>> or something. >> >> I've seen this term used for many devices: >> >> * TSL25911 ambient light sensor [1] >> >> [ One set of thresholds can be configured to trigger an interrupt >only when >> the ambient light exceeds them for a configurable amount of time >(persistence) >> ] >> >> * TAOS TCS34725 ambient light sensor [2] >> [ >> The interrupt persistence filter allows the user to define the number >> of consecutive >> out-of-threshold events necessary before generating an interrupt. >> ] >> >> * Avago SAPDS-9950, Sensortek STK3310 >> >> I think the TSL25911 datasheet best describes this parameter, as the >> amount of time >> that ambient light should exceed a threshold until an interrupt is >generated. > >Ok, that makes more sense. I misunderstood the initial description as >that >the signal would have to go first above the threshold then below the >threshold, and this for a number of times. Whereas it needs to exceed >the >threshold for a certain amount of time before the event is triggered. >If it >goes below the threshold before the persistence interval no event is >triggered and the counter is reset. See ABI docs for _period. This is indeed very common... -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support 2015-04-01 14:04 ` Daniel Baluta 2015-04-01 14:39 ` Lars-Peter Clausen @ 2015-04-01 17:33 ` sathyanarayanan kuppuswamy 1 sibling, 0 replies; 21+ messages in thread From: sathyanarayanan kuppuswamy @ 2015-04-01 17:33 UTC (permalink / raw) To: Daniel Baluta Cc: Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On 04/01/2015 07:04 AM, Daniel Baluta wrote: > On Wed, Apr 1, 2015 at 5:55 AM, Kuppuswamy Sathyanarayanan > <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: >> Added rate control support for ALS and proximity >> threshold interrupts. >> >> Setting <n> to ALS intr_persist sysfs node would >> generate interrupt whenever ALS data cross either >> upper or lower threshold limits <n> number of times. >> Similarly setting <m> to proximity intr_persist sysfs >> node would genere interrupt whenever proximity data falls >> outside threshold limit <m> number of times. >> > <snip> > >> +static ssize_t ltr501_read_intr_prst(struct iio_dev *indio_dev, >> + uintptr_t private, >> + const struct iio_chan_spec *chan, >> + char *buf) >> +{ >> + struct ltr501_data *data = iio_priv(indio_dev); >> + int ret = -EINVAL; >> + >> + switch (chan->type) { >> + case IIO_INTENSITY: >> + mutex_lock(&data->lock_als); >> + ret = i2c_smbus_read_byte_data(data->client, LTR501_INTR_PRST); >> + mutex_unlock(&data->lock_als); > I am not sure I understand why is the mutex needed here? AFAIK I2C transactions > are serialized. That's mutex is to protect the ALS register updates. I want it serialized so that no data can be read when we are changing the control settings. > > <snip> > >> +static const struct iio_chan_spec_ext_info ltr501_ext_info[] = { >> + { >> + .name = "intr_persist", >> + .read = ltr501_read_intr_prst, >> + .write = ltr501_write_intr_prst, >> + .shared = IIO_SHARED_BY_TYPE, >> + }, >> + {}, >> +}; >> + > Would be nice to standardize persistence attribute (IIO_CHAN_INFO_PERSISTENCE). Agreed. I will work on it. > > thanks, > Daniel. > -- Sathyanarayanan Kuppuswamy Android kernel developer ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH v1 3/3] iio: ltr501: Add ACPI enumeration support 2015-04-01 2:55 [PATCH v1 0/3] Added LTR501 Interrupt support Kuppuswamy Sathyanarayanan 2015-04-01 2:55 ` [PATCH v1 1/3] iio: ltr501: Add interrupt support Kuppuswamy Sathyanarayanan 2015-04-01 2:55 ` [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support Kuppuswamy Sathyanarayanan @ 2015-04-01 2:55 ` Kuppuswamy Sathyanarayanan 2015-04-01 13:02 ` [PATCH v1 0/3] Added LTR501 Interrupt support Daniel Baluta 3 siblings, 0 replies; 21+ messages in thread From: Kuppuswamy Sathyanarayanan @ 2015-04-01 2:55 UTC (permalink / raw) To: jic23, pmeerw; +Cc: linux-iio, srinivas.pandruvada, sathyanarayanan.kuppuswamy Added ACPI enumeration support for LTR501 chip. Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> --- drivers/iio/light/ltr501.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c index e8f5019..fc32036 100644 --- a/drivers/iio/light/ltr501.c +++ b/drivers/iio/light/ltr501.c @@ -16,6 +16,7 @@ #include <linux/i2c.h> #include <linux/err.h> #include <linux/delay.h> +#include <linux/acpi.h> #include <linux/iio/iio.h> #include <linux/iio/events.h> @@ -802,6 +803,12 @@ static int ltr501_resume(struct device *dev) static SIMPLE_DEV_PM_OPS(ltr501_pm_ops, ltr501_suspend, ltr501_resume); +static const struct acpi_device_id ltr_acpi_match[] = { + {"LTER0501", 0}, + { }, +}; +MODULE_DEVICE_TABLE(acpi, ltr_acpi_match); + static const struct i2c_device_id ltr501_id[] = { { "ltr501", 0 }, { } @@ -812,6 +819,7 @@ static struct i2c_driver ltr501_driver = { .driver = { .name = LTR501_DRV_NAME, .pm = <r501_pm_ops, + .acpi_match_table = ACPI_PTR(ltr_acpi_match), .owner = THIS_MODULE, }, .probe = ltr501_probe, -- 1.9.1 ^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH v1 0/3] Added LTR501 Interrupt support 2015-04-01 2:55 [PATCH v1 0/3] Added LTR501 Interrupt support Kuppuswamy Sathyanarayanan ` (2 preceding siblings ...) 2015-04-01 2:55 ` [PATCH v1 3/3] iio: ltr501: Add ACPI enumeration support Kuppuswamy Sathyanarayanan @ 2015-04-01 13:02 ` Daniel Baluta 2015-04-01 17:29 ` sathyanarayanan kuppuswamy 3 siblings, 1 reply; 21+ messages in thread From: Daniel Baluta @ 2015-04-01 13:02 UTC (permalink / raw) To: Kuppuswamy Sathyanarayanan Cc: Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On Wed, Apr 1, 2015 at 5:55 AM, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: > This patchset adds interrupt support for LTR501 chip. Also > added acpi enumaration support. > > Please let me know your review comments. > > v1: > 1. Added support to enable ALS & PS intterupts based > on threshold settings. > 2. Added support to control intrrupt rate. > 3. Added acpi enumeration support. > > Kuppuswamy Sathyanarayanan (3): > iio: ltr501: Add interrupt support > iio: ltr501: Add interrupt rate control support > iio: ltr501: Add ACPI enumeration support > > drivers/iio/light/ltr501.c | 395 ++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 392 insertions(+), 3 deletions(-) Nice :). Keep in mind that there are some pending patches for ltr501 and your code might not apply. I think at least this patch must be applied. http://marc.info/?l=linux-iio&m=142779829617041&w=2 thanks, Daniel. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH v1 0/3] Added LTR501 Interrupt support 2015-04-01 13:02 ` [PATCH v1 0/3] Added LTR501 Interrupt support Daniel Baluta @ 2015-04-01 17:29 ` sathyanarayanan kuppuswamy 0 siblings, 0 replies; 21+ messages in thread From: sathyanarayanan kuppuswamy @ 2015-04-01 17:29 UTC (permalink / raw) To: Daniel Baluta Cc: Jonathan Cameron, Peter Meerwald, linux-iio, Srinivas Pandruvada On 04/01/2015 06:02 AM, Daniel Baluta wrote: > On Wed, Apr 1, 2015 at 5:55 AM, Kuppuswamy Sathyanarayanan > <sathyanarayanan.kuppuswamy@linux.intel.com> wrote: >> This patchset adds interrupt support for LTR501 chip. Also >> added acpi enumaration support. >> >> Please let me know your review comments. >> >> v1: >> 1. Added support to enable ALS & PS intterupts based >> on threshold settings. >> 2. Added support to control intrrupt rate. >> 3. Added acpi enumeration support. >> >> Kuppuswamy Sathyanarayanan (3): >> iio: ltr501: Add interrupt support >> iio: ltr501: Add interrupt rate control support >> iio: ltr501: Add ACPI enumeration support >> >> drivers/iio/light/ltr501.c | 395 ++++++++++++++++++++++++++++++++++++++++++++- >> 1 file changed, 392 insertions(+), 3 deletions(-) > Nice :). Keep in mind that there are some pending patches for ltr501 > and your code > might not apply. > > I think at least this patch must be applied. > > http://marc.info/?l=linux-iio&m=142779829617041&w=2 Do you want me to include this in my patch set. I can rebase my patches on top of this. > > thanks, > Daniel. > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Sathyanarayanan Kuppuswamy Android kernel developer ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2015-04-22 20:58 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-01 2:55 [PATCH v1 0/3] Added LTR501 Interrupt support Kuppuswamy Sathyanarayanan 2015-04-01 2:55 ` [PATCH v1 1/3] iio: ltr501: Add interrupt support Kuppuswamy Sathyanarayanan 2015-04-01 2:55 ` [PATCH v1 2/3] iio: ltr501: Add interrupt rate control support Kuppuswamy Sathyanarayanan 2015-04-01 14:04 ` Daniel Baluta 2015-04-01 14:39 ` Lars-Peter Clausen 2015-04-01 15:02 ` Daniel Baluta 2015-04-01 15:15 ` Lars-Peter Clausen 2015-04-01 17:45 ` sathyanarayanan kuppuswamy 2015-04-01 17:48 ` Lars-Peter Clausen 2015-04-01 19:06 ` sathyanarayanan kuppuswamy 2015-04-01 19:22 ` sathyanarayanan kuppuswamy 2015-04-09 10:16 ` Jonathan Cameron 2015-04-09 22:35 ` sathyanarayanan kuppuswamy 2015-04-10 5:51 ` Jonathan Cameron 2015-04-22 15:59 ` Lars-Peter Clausen 2015-04-22 20:58 ` Jonathan Cameron 2015-04-01 20:19 ` Jonathan Cameron 2015-04-01 17:33 ` sathyanarayanan kuppuswamy 2015-04-01 2:55 ` [PATCH v1 3/3] iio: ltr501: Add ACPI enumeration support Kuppuswamy Sathyanarayanan 2015-04-01 13:02 ` [PATCH v1 0/3] Added LTR501 Interrupt support Daniel Baluta 2015-04-01 17:29 ` sathyanarayanan kuppuswamy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.