* [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support @ 2016-06-12 5:13 Matt Ranostay [not found] ` <1465708397-19649-1-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Matt Ranostay @ 2016-06-12 5:13 UTC (permalink / raw) To: linux-iio; +Cc: jic23, Matt Ranostay Add support for the humidity and temperature functionally for the SHT31 chipset. In addition add support for using using software triggers. Matt Ranostay (2): devicetree: add Sensirion AG vendor id iio: humidity: sht31: add Sensirion SHT31 support .../devicetree/bindings/i2c/trivial-devices.txt | 1 + .../devicetree/bindings/vendor-prefixes.txt | 1 + drivers/iio/humidity/Kconfig | 11 + drivers/iio/humidity/Makefile | 1 + drivers/iio/humidity/sht31.c | 416 +++++++++++++++++++++ 5 files changed, 430 insertions(+) create mode 100644 drivers/iio/humidity/sht31.c -- 2.7.4 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <1465708397-19649-1-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* [PATCH 1/2] devicetree: add Sensirion AG vendor id 2016-06-12 5:13 [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support Matt Ranostay @ 2016-06-12 5:13 ` Matt Ranostay 2016-06-12 5:13 ` [PATCH 2/2] iio: humidity: sht31: add Sensirion SHT31 support Matt Ranostay 2016-06-13 22:25 ` [PATCH 0/2] " Alison Schofield 2 siblings, 0 replies; 17+ messages in thread From: Matt Ranostay @ 2016-06-12 5:13 UTC (permalink / raw) To: linux-iio-u79uwXL29TY76Z2rM5mHXA Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, Matt Ranostay, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index a7440bcd67ff..70ee5f5c5291 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -225,6 +225,7 @@ sbs Smart Battery System schindler Schindler seagate Seagate Technology PLC semtech Semtech Corporation +sensirion Sensirion AG Switzerland sgx SGX Sensortech sharp Sharp Corporation si-en Si-En Technology Ltd. -- 2.7.4 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 1/2] devicetree: add Sensirion AG vendor id @ 2016-06-12 5:13 ` Matt Ranostay 0 siblings, 0 replies; 17+ messages in thread From: Matt Ranostay @ 2016-06-12 5:13 UTC (permalink / raw) To: linux-iio; +Cc: jic23, Matt Ranostay, Rob Herring, devicetree Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by: Matt Ranostay <mranostay@gmail.com> --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index a7440bcd67ff..70ee5f5c5291 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -225,6 +225,7 @@ sbs Smart Battery System schindler Schindler seagate Seagate Technology PLC semtech Semtech Corporation +sensirion Sensirion AG Switzerland sgx SGX Sensortech sharp Sharp Corporation si-en Si-En Technology Ltd. -- 2.7.4 ^ permalink raw reply related [flat|nested] 17+ messages in thread
[parent not found: <1465708397-19649-2-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH 1/2] devicetree: add Sensirion AG vendor id 2016-06-12 5:13 ` Matt Ranostay @ 2016-06-14 22:06 ` Rob Herring -1 siblings, 0 replies; 17+ messages in thread From: Rob Herring @ 2016-06-14 22:06 UTC (permalink / raw) To: Matt Ranostay Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA On Sat, Jun 11, 2016 at 10:13:16PM -0700, Matt Ranostay wrote: > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 1/2] devicetree: add Sensirion AG vendor id @ 2016-06-14 22:06 ` Rob Herring 0 siblings, 0 replies; 17+ messages in thread From: Rob Herring @ 2016-06-14 22:06 UTC (permalink / raw) To: Matt Ranostay; +Cc: linux-iio, jic23, devicetree On Sat, Jun 11, 2016 at 10:13:16PM -0700, Matt Ranostay wrote: > Cc: Rob Herring <robh+dt@kernel.org> > Cc: devicetree@vger.kernel.org > Signed-off-by: Matt Ranostay <mranostay@gmail.com> > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring <robh@kernel.org> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 2/2] iio: humidity: sht31: add Sensirion SHT31 support 2016-06-12 5:13 [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support Matt Ranostay [not found] ` <1465708397-19649-1-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2016-06-12 5:13 ` Matt Ranostay 2016-06-12 5:35 ` Matt Ranostay 2016-06-13 22:25 ` [PATCH 0/2] " Alison Schofield 2 siblings, 1 reply; 17+ messages in thread From: Matt Ranostay @ 2016-06-12 5:13 UTC (permalink / raw) To: linux-iio; +Cc: jic23, Matt Ranostay Add support for the Sensirion SHT31 humidity + temperature sensor. Signed-off-by: Matt Ranostay <mranostay@gmail.com> --- .../devicetree/bindings/i2c/trivial-devices.txt | 1 + drivers/iio/humidity/Kconfig | 11 + drivers/iio/humidity/Makefile | 1 + drivers/iio/humidity/sht31.c | 416 +++++++++++++++++++++ 4 files changed, 429 insertions(+) create mode 100644 drivers/iio/humidity/sht31.c diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index 539874490492..a651ccd15459 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -78,6 +78,7 @@ ricoh,rs5c372b I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power) +sensirion,sht31 Sensirion SHT31 humidity + temperature sensor sgx,vz89x SGX Sensortech VZ89X Sensors sii,s35390a 2-wire CMOS real-time clock skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig index 738a86d9e4a9..21bff72511a5 100644 --- a/drivers/iio/humidity/Kconfig +++ b/drivers/iio/humidity/Kconfig @@ -45,6 +45,17 @@ config HTU21 This driver can also be built as a module. If so, the module will be called htu21. +config SHT31 + tristate "Sensirion SHT31 humidity and temperature sensor" + depends on I2C + select CRC8 + help + If you say yes here you support for the Sensirion SHT31 humidity and + temperature sensor. + + This driver can also be built as a module. If so, the module will be + called sht31. + config SI7005 tristate "SI7005 relative humidity and temperature sensor" depends on I2C diff --git a/drivers/iio/humidity/Makefile b/drivers/iio/humidity/Makefile index 4a73442fcd9c..a3b7727d47bf 100644 --- a/drivers/iio/humidity/Makefile +++ b/drivers/iio/humidity/Makefile @@ -6,5 +6,6 @@ obj-$(CONFIG_AM2315) += am2315.o obj-$(CONFIG_DHT11) += dht11.o obj-$(CONFIG_HDC100X) += hdc100x.o obj-$(CONFIG_HTU21) += htu21.o +obj-$(CONFIG_SHT31) += sht31.o obj-$(CONFIG_SI7005) += si7005.o obj-$(CONFIG_SI7020) += si7020.o diff --git a/drivers/iio/humidity/sht31.c b/drivers/iio/humidity/sht31.c new file mode 100644 index 000000000000..c1d74dcaf8c6 --- /dev/null +++ b/drivers/iio/humidity/sht31.c @@ -0,0 +1,416 @@ +/* + * sht31.c - Support for the Sensirion SHT31 temperature + humidity sensor + * + * Copyright (C) 2016 Matt Ranostay <mranostay@gmail.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include <linux/crc8.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/init.h> +#include <linux/i2c.h> +#include <linux/iio/iio.h> +#include <linux/iio/sysfs.h> +#include <linux/iio/buffer.h> +#include <linux/iio/trigger.h> +#include <linux/iio/triggered_buffer.h> +#include <linux/iio/trigger_consumer.h> + +#define SHT31_DRV_NAME "sht31" + +#define SHT31_HEATER_CMD_MSB 0x30 +#define SHT31_HEATER_CMD_ENABLE 0x6d +#define SHT31_HEATER_CMD_DISABLE 0x66 + +#define SHT31_MEASUREMENT_CMD_MSB (0x2C << 8) + +#define SHT31_STATUS_CMD 0xF32D +#define SHT31_STATUS_CMD_CHKSUM BIT(0) + +struct sht31_data { + struct iio_dev *indio_dev; + struct i2c_client *client; + struct mutex lock; + + /* config */ + int heater_status; + int it_time; + + u8 crc_table[CRC8_TABLE_SIZE]; + u16 buffer[8]; /* 4 byte data + 2 byte pad + 8 byte */ +}; + +static const struct iio_chan_spec sht31_channels[] = { + { + .type = IIO_TEMP, + .address = 0, + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | + BIT(IIO_CHAN_INFO_SCALE) | + BIT(IIO_CHAN_INFO_OFFSET), + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_INT_TIME), + .scan_index = 0, + .scan_type = { + .sign = 'u', + .realbits = 16, + .storagebits = 16, + }, + }, + { + .type = IIO_HUMIDITYRELATIVE, + .address = 1, + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | + BIT(IIO_CHAN_INFO_SCALE), + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_INT_TIME), + .scan_index = 1, + .scan_type = { + .sign = 'u', + .realbits = 16, + .storagebits = 16, + }, + }, + IIO_CHAN_SOFT_TIMESTAMP(2), + { + .type = IIO_CURRENT, + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), + .extend_name = "heater", + .scan_index = -1, + .output = 1, + }, +}; + +static IIO_CONST_ATTR(integration_time_available, + "0.0025 0.0045 0.0125"); + +static IIO_CONST_ATTR(out_current_heater_raw_available, + "0 1"); + +/* integration time + LSB of I2C command */ +static const int sht31_integration_time[][2] = { + {2500, 0x10}, + {4500, 0x0d}, + {12500, 0x06} +}; + +static const unsigned long sht31_scan_masks[] = {0x3, 0}; + +static struct attribute *sht31_attributes[] = { + &iio_const_attr_integration_time_available.dev_attr.attr, + &iio_const_attr_out_current_heater_raw_available.dev_attr.attr, + NULL +}; + +static struct attribute_group sht31_attribute_group = { + .attrs = sht31_attributes, +}; + +static int sht31_crc8_check(struct sht31_data *data, u8 *vals) +{ + int ret = crc8(data->crc_table, vals, 2, 0xff); + + if (ret != vals[2]) + return -EINVAL; + + return 0; +} + +static int sht31_get_measurement(struct sht31_data *data, u16 *buf) +{ + struct i2c_client *client = data->client; + struct i2c_msg msg[2]; + u16 reg = cpu_to_be16(SHT31_MEASUREMENT_CMD_MSB | + sht31_integration_time[data->it_time][1]); + u8 vals[6]; + int ret, i; + + msg[0].addr = client->addr; + msg[0].flags = client->flags; + msg[0].len = 2; + msg[0].buf = (char *) ® + + msg[1].addr = client->addr; + msg[1].flags = client->flags | I2C_M_RD; + msg[1].len = sizeof(vals); + msg[1].buf = (char *) &vals; + + ret = i2c_transfer(client->adapter, msg, 2); + if (ret != 2) + return -EIO; + + for (i = 0; i < 2; i++) { + ret = sht31_crc8_check(data, (u8 *) &vals[3 * i]); + if (ret) + return -EINVAL; + *buf++ = be16_to_cpu(*((u16 *) &vals[3 * i])); + } + + return 0; +} + +static irqreturn_t sht31_trigger_handler(int irq, void *private) +{ + struct iio_poll_func *pf = private; + struct iio_dev *indio_dev = pf->indio_dev; + struct sht31_data *data = iio_priv(indio_dev); + int ret; + + ret = sht31_get_measurement(data, data->buffer); + if (!ret) + iio_push_to_buffers_with_timestamp(indio_dev, data->buffer, + iio_get_time_ns()); + iio_trigger_notify_done(indio_dev->trig); + + return IRQ_HANDLED; +} + +static int sht31_read_raw(struct iio_dev *indio_dev, + struct iio_chan_spec const *chan, + int *val, int *val2, long mask) +{ + struct sht31_data *data = iio_priv(indio_dev); + int ret = -EINVAL; + u16 buf[2]; + + switch (mask) { + case IIO_CHAN_INFO_INT_TIME: + mutex_lock(&data->lock); + *val = 0; + *val2 = sht31_integration_time[data->it_time][0]; + ret = IIO_VAL_INT_PLUS_MICRO; + mutex_unlock(&data->lock); + break; + case IIO_CHAN_INFO_RAW: + switch (chan->type) { + case IIO_HUMIDITYRELATIVE: + case IIO_TEMP: + if (iio_device_claim_direct_mode(indio_dev)) + return -EBUSY; + + ret = sht31_get_measurement(data, (u16 *) &buf); + if (!ret) { + *val = buf[chan->address]; + ret = IIO_VAL_INT; + } + iio_device_release_direct_mode(indio_dev); + break; + case IIO_CURRENT: + mutex_lock(&data->lock); + *val = data->heater_status; + ret = IIO_VAL_INT; + mutex_unlock(&data->lock); + break; + default: + return -EINVAL; + } + break; + case IIO_CHAN_INFO_SCALE: + switch (chan->type) { + case IIO_HUMIDITYRELATIVE: + *val = 100; + *val2 = 65535; + break; + case IIO_TEMP: + *val = 175000; + *val2 = 65535; + break; + default: + return -EINVAL; + } + ret = IIO_VAL_FRACTIONAL; + break; + case IIO_CHAN_INFO_OFFSET: + *val = 18349; /* 18349.8 */ + *val2 = 800000; + ret = IIO_VAL_INT_PLUS_MICRO; + break; + } + + return ret; +} + +static int sht31_set_it_time(struct sht31_data *data, int val2) +{ + int i; + + for (i = 0; i < ARRAY_SIZE(sht31_integration_time); i++) { + if (sht31_integration_time[i][0] == val2) { + data->it_time = i; + return 0; + } + } + + return -EINVAL; +} + +static int sht31_validate_checksum(struct sht31_data *data) +{ + struct i2c_client *client = data->client; + struct i2c_msg msg[2]; + u16 reg = cpu_to_be16(SHT31_STATUS_CMD); + u8 vals[3]; + int ret; + + msg[0].addr = client->addr; + msg[0].flags = client->flags; + msg[0].len = 2; + msg[0].buf = (char *) ® + + msg[1].addr = client->addr; + msg[1].flags = client->flags | I2C_M_RD; + msg[1].len = sizeof(vals); + msg[1].buf = (char *) &vals; + + ret = i2c_transfer(client->adapter, msg, 2); + if (ret != 2) + return -EIO; + + ret = sht31_crc8_check(data, (u8 *) &vals); + if (ret) + return ret; + + return (vals[1] & SHT31_STATUS_CMD_CHKSUM) ? -EINVAL : 0; +} + +static int sht31_set_heater_status(struct sht31_data *data, int val) +{ + int ret; + + ret = i2c_smbus_write_byte_data(data->client, SHT31_HEATER_CMD_MSB, + val ? SHT31_HEATER_CMD_ENABLE : SHT31_HEATER_CMD_DISABLE); + if (ret < 0) + return ret; + + ret = sht31_validate_checksum(data); + if (!ret) + data->heater_status = !!val; + + return ret; +} + +static int sht31_write_raw(struct iio_dev *indio_dev, + struct iio_chan_spec const *chan, + int val, int val2, long mask) +{ + struct sht31_data *data = iio_priv(indio_dev); + int ret = -EINVAL; + + switch (mask) { + case IIO_CHAN_INFO_INT_TIME: + if (val != 0) + return -EINVAL; + + mutex_lock(&data->lock); + ret = sht31_set_it_time(data, val2); + mutex_unlock(&data->lock); + break; + case IIO_CHAN_INFO_RAW: + if (chan->type != IIO_CURRENT || val2 != 0) + return -EINVAL; + + mutex_lock(&data->lock); + ret = sht31_set_heater_status(data, val); + mutex_unlock(&data->lock); + break; + } + + return ret; +} + +static const struct iio_info sht31_info = { + .driver_module = THIS_MODULE, + .read_raw = sht31_read_raw, + .write_raw = sht31_write_raw, + .attrs = &sht31_attribute_group, +}; + +static int sht31_probe(struct i2c_client *client, + const struct i2c_device_id *id) +{ + struct sht31_data *data; + struct iio_dev *indio_dev; + int ret; + + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data)); + if (!indio_dev) + return -ENOMEM; + data = iio_priv(indio_dev); + + indio_dev->info = &sht31_info; + indio_dev->name = SHT31_DRV_NAME; + indio_dev->channels = sht31_channels; + indio_dev->num_channels = ARRAY_SIZE(sht31_channels); + indio_dev->available_scan_masks = sht31_scan_masks; + indio_dev->modes = INDIO_DIRECT_MODE; + indio_dev->dev.parent = &client->dev; + + i2c_set_clientdata(client, indio_dev); + + data->client = client; + data->indio_dev = indio_dev; + mutex_init(&data->lock); + + /* CRC polynomial x8 + x5 + x4 + 1 */ + crc8_populate_msb(data->crc_table, 0x31); + + ret = iio_triggered_buffer_setup(indio_dev, NULL, + sht31_trigger_handler, NULL); + if (ret) + return ret; + + ret = iio_device_register(indio_dev); + if (ret) + goto error_unreg_buffer; + + return 0; + +error_unreg_buffer: + iio_triggered_buffer_cleanup(indio_dev); + + return ret; +} + +static int sht31_remove(struct i2c_client *client) +{ + struct iio_dev *indio_dev = i2c_get_clientdata(client); + + iio_device_unregister(indio_dev); + iio_triggered_buffer_cleanup(indio_dev); + + return 0; +} + +static const struct of_device_id sht31_dt_ids[] = { + { .compatible = "sensirion,sht31" }, + { } +}; +MODULE_DEVICE_TABLE(of, sht31_dt_ids); + +static const struct i2c_device_id sht31_id[] = { + { "sht31", 0 }, + { } +}; +MODULE_DEVICE_TABLE(i2c, sht31_id); + +static struct i2c_driver sht31_driver = { + .driver = { + .name = SHT31_DRV_NAME, + }, + .probe = sht31_probe, + .remove = sht31_remove, + .id_table = sht31_id, +}; +module_i2c_driver(sht31_driver); + +MODULE_AUTHOR("Matt Ranostay <mranostay@gmail.com>"); +MODULE_DESCRIPTION("Sensirion SHT31 humidity and temperature sensor driver"); +MODULE_LICENSE("GPL"); -- 2.7.4 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 2/2] iio: humidity: sht31: add Sensirion SHT31 support 2016-06-12 5:13 ` [PATCH 2/2] iio: humidity: sht31: add Sensirion SHT31 support Matt Ranostay @ 2016-06-12 5:35 ` Matt Ranostay 0 siblings, 0 replies; 17+ messages in thread From: Matt Ranostay @ 2016-06-12 5:35 UTC (permalink / raw) To: linux-iio; +Cc: Jonathan Cameron, Matt Ranostay On Sat, Jun 11, 2016 at 10:13 PM, Matt Ranostay <mranostay@gmail.com> wrote: > Add support for the Sensirion SHT31 humidity + temperature sensor. > > Signed-off-by: Matt Ranostay <mranostay@gmail.com> > --- > .../devicetree/bindings/i2c/trivial-devices.txt | 1 + > drivers/iio/humidity/Kconfig | 11 + > drivers/iio/humidity/Makefile | 1 + > drivers/iio/humidity/sht31.c | 416 +++++++++++++++++++++ > 4 files changed, 429 insertions(+) > create mode 100644 drivers/iio/humidity/sht31.c > > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > index 539874490492..a651ccd15459 100644 > --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > @@ -78,6 +78,7 @@ ricoh,rs5c372b I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC > ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC > ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC > samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power) > +sensirion,sht31 Sensirion SHT31 humidity + temperature sensor > sgx,vz89x SGX Sensortech VZ89X Sensors > sii,s35390a 2-wire CMOS real-time clock > skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply > diff --git a/drivers/iio/humidity/Kconfig b/drivers/iio/humidity/Kconfig > index 738a86d9e4a9..21bff72511a5 100644 > --- a/drivers/iio/humidity/Kconfig > +++ b/drivers/iio/humidity/Kconfig > @@ -45,6 +45,17 @@ config HTU21 > This driver can also be built as a module. If so, the module will > be called htu21. > > +config SHT31 > + tristate "Sensirion SHT31 humidity and temperature sensor" > + depends on I2C > + select CRC8 > + help > + If you say yes here you support for the Sensirion SHT31 humidity and > + temperature sensor. > + > + This driver can also be built as a module. If so, the module will be > + called sht31. > + > config SI7005 > tristate "SI7005 relative humidity and temperature sensor" > depends on I2C > diff --git a/drivers/iio/humidity/Makefile b/drivers/iio/humidity/Makefile > index 4a73442fcd9c..a3b7727d47bf 100644 > --- a/drivers/iio/humidity/Makefile > +++ b/drivers/iio/humidity/Makefile > @@ -6,5 +6,6 @@ obj-$(CONFIG_AM2315) += am2315.o > obj-$(CONFIG_DHT11) += dht11.o > obj-$(CONFIG_HDC100X) += hdc100x.o > obj-$(CONFIG_HTU21) += htu21.o > +obj-$(CONFIG_SHT31) += sht31.o > obj-$(CONFIG_SI7005) += si7005.o > obj-$(CONFIG_SI7020) += si7020.o > diff --git a/drivers/iio/humidity/sht31.c b/drivers/iio/humidity/sht31.c > new file mode 100644 > index 000000000000..c1d74dcaf8c6 > --- /dev/null > +++ b/drivers/iio/humidity/sht31.c > @@ -0,0 +1,416 @@ > +/* > + * sht31.c - Support for the Sensirion SHT31 temperature + humidity sensor > + * > + * Copyright (C) 2016 Matt Ranostay <mranostay@gmail.com> > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + */ > + > +#include <linux/crc8.h> > +#include <linux/module.h> > +#include <linux/mutex.h> > +#include <linux/init.h> > +#include <linux/i2c.h> > +#include <linux/iio/iio.h> > +#include <linux/iio/sysfs.h> > +#include <linux/iio/buffer.h> > +#include <linux/iio/trigger.h> > +#include <linux/iio/triggered_buffer.h> > +#include <linux/iio/trigger_consumer.h> > + > +#define SHT31_DRV_NAME "sht31" > + > +#define SHT31_HEATER_CMD_MSB 0x30 > +#define SHT31_HEATER_CMD_ENABLE 0x6d > +#define SHT31_HEATER_CMD_DISABLE 0x66 > + > +#define SHT31_MEASUREMENT_CMD_MSB (0x2C << 8) > + > +#define SHT31_STATUS_CMD 0xF32D > +#define SHT31_STATUS_CMD_CHKSUM BIT(0) > + > +struct sht31_data { > + struct iio_dev *indio_dev; > + struct i2c_client *client; > + struct mutex lock; > + > + /* config */ > + int heater_status; > + int it_time; > + > + u8 crc_table[CRC8_TABLE_SIZE]; > + u16 buffer[8]; /* 4 byte data + 2 byte pad + 8 byte */ > +}; > + > +static const struct iio_chan_spec sht31_channels[] = { > + { > + .type = IIO_TEMP, > + .address = 0, > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | > + BIT(IIO_CHAN_INFO_SCALE) | > + BIT(IIO_CHAN_INFO_OFFSET), > + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_INT_TIME), > + .scan_index = 0, > + .scan_type = { > + .sign = 'u', > + .realbits = 16, > + .storagebits = 16, > + }, > + }, > + { > + .type = IIO_HUMIDITYRELATIVE, > + .address = 1, > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | > + BIT(IIO_CHAN_INFO_SCALE), > + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_INT_TIME), > + .scan_index = 1, > + .scan_type = { > + .sign = 'u', > + .realbits = 16, > + .storagebits = 16, > + }, > + }, > + IIO_CHAN_SOFT_TIMESTAMP(2), > + { > + .type = IIO_CURRENT, > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), > + .extend_name = "heater", > + .scan_index = -1, > + .output = 1, > + }, > +}; > + > +static IIO_CONST_ATTR(integration_time_available, > + "0.0025 0.0045 0.0125"); > + > +static IIO_CONST_ATTR(out_current_heater_raw_available, > + "0 1"); > + > +/* integration time + LSB of I2C command */ > +static const int sht31_integration_time[][2] = { > + {2500, 0x10}, > + {4500, 0x0d}, > + {12500, 0x06} > +}; > + > +static const unsigned long sht31_scan_masks[] = {0x3, 0}; > + > +static struct attribute *sht31_attributes[] = { > + &iio_const_attr_integration_time_available.dev_attr.attr, > + &iio_const_attr_out_current_heater_raw_available.dev_attr.attr, > + NULL > +}; > + > +static struct attribute_group sht31_attribute_group = { > + .attrs = sht31_attributes, > +}; > + > +static int sht31_crc8_check(struct sht31_data *data, u8 *vals) > +{ > + int ret = crc8(data->crc_table, vals, 2, 0xff); > + > + if (ret != vals[2]) > + return -EINVAL; > + > + return 0; > +} > + > +static int sht31_get_measurement(struct sht31_data *data, u16 *buf) > +{ > + struct i2c_client *client = data->client; > + struct i2c_msg msg[2]; > + u16 reg = cpu_to_be16(SHT31_MEASUREMENT_CMD_MSB | > + sht31_integration_time[data->it_time][1]); > + u8 vals[6]; > + int ret, i; > + > + msg[0].addr = client->addr; > + msg[0].flags = client->flags; > + msg[0].len = 2; > + msg[0].buf = (char *) ® > + > + msg[1].addr = client->addr; > + msg[1].flags = client->flags | I2C_M_RD; > + msg[1].len = sizeof(vals); > + msg[1].buf = (char *) &vals; > + > + ret = i2c_transfer(client->adapter, msg, 2); > + if (ret != 2) > + return -EIO; > + > + for (i = 0; i < 2; i++) { > + ret = sht31_crc8_check(data, (u8 *) &vals[3 * i]); > + if (ret) > + return -EINVAL; > + *buf++ = be16_to_cpu(*((u16 *) &vals[3 * i])); > + } > + > + return 0; > +} > + > +static irqreturn_t sht31_trigger_handler(int irq, void *private) > +{ > + struct iio_poll_func *pf = private; > + struct iio_dev *indio_dev = pf->indio_dev; > + struct sht31_data *data = iio_priv(indio_dev); > + int ret; > + > + ret = sht31_get_measurement(data, data->buffer); > + if (!ret) > + iio_push_to_buffers_with_timestamp(indio_dev, data->buffer, > + iio_get_time_ns()); > + iio_trigger_notify_done(indio_dev->trig); > + > + return IRQ_HANDLED; > +} > + > +static int sht31_read_raw(struct iio_dev *indio_dev, > + struct iio_chan_spec const *chan, > + int *val, int *val2, long mask) > +{ > + struct sht31_data *data = iio_priv(indio_dev); > + int ret = -EINVAL; > + u16 buf[2]; > + > + switch (mask) { > + case IIO_CHAN_INFO_INT_TIME: > + mutex_lock(&data->lock); > + *val = 0; > + *val2 = sht31_integration_time[data->it_time][0]; > + ret = IIO_VAL_INT_PLUS_MICRO; > + mutex_unlock(&data->lock); > + break; > + case IIO_CHAN_INFO_RAW: > + switch (chan->type) { > + case IIO_HUMIDITYRELATIVE: > + case IIO_TEMP: > + if (iio_device_claim_direct_mode(indio_dev)) > + return -EBUSY; > + > + ret = sht31_get_measurement(data, (u16 *) &buf); > + if (!ret) { > + *val = buf[chan->address]; > + ret = IIO_VAL_INT; > + } > + iio_device_release_direct_mode(indio_dev); > + break; > + case IIO_CURRENT: > + mutex_lock(&data->lock); > + *val = data->heater_status; > + ret = IIO_VAL_INT; > + mutex_unlock(&data->lock); > + break; > + default: > + return -EINVAL; > + } > + break; > + case IIO_CHAN_INFO_SCALE: > + switch (chan->type) { > + case IIO_HUMIDITYRELATIVE: > + *val = 100; > + *val2 = 65535; > + break; > + case IIO_TEMP: > + *val = 175000; > + *val2 = 65535; > + break; > + default: > + return -EINVAL; > + } > + ret = IIO_VAL_FRACTIONAL; > + break; > + case IIO_CHAN_INFO_OFFSET: > + *val = 18349; /* 18349.8 */ > + *val2 = 800000; *doh* doublechecking my maths for the calculation I think it should be the following after all 16851.857142 > + ret = IIO_VAL_INT_PLUS_MICRO; > + break; > + } > + > + return ret; > +} > + > +static int sht31_set_it_time(struct sht31_data *data, int val2) > +{ > + int i; > + > + for (i = 0; i < ARRAY_SIZE(sht31_integration_time); i++) { > + if (sht31_integration_time[i][0] == val2) { > + data->it_time = i; > + return 0; > + } > + } > + > + return -EINVAL; > +} > + > +static int sht31_validate_checksum(struct sht31_data *data) > +{ > + struct i2c_client *client = data->client; > + struct i2c_msg msg[2]; > + u16 reg = cpu_to_be16(SHT31_STATUS_CMD); > + u8 vals[3]; > + int ret; > + > + msg[0].addr = client->addr; > + msg[0].flags = client->flags; > + msg[0].len = 2; > + msg[0].buf = (char *) ® > + > + msg[1].addr = client->addr; > + msg[1].flags = client->flags | I2C_M_RD; > + msg[1].len = sizeof(vals); > + msg[1].buf = (char *) &vals; > + > + ret = i2c_transfer(client->adapter, msg, 2); > + if (ret != 2) > + return -EIO; > + > + ret = sht31_crc8_check(data, (u8 *) &vals); > + if (ret) > + return ret; > + > + return (vals[1] & SHT31_STATUS_CMD_CHKSUM) ? -EINVAL : 0; > +} > + > +static int sht31_set_heater_status(struct sht31_data *data, int val) > +{ > + int ret; > + > + ret = i2c_smbus_write_byte_data(data->client, SHT31_HEATER_CMD_MSB, > + val ? SHT31_HEATER_CMD_ENABLE : SHT31_HEATER_CMD_DISABLE); > + if (ret < 0) > + return ret; > + > + ret = sht31_validate_checksum(data); > + if (!ret) > + data->heater_status = !!val; > + > + return ret; > +} > + > +static int sht31_write_raw(struct iio_dev *indio_dev, > + struct iio_chan_spec const *chan, > + int val, int val2, long mask) > +{ > + struct sht31_data *data = iio_priv(indio_dev); > + int ret = -EINVAL; > + > + switch (mask) { > + case IIO_CHAN_INFO_INT_TIME: > + if (val != 0) > + return -EINVAL; > + > + mutex_lock(&data->lock); > + ret = sht31_set_it_time(data, val2); > + mutex_unlock(&data->lock); > + break; > + case IIO_CHAN_INFO_RAW: > + if (chan->type != IIO_CURRENT || val2 != 0) > + return -EINVAL; > + > + mutex_lock(&data->lock); > + ret = sht31_set_heater_status(data, val); > + mutex_unlock(&data->lock); > + break; > + } > + > + return ret; > +} > + > +static const struct iio_info sht31_info = { > + .driver_module = THIS_MODULE, > + .read_raw = sht31_read_raw, > + .write_raw = sht31_write_raw, > + .attrs = &sht31_attribute_group, > +}; > + > +static int sht31_probe(struct i2c_client *client, > + const struct i2c_device_id *id) > +{ > + struct sht31_data *data; > + struct iio_dev *indio_dev; > + int ret; > + > + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data)); > + if (!indio_dev) > + return -ENOMEM; > + data = iio_priv(indio_dev); > + > + indio_dev->info = &sht31_info; > + indio_dev->name = SHT31_DRV_NAME; > + indio_dev->channels = sht31_channels; > + indio_dev->num_channels = ARRAY_SIZE(sht31_channels); > + indio_dev->available_scan_masks = sht31_scan_masks; > + indio_dev->modes = INDIO_DIRECT_MODE; > + indio_dev->dev.parent = &client->dev; > + > + i2c_set_clientdata(client, indio_dev); > + > + data->client = client; > + data->indio_dev = indio_dev; > + mutex_init(&data->lock); > + > + /* CRC polynomial x8 + x5 + x4 + 1 */ > + crc8_populate_msb(data->crc_table, 0x31); > + > + ret = iio_triggered_buffer_setup(indio_dev, NULL, > + sht31_trigger_handler, NULL); > + if (ret) > + return ret; > + > + ret = iio_device_register(indio_dev); > + if (ret) > + goto error_unreg_buffer; > + > + return 0; > + > +error_unreg_buffer: > + iio_triggered_buffer_cleanup(indio_dev); > + > + return ret; > +} > + > +static int sht31_remove(struct i2c_client *client) > +{ > + struct iio_dev *indio_dev = i2c_get_clientdata(client); > + > + iio_device_unregister(indio_dev); > + iio_triggered_buffer_cleanup(indio_dev); > + > + return 0; > +} > + > +static const struct of_device_id sht31_dt_ids[] = { > + { .compatible = "sensirion,sht31" }, > + { } > +}; > +MODULE_DEVICE_TABLE(of, sht31_dt_ids); > + > +static const struct i2c_device_id sht31_id[] = { > + { "sht31", 0 }, > + { } > +}; > +MODULE_DEVICE_TABLE(i2c, sht31_id); > + > +static struct i2c_driver sht31_driver = { > + .driver = { > + .name = SHT31_DRV_NAME, > + }, > + .probe = sht31_probe, > + .remove = sht31_remove, > + .id_table = sht31_id, > +}; > +module_i2c_driver(sht31_driver); > + > +MODULE_AUTHOR("Matt Ranostay <mranostay@gmail.com>"); > +MODULE_DESCRIPTION("Sensirion SHT31 humidity and temperature sensor driver"); > +MODULE_LICENSE("GPL"); > -- > 2.7.4 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support 2016-06-12 5:13 [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support Matt Ranostay [not found] ` <1465708397-19649-1-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-06-12 5:13 ` [PATCH 2/2] iio: humidity: sht31: add Sensirion SHT31 support Matt Ranostay @ 2016-06-13 22:25 ` Alison Schofield 2016-06-13 23:23 ` Matt Ranostay 2 siblings, 1 reply; 17+ messages in thread From: Alison Schofield @ 2016-06-13 22:25 UTC (permalink / raw) To: Matt Ranostay; +Cc: linux-iio, jic23 On Sat, Jun 11, 2016 at 10:13:15PM -0700, Matt Ranostay wrote: > Add support for the humidity and temperature functionally for the SHT31 > chipset. In addition add support for using using software triggers. Now that I'm hwmon-aware ;) I see this same driver under review in hwmon. Can support exist in 2 places? alisons > > Matt Ranostay (2): > devicetree: add Sensirion AG vendor id > iio: humidity: sht31: add Sensirion SHT31 support > > .../devicetree/bindings/i2c/trivial-devices.txt | 1 + > .../devicetree/bindings/vendor-prefixes.txt | 1 + > drivers/iio/humidity/Kconfig | 11 + > drivers/iio/humidity/Makefile | 1 + > drivers/iio/humidity/sht31.c | 416 +++++++++++++++++++++ > 5 files changed, 430 insertions(+) > create mode 100644 drivers/iio/humidity/sht31.c > > -- > 2.7.4 > > -- > 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] 17+ messages in thread
* Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support 2016-06-13 22:25 ` [PATCH 0/2] " Alison Schofield @ 2016-06-13 23:23 ` Matt Ranostay 2016-06-14 7:44 ` jic23 0 siblings, 1 reply; 17+ messages in thread From: Matt Ranostay @ 2016-06-13 23:23 UTC (permalink / raw) To: Alison Schofield; +Cc: linux-iio, Jonathan Cameron Didn't notice that will till now, and looking at the timestamp I see why :). However this is more for the sw triggered buffer support which hwmon lacks... there is a few examples of this already in the tree. Maybe Jonathan and Peter will have some input on this. On Mon, Jun 13, 2016 at 3:25 PM, Alison Schofield <amsfield22@gmail.com> wrote: > On Sat, Jun 11, 2016 at 10:13:15PM -0700, Matt Ranostay wrote: >> Add support for the humidity and temperature functionally for the SHT31 >> chipset. In addition add support for using using software triggers. > > Now that I'm hwmon-aware ;) I see this same driver under review in hwmon. > Can support exist in 2 places? > > alisons > >> >> Matt Ranostay (2): >> devicetree: add Sensirion AG vendor id >> iio: humidity: sht31: add Sensirion SHT31 support >> >> .../devicetree/bindings/i2c/trivial-devices.txt | 1 + >> .../devicetree/bindings/vendor-prefixes.txt | 1 + >> drivers/iio/humidity/Kconfig | 11 + >> drivers/iio/humidity/Makefile | 1 + >> drivers/iio/humidity/sht31.c | 416 +++++++++++++++++++++ >> 5 files changed, 430 insertions(+) >> create mode 100644 drivers/iio/humidity/sht31.c >> >> -- >> 2.7.4 >> >> -- >> 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] 17+ messages in thread
* Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support 2016-06-13 23:23 ` Matt Ranostay @ 2016-06-14 7:44 ` jic23 2016-06-14 19:01 ` Matt Ranostay 0 siblings, 1 reply; 17+ messages in thread From: jic23 @ 2016-06-14 7:44 UTC (permalink / raw) To: Matt Ranostay; +Cc: Alison Schofield, linux-iio, Jonathan Cameron On 14.06.2016 00:23, Matt Ranostay wrote: > Didn't notice that will till now, and looking at the timestamp I see > why :). > However this is more for the sw triggered buffer support which hwmon > lacks... there is a few examples of this already in the tree. > > Maybe Jonathan and Peter will have some input on this. > Thanks for highlighting this Alison. Not the first time we have had simultaneous driver postings under review for both IIO and HWMON unfortunately. The hwmon guys are fairly flexible iff there is a good reason to want stuff that is in IIO. The original hwmon humidity driver was actually my fault as it slipped in when hwmon was effectively not maintained (Andrew Morton was babysitting). People on their side have always been a bit split on humidity drivers and whether they are within their scope. Anyhow, best bet is to email their list (perhaps reply to the driver thread) to make sure everyone knows this is going on (cc linux-iio as well). Then we can work out how to move forward. Two drivers, one in each place is a non starter for new parts. We have ended up with a few instances, but it's mostly been a case of a driver with much wider scope ending up covering parts that were already in hwmon. Also a very small number of devices have moved across from hwmon to IIO. In this particular case the sensor is reasonably fast so there is at least some argument for IIO support. Note I tend to stay out of these and let the driver author work on convincing Guenter / Jean (they are very reasonable and responsive!) Only thing I'll say is that I'm more than happy to have this in IIO if the hwmon guys don't mind. Jonathan > On Mon, Jun 13, 2016 at 3:25 PM, Alison Schofield > <amsfield22@gmail.com> wrote: >> On Sat, Jun 11, 2016 at 10:13:15PM -0700, Matt Ranostay wrote: >>> Add support for the humidity and temperature functionally for the >>> SHT31 >>> chipset. In addition add support for using using software triggers. >> >> Now that I'm hwmon-aware ;) I see this same driver under review in >> hwmon. >> Can support exist in 2 places? >> >> alisons >> >>> >>> Matt Ranostay (2): >>> devicetree: add Sensirion AG vendor id >>> iio: humidity: sht31: add Sensirion SHT31 support >>> >>> .../devicetree/bindings/i2c/trivial-devices.txt | 1 + >>> .../devicetree/bindings/vendor-prefixes.txt | 1 + >>> drivers/iio/humidity/Kconfig | 11 + >>> drivers/iio/humidity/Makefile | 1 + >>> drivers/iio/humidity/sht31.c | 416 >>> +++++++++++++++++++++ >>> 5 files changed, 430 insertions(+) >>> create mode 100644 drivers/iio/humidity/sht31.c >>> >>> -- >>> 2.7.4 >>> >>> -- >>> 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] 17+ messages in thread
* Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support 2016-06-14 7:44 ` jic23 @ 2016-06-14 19:01 ` Matt Ranostay 2016-06-15 4:18 ` Guenter Roeck 0 siblings, 1 reply; 17+ messages in thread From: Matt Ranostay @ 2016-06-14 19:01 UTC (permalink / raw) To: Jonathan Cameron, Guenter Roeck, linux-hwmon, david.frey Cc: Alison Schofield, linux-iio, Jonathan Cameron Hello Guenter et al, So seems I wrote an iio driver for the SHT31 chipset about the same David Frey had his merged into hwmon tree. So was wondering per Jonathan's comments what your input on this would be. >From what I can see the additional functionality of the hrtimer trigger + rather fast update/integration time that a case could be made because of the triggered buffer. Now there is some functionality missing from my iio driver than exists in the hwmon.. like the thermal and humidity trip points (but that can be handled in a userspace HAL anyway), and the non-clock skewing read/write functionality (this can be easily added). Thanks, Matt On Tue, Jun 14, 2016 at 12:44 AM, <jic23@jic23.retrosnub.co.uk> wrote: > On 14.06.2016 00:23, Matt Ranostay wrote: >> >> Didn't notice that will till now, and looking at the timestamp I see why >> :). >> However this is more for the sw triggered buffer support which hwmon >> lacks... there is a few examples of this already in the tree. >> >> Maybe Jonathan and Peter will have some input on this. >> > Thanks for highlighting this Alison. Not the first time we have had > simultaneous driver postings under review for both IIO and > HWMON unfortunately. > > The hwmon guys are fairly flexible iff there is a good reason to want stuff > that is in IIO. The original hwmon humidity driver was actually my fault > as it slipped in when hwmon was effectively not maintained (Andrew Morton > was > babysitting). People on their side have always been a bit split on humidity > drivers and whether they are within their scope. > > Anyhow, best bet is to email their list (perhaps reply to the driver thread) > to make sure everyone knows this is going on (cc linux-iio as well). > Then we can work out how to move forward. > > Two drivers, one in each place is a non starter for new parts. We have > ended up with a few instances, but it's mostly been a case of a driver > with much wider scope ending up covering parts that were already in hwmon. > Also a very small number of devices have moved across from hwmon to IIO. > > In this particular case the sensor is reasonably fast so there is at > least some argument for IIO support. Note I tend to stay out of these > and let the driver author work on convincing Guenter / Jean > (they are very reasonable and responsive!) Only thing I'll say is that > I'm more than happy to have this in IIO if the hwmon guys don't mind. > > Jonathan > >> On Mon, Jun 13, 2016 at 3:25 PM, Alison Schofield <amsfield22@gmail.com> >> wrote: >>> >>> On Sat, Jun 11, 2016 at 10:13:15PM -0700, Matt Ranostay wrote: >>>> >>>> Add support for the humidity and temperature functionally for the SHT31 >>>> chipset. In addition add support for using using software triggers. >>> >>> >>> Now that I'm hwmon-aware ;) I see this same driver under review in >>> hwmon. >>> Can support exist in 2 places? >>> >>> alisons >>> >>>> >>>> Matt Ranostay (2): >>>> devicetree: add Sensirion AG vendor id >>>> iio: humidity: sht31: add Sensirion SHT31 support >>>> >>>> .../devicetree/bindings/i2c/trivial-devices.txt | 1 + >>>> .../devicetree/bindings/vendor-prefixes.txt | 1 + >>>> drivers/iio/humidity/Kconfig | 11 + >>>> drivers/iio/humidity/Makefile | 1 + >>>> drivers/iio/humidity/sht31.c | 416 >>>> +++++++++++++++++++++ >>>> 5 files changed, 430 insertions(+) >>>> create mode 100644 drivers/iio/humidity/sht31.c >>>> >>>> -- >>>> 2.7.4 >>>> >>>> -- >>>> 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] 17+ messages in thread
* Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support 2016-06-14 19:01 ` Matt Ranostay @ 2016-06-15 4:18 ` Guenter Roeck 0 siblings, 0 replies; 17+ messages in thread From: Guenter Roeck @ 2016-06-15 4:18 UTC (permalink / raw) To: Matt Ranostay, Jonathan Cameron, linux-hwmon, david.frey Cc: Alison Schofield, linux-iio, Jonathan Cameron On 06/14/2016 12:01 PM, Matt Ranostay wrote: > Hello Guenter et al, > > So seems I wrote an iio driver for the SHT31 chipset about the same > David Frey had his merged into hwmon tree. So was wondering per > Jonathan's comments what your input on this would be. > >>From what I can see the additional functionality of the hrtimer > trigger + rather fast update/integration time that a case could be > made because of the triggered buffer. > > Now there is some functionality missing from my iio driver than exists > in the hwmon.. like the thermal and humidity trip points (but that can > be handled in a userspace HAL anyway), and the non-clock skewing > read/write functionality (this can be easily added). > I am quite sure that we had this discussion about this very driver before. One of the key reasons for going with hwmon was limit register support. Guess you claim that is no longer relevant since it can be handled in user space ? If so, I would disagree; it seems to be difficult to generate an alert signal from user space. I don't mind if you folks want drivers for chips like like this (ie chips supporting limits, or in other words typical hardware monitoring chips) in iio, but I would kindly ask to enhance the iio subsystem to support limits. It might be worth mentioning that at least for my part am not split on humidity sensors. They are supported in high end servers and thus used for hardware monitoring. Thanks, Guenter > Thanks, > > Matt > > > > On Tue, Jun 14, 2016 at 12:44 AM, <jic23@jic23.retrosnub.co.uk> wrote: >> On 14.06.2016 00:23, Matt Ranostay wrote: >>> >>> Didn't notice that will till now, and looking at the timestamp I see why >>> :). >>> However this is more for the sw triggered buffer support which hwmon >>> lacks... there is a few examples of this already in the tree. >>> >>> Maybe Jonathan and Peter will have some input on this. >>> >> Thanks for highlighting this Alison. Not the first time we have had >> simultaneous driver postings under review for both IIO and >> HWMON unfortunately. >> >> The hwmon guys are fairly flexible iff there is a good reason to want stuff >> that is in IIO. The original hwmon humidity driver was actually my fault >> as it slipped in when hwmon was effectively not maintained (Andrew Morton >> was >> babysitting). People on their side have always been a bit split on humidity >> drivers and whether they are within their scope. >> >> Anyhow, best bet is to email their list (perhaps reply to the driver thread) >> to make sure everyone knows this is going on (cc linux-iio as well). >> Then we can work out how to move forward. >> >> Two drivers, one in each place is a non starter for new parts. We have >> ended up with a few instances, but it's mostly been a case of a driver >> with much wider scope ending up covering parts that were already in hwmon. >> Also a very small number of devices have moved across from hwmon to IIO. >> >> In this particular case the sensor is reasonably fast so there is at >> least some argument for IIO support. Note I tend to stay out of these >> and let the driver author work on convincing Guenter / Jean >> (they are very reasonable and responsive!) Only thing I'll say is that >> I'm more than happy to have this in IIO if the hwmon guys don't mind. >> >> Jonathan >> >>> On Mon, Jun 13, 2016 at 3:25 PM, Alison Schofield <amsfield22@gmail.com> >>> wrote: >>>> >>>> On Sat, Jun 11, 2016 at 10:13:15PM -0700, Matt Ranostay wrote: >>>>> >>>>> Add support for the humidity and temperature functionally for the SHT31 >>>>> chipset. In addition add support for using using software triggers. >>>> >>>> >>>> Now that I'm hwmon-aware ;) I see this same driver under review in >>>> hwmon. >>>> Can support exist in 2 places? >>>> >>>> alisons >>>> >>>>> >>>>> Matt Ranostay (2): >>>>> devicetree: add Sensirion AG vendor id >>>>> iio: humidity: sht31: add Sensirion SHT31 support >>>>> >>>>> .../devicetree/bindings/i2c/trivial-devices.txt | 1 + >>>>> .../devicetree/bindings/vendor-prefixes.txt | 1 + >>>>> drivers/iio/humidity/Kconfig | 11 + >>>>> drivers/iio/humidity/Makefile | 1 + >>>>> drivers/iio/humidity/sht31.c | 416 >>>>> +++++++++++++++++++++ >>>>> 5 files changed, 430 insertions(+) >>>>> create mode 100644 drivers/iio/humidity/sht31.c >>>>> >>>>> -- >>>>> 2.7.4 >>>>> >>>>> -- >>>>> 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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-hwmon" 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] 17+ messages in thread
* Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support @ 2016-06-15 4:18 ` Guenter Roeck 0 siblings, 0 replies; 17+ messages in thread From: Guenter Roeck @ 2016-06-15 4:18 UTC (permalink / raw) To: Matt Ranostay, Jonathan Cameron, linux-hwmon, david.frey Cc: Alison Schofield, linux-iio, Jonathan Cameron On 06/14/2016 12:01 PM, Matt Ranostay wrote: > Hello Guenter et al, > > So seems I wrote an iio driver for the SHT31 chipset about the same > David Frey had his merged into hwmon tree. So was wondering per > Jonathan's comments what your input on this would be. > >>>From what I can see the additional functionality of the hrtimer > trigger + rather fast update/integration time that a case could be > made because of the triggered buffer. > > Now there is some functionality missing from my iio driver than exists > in the hwmon.. like the thermal and humidity trip points (but that can > be handled in a userspace HAL anyway), and the non-clock skewing > read/write functionality (this can be easily added). > I am quite sure that we had this discussion about this very driver before. One of the key reasons for going with hwmon was limit register support. Guess you claim that is no longer relevant since it can be handled in user space ? If so, I would disagree; it seems to be difficult to generate an alert signal from user space. I don't mind if you folks want drivers for chips like like this (ie chips supporting limits, or in other words typical hardware monitoring chips) in iio, but I would kindly ask to enhance the iio subsystem to support limits. It might be worth mentioning that at least for my part am not split on humidity sensors. They are supported in high end servers and thus used for hardware monitoring. Thanks, Guenter > Thanks, > > Matt > > > > On Tue, Jun 14, 2016 at 12:44 AM, <jic23@jic23.retrosnub.co.uk> wrote: >> On 14.06.2016 00:23, Matt Ranostay wrote: >>> >>> Didn't notice that will till now, and looking at the timestamp I see why >>> :). >>> However this is more for the sw triggered buffer support which hwmon >>> lacks... there is a few examples of this already in the tree. >>> >>> Maybe Jonathan and Peter will have some input on this. >>> >> Thanks for highlighting this Alison. Not the first time we have had >> simultaneous driver postings under review for both IIO and >> HWMON unfortunately. >> >> The hwmon guys are fairly flexible iff there is a good reason to want stuff >> that is in IIO. The original hwmon humidity driver was actually my fault >> as it slipped in when hwmon was effectively not maintained (Andrew Morton >> was >> babysitting). People on their side have always been a bit split on humidity >> drivers and whether they are within their scope. >> >> Anyhow, best bet is to email their list (perhaps reply to the driver thread) >> to make sure everyone knows this is going on (cc linux-iio as well). >> Then we can work out how to move forward. >> >> Two drivers, one in each place is a non starter for new parts. We have >> ended up with a few instances, but it's mostly been a case of a driver >> with much wider scope ending up covering parts that were already in hwmon. >> Also a very small number of devices have moved across from hwmon to IIO. >> >> In this particular case the sensor is reasonably fast so there is at >> least some argument for IIO support. Note I tend to stay out of these >> and let the driver author work on convincing Guenter / Jean >> (they are very reasonable and responsive!) Only thing I'll say is that >> I'm more than happy to have this in IIO if the hwmon guys don't mind. >> >> Jonathan >> >>> On Mon, Jun 13, 2016 at 3:25 PM, Alison Schofield <amsfield22@gmail.com> >>> wrote: >>>> >>>> On Sat, Jun 11, 2016 at 10:13:15PM -0700, Matt Ranostay wrote: >>>>> >>>>> Add support for the humidity and temperature functionally for the SHT31 >>>>> chipset. In addition add support for using using software triggers. >>>> >>>> >>>> Now that I'm hwmon-aware ;) I see this same driver under review in >>>> hwmon. >>>> Can support exist in 2 places? >>>> >>>> alisons >>>> >>>>> >>>>> Matt Ranostay (2): >>>>> devicetree: add Sensirion AG vendor id >>>>> iio: humidity: sht31: add Sensirion SHT31 support >>>>> >>>>> .../devicetree/bindings/i2c/trivial-devices.txt | 1 + >>>>> .../devicetree/bindings/vendor-prefixes.txt | 1 + >>>>> drivers/iio/humidity/Kconfig | 11 + >>>>> drivers/iio/humidity/Makefile | 1 + >>>>> drivers/iio/humidity/sht31.c | 416 >>>>> +++++++++++++++++++++ >>>>> 5 files changed, 430 insertions(+) >>>>> create mode 100644 drivers/iio/humidity/sht31.c >>>>> >>>>> -- >>>>> 2.7.4 >>>>> >>>>> -- >>>>> 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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-hwmon" 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] 17+ messages in thread
* Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support 2016-06-15 4:18 ` Guenter Roeck @ 2016-06-15 16:31 ` Jonathan Cameron -1 siblings, 0 replies; 17+ messages in thread From: Jonathan Cameron @ 2016-06-15 16:31 UTC (permalink / raw) To: Guenter Roeck, Matt Ranostay, linux-hwmon, david.frey Cc: Alison Schofield, linux-iio, Jonathan Cameron On 15 June 2016 05:18:05 BST, Guenter Roeck <linux@roeck-us.net> wrote: >On 06/14/2016 12:01 PM, Matt Ranostay wrote: >> Hello Guenter et al, >> >> So seems I wrote an iio driver for the SHT31 chipset about the same >> David Frey had his merged into hwmon tree. So was wondering per >> Jonathan's comments what your input on this would be. >> >>>From what I can see the additional functionality of the hrtimer >> trigger + rather fast update/integration time that a case could be >> made because of the triggered buffer. >> >> Now there is some functionality missing from my iio driver than >exists >> in the hwmon.. like the thermal and humidity trip points (but that >can >> be handled in a userspace HAL anyway), and the non-clock skewing >> read/write functionality (this can be easily added). >> > >I am quite sure that we had this discussion about this very driver >before. >One of the key reasons for going with hwmon was limit register support. > >Guess you claim that is no longer relevant since it can be handled in >user space ? >If so, I would disagree; it seems to be difficult to generate an alert >signal >from user space. Agreed > >I don't mind if you folks want drivers for chips like like this (ie >chips supporting >limits, or in other words typical hardware monitoring chips) in iio, >but I would >kindly ask to enhance the iio subsystem to support limits. It has done since day one via event chardev. Limitations are : * One per channel per type per direction. (Didn't seem necessary at the time) This obviously matters for hwmon chips. * No in kernel interface yet so not pushed on to iio-hwmon bridge. * Intended for interrupt type limits which do not always correspond to how all devices do it... there are ways around it but only indirectly. All fixable and not actually directly relevant for this part (possibly the inkern interface is...) > >It might be worth mentioning that at least for my part am not split on >humidity >sensors. They are supported in high end servers and thus used for >hardware monitoring. Cool. Didn't know that. Jonathan > >Thanks, >Guenter > >> Thanks, >> >> Matt >> >> >> >> On Tue, Jun 14, 2016 at 12:44 AM, <jic23@jic23.retrosnub.co.uk> >wrote: >>> On 14.06.2016 00:23, Matt Ranostay wrote: >>>> >>>> Didn't notice that will till now, and looking at the timestamp I >see why >>>> :). >>>> However this is more for the sw triggered buffer support which >hwmon >>>> lacks... there is a few examples of this already in the tree. >>>> >>>> Maybe Jonathan and Peter will have some input on this. >>>> >>> Thanks for highlighting this Alison. Not the first time we have had >>> simultaneous driver postings under review for both IIO and >>> HWMON unfortunately. >>> >>> The hwmon guys are fairly flexible iff there is a good reason to >want stuff >>> that is in IIO. The original hwmon humidity driver was actually my >fault >>> as it slipped in when hwmon was effectively not maintained (Andrew >Morton >>> was >>> babysitting). People on their side have always been a bit split on >humidity >>> drivers and whether they are within their scope. >>> >>> Anyhow, best bet is to email their list (perhaps reply to the driver >thread) >>> to make sure everyone knows this is going on (cc linux-iio as well). >>> Then we can work out how to move forward. >>> >>> Two drivers, one in each place is a non starter for new parts. We >have >>> ended up with a few instances, but it's mostly been a case of a >driver >>> with much wider scope ending up covering parts that were already in >hwmon. >>> Also a very small number of devices have moved across from hwmon to >IIO. >>> >>> In this particular case the sensor is reasonably fast so there is at >>> least some argument for IIO support. Note I tend to stay out of >these >>> and let the driver author work on convincing Guenter / Jean >>> (they are very reasonable and responsive!) Only thing I'll say is >that >>> I'm more than happy to have this in IIO if the hwmon guys don't >mind. >>> >>> Jonathan >>> >>>> On Mon, Jun 13, 2016 at 3:25 PM, Alison Schofield ><amsfield22@gmail.com> >>>> wrote: >>>>> >>>>> On Sat, Jun 11, 2016 at 10:13:15PM -0700, Matt Ranostay wrote: >>>>>> >>>>>> Add support for the humidity and temperature functionally for the >SHT31 >>>>>> chipset. In addition add support for using using software >triggers. >>>>> >>>>> >>>>> Now that I'm hwmon-aware ;) I see this same driver under review >in >>>>> hwmon. >>>>> Can support exist in 2 places? >>>>> >>>>> alisons >>>>> >>>>>> >>>>>> Matt Ranostay (2): >>>>>> devicetree: add Sensirion AG vendor id >>>>>> iio: humidity: sht31: add Sensirion SHT31 support >>>>>> >>>>>> .../devicetree/bindings/i2c/trivial-devices.txt | 1 + >>>>>> .../devicetree/bindings/vendor-prefixes.txt | 1 + >>>>>> drivers/iio/humidity/Kconfig | 11 + >>>>>> drivers/iio/humidity/Makefile | 1 + >>>>>> drivers/iio/humidity/sht31.c | 416 >>>>>> +++++++++++++++++++++ >>>>>> 5 files changed, 430 insertions(+) >>>>>> create mode 100644 drivers/iio/humidity/sht31.c >>>>>> >>>>>> -- >>>>>> 2.7.4 >>>>>> >>>>>> -- >>>>>> 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 >> -- >> To unsubscribe from this list: send the line "unsubscribe >linux-hwmon" 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] 17+ messages in thread
* Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support @ 2016-06-15 16:31 ` Jonathan Cameron 0 siblings, 0 replies; 17+ messages in thread From: Jonathan Cameron @ 2016-06-15 16:31 UTC (permalink / raw) To: Guenter Roeck, Matt Ranostay, linux-hwmon, david.frey Cc: Alison Schofield, linux-iio, Jonathan Cameron On 15 June 2016 05:18:05 BST, Guenter Roeck <linux@roeck-us.net> wrote: >On 06/14/2016 12:01 PM, Matt Ranostay wrote: >> Hello Guenter et al, >> >> So seems I wrote an iio driver for the SHT31 chipset about the same >> David Frey had his merged into hwmon tree. So was wondering per >> Jonathan's comments what your input on this would be. >> >>>>From what I can see the additional functionality of the hrtimer >> trigger + rather fast update/integration time that a case could be >> made because of the triggered buffer. >> >> Now there is some functionality missing from my iio driver than >exists >> in the hwmon.. like the thermal and humidity trip points (but that >can >> be handled in a userspace HAL anyway), and the non-clock skewing >> read/write functionality (this can be easily added). >> > >I am quite sure that we had this discussion about this very driver >before. >One of the key reasons for going with hwmon was limit register support. > >Guess you claim that is no longer relevant since it can be handled in >user space ? >If so, I would disagree; it seems to be difficult to generate an alert >signal >from user space. Agreed > >I don't mind if you folks want drivers for chips like like this (ie >chips supporting >limits, or in other words typical hardware monitoring chips) in iio, >but I would >kindly ask to enhance the iio subsystem to support limits. It has done since day one via event chardev. Limitations are : * One per channel per type per direction. (Didn't seem necessary at the time) This obviously matters for hwmon chips. * No in kernel interface yet so not pushed on to iio-hwmon bridge. * Intended for interrupt type limits which do not always correspond to how all devices do it... there are ways around it but only indirectly. All fixable and not actually directly relevant for this part (possibly the inkern interface is...) > >It might be worth mentioning that at least for my part am not split on >humidity >sensors. They are supported in high end servers and thus used for >hardware monitoring. Cool. Didn't know that. Jonathan > >Thanks, >Guenter > >> Thanks, >> >> Matt >> >> >> >> On Tue, Jun 14, 2016 at 12:44 AM, <jic23@jic23.retrosnub.co.uk> >wrote: >>> On 14.06.2016 00:23, Matt Ranostay wrote: >>>> >>>> Didn't notice that will till now, and looking at the timestamp I >see why >>>> :). >>>> However this is more for the sw triggered buffer support which >hwmon >>>> lacks... there is a few examples of this already in the tree. >>>> >>>> Maybe Jonathan and Peter will have some input on this. >>>> >>> Thanks for highlighting this Alison. Not the first time we have had >>> simultaneous driver postings under review for both IIO and >>> HWMON unfortunately. >>> >>> The hwmon guys are fairly flexible iff there is a good reason to >want stuff >>> that is in IIO. The original hwmon humidity driver was actually my >fault >>> as it slipped in when hwmon was effectively not maintained (Andrew >Morton >>> was >>> babysitting). People on their side have always been a bit split on >humidity >>> drivers and whether they are within their scope. >>> >>> Anyhow, best bet is to email their list (perhaps reply to the driver >thread) >>> to make sure everyone knows this is going on (cc linux-iio as well). >>> Then we can work out how to move forward. >>> >>> Two drivers, one in each place is a non starter for new parts. We >have >>> ended up with a few instances, but it's mostly been a case of a >driver >>> with much wider scope ending up covering parts that were already in >hwmon. >>> Also a very small number of devices have moved across from hwmon to >IIO. >>> >>> In this particular case the sensor is reasonably fast so there is at >>> least some argument for IIO support. Note I tend to stay out of >these >>> and let the driver author work on convincing Guenter / Jean >>> (they are very reasonable and responsive!) Only thing I'll say is >that >>> I'm more than happy to have this in IIO if the hwmon guys don't >mind. >>> >>> Jonathan >>> >>>> On Mon, Jun 13, 2016 at 3:25 PM, Alison Schofield ><amsfield22@gmail.com> >>>> wrote: >>>>> >>>>> On Sat, Jun 11, 2016 at 10:13:15PM -0700, Matt Ranostay wrote: >>>>>> >>>>>> Add support for the humidity and temperature functionally for the >SHT31 >>>>>> chipset. In addition add support for using using software >triggers. >>>>> >>>>> >>>>> Now that I'm hwmon-aware ;) I see this same driver under review >in >>>>> hwmon. >>>>> Can support exist in 2 places? >>>>> >>>>> alisons >>>>> >>>>>> >>>>>> Matt Ranostay (2): >>>>>> devicetree: add Sensirion AG vendor id >>>>>> iio: humidity: sht31: add Sensirion SHT31 support >>>>>> >>>>>> .../devicetree/bindings/i2c/trivial-devices.txt | 1 + >>>>>> .../devicetree/bindings/vendor-prefixes.txt | 1 + >>>>>> drivers/iio/humidity/Kconfig | 11 + >>>>>> drivers/iio/humidity/Makefile | 1 + >>>>>> drivers/iio/humidity/sht31.c | 416 >>>>>> +++++++++++++++++++++ >>>>>> 5 files changed, 430 insertions(+) >>>>>> create mode 100644 drivers/iio/humidity/sht31.c >>>>>> >>>>>> -- >>>>>> 2.7.4 >>>>>> >>>>>> -- >>>>>> 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 >> -- >> To unsubscribe from this list: send the line "unsubscribe >linux-hwmon" 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] 17+ messages in thread
* Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support 2016-06-15 16:31 ` Jonathan Cameron (?) @ 2016-06-15 18:48 ` Guenter Roeck 2016-06-15 19:34 ` Jonathan Cameron -1 siblings, 1 reply; 17+ messages in thread From: Guenter Roeck @ 2016-06-15 18:48 UTC (permalink / raw) To: Jonathan Cameron Cc: Matt Ranostay, linux-hwmon, david.frey, Alison Schofield, linux-iio, Jonathan Cameron On Wed, Jun 15, 2016 at 05:31:10PM +0100, Jonathan Cameron wrote: > > > On 15 June 2016 05:18:05 BST, Guenter Roeck <linux@roeck-us.net> wrote: > >On 06/14/2016 12:01 PM, Matt Ranostay wrote: > >> Hello Guenter et al, > >> > >> So seems I wrote an iio driver for the SHT31 chipset about the same > >> David Frey had his merged into hwmon tree. So was wondering per > >> Jonathan's comments what your input on this would be. > >> > >>>From what I can see the additional functionality of the hrtimer > >> trigger + rather fast update/integration time that a case could be > >> made because of the triggered buffer. > >> > >> Now there is some functionality missing from my iio driver than > >exists > >> in the hwmon.. like the thermal and humidity trip points (but that > >can > >> be handled in a userspace HAL anyway), and the non-clock skewing > >> read/write functionality (this can be easily added). > >> > > > >I am quite sure that we had this discussion about this very driver > >before. > >One of the key reasons for going with hwmon was limit register support. > > > >Guess you claim that is no longer relevant since it can be handled in > >user space ? > >If so, I would disagree; it seems to be difficult to generate an alert > >signal > >from user space. > Agreed > > > >I don't mind if you folks want drivers for chips like like this (ie > >chips supporting > >limits, or in other words typical hardware monitoring chips) in iio, > >but I would > >kindly ask to enhance the iio subsystem to support limits. > > It has done since day one via event chardev. Limitations are : > * One per channel per type per direction. (Didn't seem necessary at the time) > This obviously matters for hwmon chips. > * No in kernel interface yet so not pushed on to iio-hwmon bridge. > * Intended for interrupt type limits which do not always correspond to how all > devices do it... there are ways around it but only indirectly. > > All fixable and not actually directly relevant for this part (possibly the inkern > interface is...) Sure, all is fixable. Not that it will help here. If you plan to accept this driver, please let me and David know, and I'll drop the hwmon driver. It means we'll both have wasted our time, but it does not make sense to keep two drivers for this chip around. On another side note, I don't really believe that it makes much sense to add all this functionality to iio to start with. I'd rather fix the hwmon registration API and create a hwmon->iio bridge. Guenter ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support 2016-06-15 18:48 ` Guenter Roeck @ 2016-06-15 19:34 ` Jonathan Cameron 0 siblings, 0 replies; 17+ messages in thread From: Jonathan Cameron @ 2016-06-15 19:34 UTC (permalink / raw) To: Guenter Roeck Cc: Matt Ranostay, linux-hwmon, david.frey, Alison Schofield, linux-iio, Jonathan Cameron On 15 June 2016 19:48:55 BST, Guenter Roeck <linux@roeck-us.net> wrote: >On Wed, Jun 15, 2016 at 05:31:10PM +0100, Jonathan Cameron wrote: >> >> >> On 15 June 2016 05:18:05 BST, Guenter Roeck <linux@roeck-us.net> >wrote: >> >On 06/14/2016 12:01 PM, Matt Ranostay wrote: >> >> Hello Guenter et al, >> >> >> >> So seems I wrote an iio driver for the SHT31 chipset about the >same >> >> David Frey had his merged into hwmon tree. So was wondering per >> >> Jonathan's comments what your input on this would be. >> >> >> >>>From what I can see the additional functionality of the hrtimer >> >> trigger + rather fast update/integration time that a case could be >> >> made because of the triggered buffer. >> >> >> >> Now there is some functionality missing from my iio driver than >> >exists >> >> in the hwmon.. like the thermal and humidity trip points (but that >> >can >> >> be handled in a userspace HAL anyway), and the non-clock skewing >> >> read/write functionality (this can be easily added). >> >> >> > >> >I am quite sure that we had this discussion about this very driver >> >before. >> >One of the key reasons for going with hwmon was limit register >support. >> > >> >Guess you claim that is no longer relevant since it can be handled >in >> >user space ? >> >If so, I would disagree; it seems to be difficult to generate an >alert >> >signal >> >from user space. >> Agreed >> > >> >I don't mind if you folks want drivers for chips like like this (ie >> >chips supporting >> >limits, or in other words typical hardware monitoring chips) in iio, >> >but I would >> >kindly ask to enhance the iio subsystem to support limits. >> >> It has done since day one via event chardev. Limitations are : >> * One per channel per type per direction. (Didn't seem necessary at >the time) >> This obviously matters for hwmon chips. >> * No in kernel interface yet so not pushed on to iio-hwmon bridge. >> * Intended for interrupt type limits which do not always correspond >to how all >> devices do it... there are ways around it but only indirectly. >> >> All fixable and not actually directly relevant for this part >(possibly the inkern >> interface is...) > >Sure, all is fixable. Not that it will help here. Quite. > >If you plan to accept this driver, please let me and David know, and >I'll drop >the hwmon driver. It means we'll both have wasted our time, but it does >not make >sense to keep two drivers for this chip around. I don't plan to accept it. The argument in favour has not been strong enough for likely uses if this part. Humidity doesn't typically change that fast. Would need a really strong usecase argument to persuade me... (if anyone has one, now is the time to raise it!) If the drivers had turned up in the other order I would been fine with it in IIO. Sadly it happens sometimes and this time Matt loses! Sorry Matt. However, whilst it is a bit tedious for everyone, I think we do keep needing to debate the suitable home for border line drivers. I don't think there really are any clear rules we can formulate unfortunately. > >On another side note, I don't really believe that it makes much senses >to add all >this functionality to iio to start with. I'd rather fix the hwmon >registration >API and create a hwmon->iio bridge. A worthy aim but I think you would either end up with some nasty name of attr based hackery or a substantial part of the IIO stuff reimplemented. I wish I had more time to drive the plan to fully separate the front end and back end of IIO to provide that sort of 'minimal' hardware description interface. Annoyingly we aren't actually that far away from it. I am also unclear that there is that much point in doing hwmon to IIO bridge in kernel space. Any general ADC driver that would have uses outside hwmon that demand streaming data and similar wouldn't work over such an interface anyway. Anything else is polled via sysfs in both cases, a bit of name look up code and both can be supported by one library. So for devices where the main usecase is probably relatively slow polled reading, I personally don't feel it really matters whether then end up in IIO of hwmon. Just comes down to how they work with legacy interfaces (which is pretty much all the iio-hwmon bridge is for). Right now the unclear corners are 'unusual temperature sensors' e.g. thermophiles, near infrared or high end theromcouple devices where typically high speed drives them to IIO. (they change fast because they are moving around quickly). Humidity partly because a lot of the users are not coming from hardware monitoring but rather environmental side of things. General purpose ADCs - more historical I think where hwmon was kind of the only option... + obviously there are specific hardware monitoring focused parts where hwmon makes sense as it has the interfaces tailored to these applications. Anyhow, that's my 2 pence ;) I suspect we'll keep muddling through but I absolutely agree that we should avoid two drivers for the same part. Maybe I should add a note in the relevant Kconfig files to say if you are putting something here you'd better have a good reason. Not sure anyone would notice though... Jonathan > >Guenter >-- >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] 17+ messages in thread
end of thread, other threads:[~2016-06-15 19:34 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-12 5:13 [PATCH 0/2] iio: humidity: sht31: add Sensirion SHT31 support Matt Ranostay [not found] ` <1465708397-19649-1-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-06-12 5:13 ` [PATCH 1/2] devicetree: add Sensirion AG vendor id Matt Ranostay 2016-06-12 5:13 ` Matt Ranostay [not found] ` <1465708397-19649-2-git-send-email-mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-06-14 22:06 ` Rob Herring 2016-06-14 22:06 ` Rob Herring 2016-06-12 5:13 ` [PATCH 2/2] iio: humidity: sht31: add Sensirion SHT31 support Matt Ranostay 2016-06-12 5:35 ` Matt Ranostay 2016-06-13 22:25 ` [PATCH 0/2] " Alison Schofield 2016-06-13 23:23 ` Matt Ranostay 2016-06-14 7:44 ` jic23 2016-06-14 19:01 ` Matt Ranostay 2016-06-15 4:18 ` Guenter Roeck 2016-06-15 4:18 ` Guenter Roeck 2016-06-15 16:31 ` Jonathan Cameron 2016-06-15 16:31 ` Jonathan Cameron 2016-06-15 18:48 ` Guenter Roeck 2016-06-15 19:34 ` Jonathan Cameron
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.