linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH 0/1] Add support for TI HDC200x humidity and temperature sensors
       [not found] <71176abd-4997-70f8-8132-137fadda7768@norphonic.com>
@ 2019-11-03 12:19 ` Jonathan Cameron
  2019-11-04 14:06   ` Eugene Zaikonnikov
  2019-11-22 14:50   ` Eugene Zaikonnikov
  0 siblings, 2 replies; 4+ messages in thread
From: Jonathan Cameron @ 2019-11-03 12:19 UTC (permalink / raw)
  To: Eugene Zaikonnikov
  Cc: Hartmut Knaack, Lars-Peter Clausen, development, linux-iio

On Fri, 1 Nov 2019 09:42:54 +0100
Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com> wrote:

> Hello,
> 
> Below is a driver for Texas Instruments HDC 2010 & 2080 family of 
> relative humidity and temperature sensors. Their register map, bus 
> access and acquisition modes differ substantially from the earlier 100x 
> series of devices. Therefore combining it with the existing hdc100x 
> driver was unfeasible.
> 
> (No copy to linux-iio as there is some issue between majordomo and my 
> corporate mail setup, hope this is OK)

It happens. I've cc'd linux-iio for the reply so people should be able
to see it.  If you can get the issue sorted for future versions that
would be great.

More of an issue is that your email system has broken the white space
so I won't be able to apply the patch.  Try to get that fixed. If really
hard to solve, then send the output of git format-patch as an attachment
to an email.  Note though that it will massively reduce the review
you get so it's worth having the fight with corporate IT :)

Various comments inline.

Thanks,

Jonathan

> 
> Signed-off-by: Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com>
> 
> diff -uprN linux-5.3.8/drivers/iio/humidity/hdc200x.c 
> linux-5.3.8_hdc2010/drivers/iio/humidity/hdc200x.c
> --- linux-5.3.8/drivers/iio/humidity/hdc200x.c    1970-01-01 
> 01:00:00.000000000 +0100
> +++ linux-5.3.8_hdc2010/drivers/iio/humidity/hdc200x.c 2019-10-31 

We let a few through in the past, but in general using wild cards
for driver names is extremely likely to go wrong.  In this particular
case the wild card doesn't cover the parts already supported!

Hence, just pick a part and name it after that.
This applies to all prefixes in the code as well.

> 16:25:21.196711976 +0100
> @@ -0,0 +1,375 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * hdc200x.c - Support for the TI HDC200x temperature + humidity sensors
> + *
> + * Copyright (C) 2019 Norphonic AS
> + * Author: Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com>
> + *
> + * Datasheets:
> + * http://www.ti.com/product/HDC2010/datasheet
> + * http://www.ti.com/product/HDC2080/datasheet
> + */
> +
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/i2c.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/sysfs.h>
> +
> +#define HDC200X_REG_TEMP_LOW            0x00
> +#define HDC200X_REG_TEMP_HIGH            0x01
> +#define HDC200X_REG_HUMIDITY_LOW        0x02
> +#define HDC200X_REG_HUMIDITY_HIGH        0x03
> +#define HDC200X_REG_INTERRUPT_DRDY        0x04
> +#define HDC200X_REG_TEMP_MAX            0x05
> +#define HDC200X_REG_HUMIDITY_MAX        0x06
> +#define HDC200X_REG_INTERRUPT_EN        0x07
> +#define HDC200X_REG_TEMP_OFFSET_ADJ        0x08
> +#define HDC200X_REG_HUMIDITY_OFFSET_ADJ        0x09
> +#define HDC200X_REG_TEMP_THR_L            0x0a
> +#define HDC200X_REG_TEMP_THR_H            0x0b
> +#define HDC200X_REG_RH_THR_L            0x0c
> +#define HDC200X_REG_RH_THR_H            0x0d
> +#define HDC200X_REG_RESET_DRDY_INT_CONF        0x0e
> +#define HDC200X_REG_MEASUREMENT_CONF        0x0f
> +
> +#define HDC200X_MEAS_CONF            GENMASK(3, 2)
> +#define HDC200X_MEAS_TRIG            BIT(0)
> +#define HDC200X_HEATER_EN            BIT(3)
> +#define HDC200X_AMM                GENMASK(6, 4)
> +
> +struct hdc200x_data {
> +    struct i2c_client *client;
> +    struct mutex lock;
> +    u8 measurement_config;
> +    u8 interrupt_config;
> +    u8 drdy_config;
> +};
> +
> +/* HDC200X_REG_CONFIG shift and mask values */
> +static const struct {
> +    int shift;
> +    int mask;
> +} hdc200x_resolution_shift[2] = {
> +    { /* IIO_TEMP channel */
> +        .shift = 6,
> +        .mask = 3
> +    },
> +    { /* IIO_HUMIDITYRELATIVE channel */

Use an enum to make these explicit rather than comments.

> +        .shift = 4,
> +        .mask = 3,
> +    },
> +};
> +
> +static IIO_CONST_ATTR(out_current_heater_raw_available,
> +        "0 1");
> +
> +static struct attribute *hdc200x_attributes[] = {
> + &iio_const_attr_out_current_heater_raw_available.dev_attr.attr,
> +    NULL
> +};
> +
> +static const struct attribute_group hdc200x_attribute_group = {
> +    .attrs = hdc200x_attributes,
> +};
> +
> +static const struct iio_chan_spec hdc200x_channels[] = {
> +    {
> +        .type = IIO_TEMP,
> +        .extend_name = "Temperature",
Any use of extend_name changes the ABI and should be done extremely
carefully.  It basically means that generic userspace code cannot
use your driver.

Here I can't see any advantage in doing so at all so drop it.

> +        .datasheet_name = "TEMPERATURE",
> +        .address = HDC200X_REG_TEMP_LOW,
> +        .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +            BIT(IIO_CHAN_INFO_SCALE) |
> +            BIT(IIO_CHAN_INFO_OFFSET),
> +        .scan_type = {
> +            .sign = 'u',
> +            .realbits = 14,
> +            .storagebits = 16,
> +            .endianness = IIO_LE,

You aren't providing the buffered interface which most of this is for.
as such, just specify the bits you are using (storagebits only I think)

> +        },
> +    },
> +    {
> +        .type = IIO_TEMP,
> +        .extend_name = "Temperature_MAX",

Could we use the IIO_CHAN_INFO_PEAK element for this?  Given
the different scale, we'd need to do some work to make it
have the same scale as temp.

> +        .datasheet_name = "TEMPERATUREMAX",
> +        .address = HDC200X_REG_TEMP_MAX,
> +        .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +            BIT(IIO_CHAN_INFO_SCALE) |
> +            BIT(IIO_CHAN_INFO_OFFSET),
> +        .scan_type = {
> +            .sign = 'u',
> +            .realbits = 8,
> +            .storagebits = 8,
> +        },
> +    },
> +    {
> +        .type = IIO_HUMIDITYRELATIVE,
> +        .extend_name = "Humidity",
> +        .datasheet_name = "HUMIDITY",
> +        .address = HDC200X_REG_HUMIDITY_LOW,
> +        .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +            BIT(IIO_CHAN_INFO_SCALE),
> +        .scan_type = {
> +            .sign = 'u',
> +            .realbits = 14,
> +            .storagebits = 16,
> +            .endianness = IIO_LE,
> +        },
> +    },
> +    {
> +        .type = IIO_HUMIDITYRELATIVE,
As above, could we use the peak attribute for this?
> +        .extend_name = "Humidity_MAX",
> +        .datasheet_name = "HUMIDITYMAX",
> +        .address = HDC200X_REG_HUMIDITY_MAX,
> +        .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +            BIT(IIO_CHAN_INFO_SCALE),
> +        .scan_type = {
> +            .sign = 'u',
> +            .realbits = 8,
> +            .storagebits = 8,
> +        },
> +    },
> +    {
> +        .type = IIO_CURRENT,
> +        .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> +        .extend_name = "heater",
This bit of ABI is only documented for the hdc100x parts so far. You will need
to have a similar document to describe the non standard abi for this part.

Documentation/ABI/testing/sysfs-bus-iio-humdity-hdc200x.txt

> +        .output = 1,
> +        .scan_index = -1,
> +    },
> +    IIO_CHAN_SOFT_TIMESTAMP(2),
> +};
> +
> +static int hdc200x_update_measurement_config(struct hdc200x_data *data,
> +                         char mask, char val)
> +{
> +    char tmp = (~mask & data->measurement_config) | val;
> +    int ret;
> +
> +    ret = i2c_smbus_write_byte_data(data->client,
> +                    HDC200X_REG_MEASUREMENT_CONF, tmp);
> +    if (!ret)
> +        data->measurement_config = tmp;
> +
> +    return ret;
> +}
> +
> +static int hdc200x_update_interrupt_config(struct hdc200x_data *data,
> +                       char mask, char val)
> +{
> +    char tmp = (~mask & data->interrupt_config) | val;
> +    int ret;
> +
> +    ret = i2c_smbus_write_byte_data(data->client,
> +                    HDC200X_REG_INTERRUPT_EN, tmp);
> +    if (!ret)
> +        data->interrupt_config = tmp;
> +
> +    return ret;
> +}
> +
> +static int hdc200x_update_drdy_config(struct hdc200x_data *data,
> +                      char mask, char val)
> +{
> +    char tmp = (~mask & data->drdy_config) | val;
> +    int ret;
> +
> +    ret = i2c_smbus_write_byte_data(data->client,
> +                    HDC200X_REG_RESET_DRDY_INT_CONF, tmp);
> +    if (!ret)
> +        data->drdy_config = tmp;
> +
> +    return ret;
> +}
> +
> +static int hdc200x_get_measurement_word(struct hdc200x_data *data,
> +                    struct iio_chan_spec const *chan)

These wrappers add relatively little.  I'd prefer that you just call
the i2c calls directly instead.  Less code and ultimately a tiny
bit easier to review.

> +{
> +    struct i2c_client *client = data->client;
> +    s32 ret;
> +
> +    ret = i2c_smbus_read_word_data(data->client, chan->address);
> +
> +    if (ret < 0) {
> +        dev_err(&client->dev, "Could not read sensor data\n");
> +        return ret;
> +    }
> +
> +    return ret;
> +}
> +
> +static int hdc200x_get_measurement_byte(struct hdc200x_data *data,
> +                    struct iio_chan_spec const *chan)
> +{
> +    struct i2c_client *client = data->client;
> +    s32 ret;
> +
> +    ret = i2c_smbus_read_byte_data(data->client, chan->address);
> +
> +    if (ret < 0) {
> +        dev_err(&client->dev, "Could not read sensor data\n");
> +        return ret;

No need to have this return ret as we can use the one below.

> +    }
> +
> +    return ret;
> +}
> +
> +static int hdc200x_get_heater_status(struct hdc200x_data *data)
> +{
> +    return !!(data->drdy_config & HDC200X_HEATER_EN);
> +}
> +
> +static int hdc200x_read_raw(struct iio_dev *indio_dev,
> +                struct iio_chan_spec const *chan, int *val,
> +                int *val2, long mask)
> +{
> +    struct hdc200x_data *data = iio_priv(indio_dev);
> +
> +    switch (mask) {
> +    case IIO_CHAN_INFO_RAW: {
> +        int ret;
> +
> +        mutex_lock(&data->lock);
> +        if (chan->type == IIO_CURRENT) {
> +            *val = hdc200x_get_heater_status(data);
> +            ret = IIO_VAL_INT;
> +        } else {
> +            ret = iio_device_claim_direct_mode(indio_dev);
> +            if (ret) {
> +                mutex_unlock(&data->lock);
> +                return ret;
> +            }
> +            if (chan->scan_type.storagebits == 16)
> +                ret = hdc200x_get_measurement_word(data, chan);
> +            else
> +                ret = hdc200x_get_measurement_byte(data, chan);
> +            iio_device_release_direct_mode(indio_dev);
> +            if (ret >= 0) {
> +                *val = ret;
> +                ret = IIO_VAL_INT;
> +            }
> +        }
> +        mutex_unlock(&data->lock);
> +        return ret;
> +    }
> +    case IIO_CHAN_INFO_SCALE:
> +        if (chan->scan_type.storagebits == 16)
> +            *val2 = 65536;
> +        else
> +            *val2 = 256;
> +        if (chan->type == IIO_TEMP)
> +            *val = 165000;
> +        else
> +            *val = 100;
> +        return IIO_VAL_FRACTIONAL;
> +    case IIO_CHAN_INFO_OFFSET:
> +        if (chan->scan_type.storagebits == 16) {
> +            *val = -15887;
> +            *val2 = 515151;
> +        } else {
> +            *val = -62;
> +            *val2 = 60606;
> +        }
> +        return IIO_VAL_INT_PLUS_MICRO;
> +    default:
> +        return -EINVAL;
> +    }
> +}
> +
> +static int hdc200x_write_raw(struct iio_dev *indio_dev,
> +                 struct iio_chan_spec const *chan,
> +                 int val, int val2, long mask)
> +{
> +    struct hdc200x_data *data = iio_priv(indio_dev);
> +    int ret = -EINVAL;
> +
> +    switch (mask) {
> +    case IIO_CHAN_INFO_RAW:
> +        if (chan->type != IIO_CURRENT || val2 != 0)
> +            return -EINVAL;
> +
> +        mutex_lock(&data->lock);
> +        ret = hdc200x_update_drdy_config(data, HDC200X_HEATER_EN,
> +                         val ? HDC200X_HEATER_EN : 0);

This a little ugly as it will accept even crazy values as valid
currents.  -42 for example. Should check val == 1 or 0 not anything else


> +        mutex_unlock(&data->lock);
> +        return ret;
> +    default:
> +        return -EINVAL;
> +    }
> +}
> +
> +static const struct iio_info hdc200x_info = {
> +    .read_raw = hdc200x_read_raw,
> +    .write_raw = hdc200x_write_raw,
> +    .attrs = &hdc200x_attribute_group,
> +};
> +
> +static int hdc200x_probe(struct i2c_client *client,
> +             const struct i2c_device_id *id)
> +{
> +    struct iio_dev *indio_dev;
> +    struct hdc200x_data *data;
> +
> +    if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_WORD_DATA |
> +                     I2C_FUNC_SMBUS_BYTE | I2C_FUNC_I2C))
> +        return -EOPNOTSUPP;
> +
> +    indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> +    if (!indio_dev)
> +        return -ENOMEM;
> +
> +    data = iio_priv(indio_dev);
> +    i2c_set_clientdata(client, indio_dev);
> +    data->client = client;
> +    mutex_init(&data->lock);
> +
> +    indio_dev->dev.parent = &client->dev;
> +    indio_dev->name = dev_name(&client->dev);
> +    indio_dev->modes = INDIO_DIRECT_MODE;
> +    indio_dev->info = &hdc200x_info;
> +
> +    indio_dev->channels = hdc200x_channels;
> +    indio_dev->num_channels = ARRAY_SIZE(hdc200x_channels);
> +
> +    /* Enable Automatic Measurement Mode at 5Hz */
> +    hdc200x_update_drdy_config(data, HDC200X_AMM, HDC200X_AMM);
> +
> +    /*
> +     * We enable both temp and humidity measurement.
> +     * However the measurement won't start even in AMM until you trigger it.
> +     */
> +    hdc200x_update_measurement_config(data, HDC200X_MEAS_CONF |
> +                      HDC200X_MEAS_TRIG, HDC200X_MEAS_TRIG);
> +
> +    return devm_iio_device_register(&client->dev, indio_dev);
> +}
> +
> +static const struct i2c_device_id hdc200x_id[] = {
> +    { "hdc200x", 0 },
> +    { "hdc2010", 0 },
> +    { "hdc2080", 0 },
> +    { }
> +};
> +MODULE_DEVICE_TABLE(i2c, hdc200x_id);
> +
> +static const struct of_device_id hdc200x_dt_ids[] = {
> +    { .compatible = "ti,hdc2010" },
> +    { .compatible = "ti,hdc2080" },
> +    { }
> +};
> +MODULE_DEVICE_TABLE(of, hdc200x_dt_ids);
> +
> +static struct i2c_driver hdc200x_driver = {
> +    .driver = {
> +        .name    = "hdc200x",
> +        .of_match_table = of_match_ptr(hdc200x_dt_ids),
> +    },
> +    .probe = hdc200x_probe,
> +    .id_table = hdc200x_id,
> +};
> +module_i2c_driver(hdc200x_driver);
> +
> +MODULE_AUTHOR("Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com>");
> +MODULE_DESCRIPTION("TI HDC200x humidity and temperature sensor driver");
> +MODULE_LICENSE("GPL");
> diff -uprN linux-5.3.8/drivers/iio/humidity/Kconfig 
> linux-5.3.8_hdc2010/drivers/iio/humidity/Kconfig
> --- linux-5.3.8/drivers/iio/humidity/Kconfig    2019-10-29 
> 09:22:48.000000000 +0100
> +++ linux-5.3.8_hdc2010/drivers/iio/humidity/Kconfig    2019-10-31 
> 16:03:18.199037553 +0100
> @@ -38,6 +38,16 @@ config HDC100X
>         To compile this driver as a module, choose M here: the module
>         will be called hdc100x.
> 
> +config HDC200X
> +    tristate "TI HDC200x relative humidity and temperature sensor"
> +    depends on I2C
> +    help
> +      Say yes here to build support for the Texas Instruments
> +      HDC2010 and HDC2080 relative humidity and temperature sensors.
> +
> +      To compile this driver as a module, choose M here: the module
> +      will be called hdc200x.
> +
>   config HID_SENSOR_HUMIDITY
>       tristate "HID Environmental humidity sensor"
>       depends on HID_SENSOR_HUB
> diff -uprN linux-5.3.8/drivers/iio/humidity/Makefile 
> linux-5.3.8_hdc2010/drivers/iio/humidity/Makefile
> --- linux-5.3.8/drivers/iio/humidity/Makefile    2019-10-29 
> 09:22:48.000000000 +0100
> +++ linux-5.3.8_hdc2010/drivers/iio/humidity/Makefile 2019-10-31 
> 16:01:38.210318714 +0100
> @@ -6,6 +6,7 @@
>   obj-$(CONFIG_AM2315) += am2315.o
>   obj-$(CONFIG_DHT11) += dht11.o
>   obj-$(CONFIG_HDC100X) += hdc100x.o
> +obj-$(CONFIG_HDC200X) += hdc200x.o
>   obj-$(CONFIG_HID_SENSOR_HUMIDITY) += hid-sensor-humidity.o
> 
>   hts221-y := hts221_core.o \
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/1] Add support for TI HDC200x humidity and temperature sensors
  2019-11-03 12:19 ` [PATCH 0/1] Add support for TI HDC200x humidity and temperature sensors Jonathan Cameron
@ 2019-11-04 14:06   ` Eugene Zaikonnikov
  2019-11-22 14:50   ` Eugene Zaikonnikov
  1 sibling, 0 replies; 4+ messages in thread
From: Eugene Zaikonnikov @ 2019-11-04 14:06 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Hartmut Knaack, Lars-Peter Clausen, development, linux-iio

On 03.11.2019 13:19, Jonathan Cameron wrote:
>
> Various comments inline. 

Thanks for these. The driver was developed in our internal older branch so has some idiosyncrasies due to that, plus certain beginnings for the chip features that we haven't come around to add full support yet. Will clean up those and re-submit.


--
  Eugene.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/1] Add support for TI HDC200x humidity and temperature sensors
  2019-11-03 12:19 ` [PATCH 0/1] Add support for TI HDC200x humidity and temperature sensors Jonathan Cameron
  2019-11-04 14:06   ` Eugene Zaikonnikov
@ 2019-11-22 14:50   ` Eugene Zaikonnikov
  2019-11-23 14:15     ` Jonathan Cameron
  1 sibling, 1 reply; 4+ messages in thread
From: Eugene Zaikonnikov @ 2019-11-22 14:50 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: Hartmut Knaack, Lars-Peter Clausen, development, linux-iio

Jonathan,

Just got back to fixing most of the issues you pointed out, excepting these:

On 03.11.2019 13:19, Jonathan Cameron wrote:

> +
>> +static const struct iio_chan_spec hdc200x_channels[] = {
>> +    {
>> +        .type = IIO_TEMP,
>> +        .extend_name = "Temperature",
> Any use of extend_name changes the ABI and should be done extremely
> carefully.  It basically means that generic userspace code cannot
> use your driver.
>
> Here I can't see any advantage in doing so at all so drop it.

If I have two temperature channels and provide no extend_name to at least one of them, they fail to register.

>
>> +        },
>> +    },
>> +    {
>> +        .type = IIO_TEMP,
>> +        .extend_name = "Temperature_MAX",
> Could we use the IIO_CHAN_INFO_PEAK element for this?  Given
> the different scale, we'd need to do some work to make it
> have the same scale as temp.

Started looking into this.
Are there any examples or docs of using IIO_CHAN_INFO_PEAK? Couldn't find much in the IIO subtree.
Is it used together with INFO_RAW? And temp&max temp channels have different scales already.

>> +{
>> +    char tmp = (~mask & data->drdy_config) | val;
>> +    int ret;
>> +
>> +    ret = i2c_smbus_write_byte_data(data->client,
>> +                    HDC200X_REG_RESET_DRDY_INT_CONF, tmp);
>> +    if (!ret)
>> +        data->drdy_config = tmp;
>> +
>> +    return ret;
>> +}
>> +
>> +static int hdc200x_get_measurement_word(struct hdc200x_data *data,
>> +                    struct iio_chan_spec const *chan)
> These wrappers add relatively little.  I'd prefer that you just call
> the i2c calls directly instead.  Less code and ultimately a tiny
> bit easier to review.

Removed wrappers that are called once. Leaving the wrapper called in different places, makes intent more clear IMO.

--

  Eugene


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/1] Add support for TI HDC200x humidity and temperature sensors
  2019-11-22 14:50   ` Eugene Zaikonnikov
@ 2019-11-23 14:15     ` Jonathan Cameron
  0 siblings, 0 replies; 4+ messages in thread
From: Jonathan Cameron @ 2019-11-23 14:15 UTC (permalink / raw)
  To: Eugene Zaikonnikov
  Cc: Hartmut Knaack, Lars-Peter Clausen, development, linux-iio

On Fri, 22 Nov 2019 15:50:43 +0100
Eugene Zaikonnikov <eugene.zaikonnikov@norphonic.com> wrote:

> Jonathan,
> 
> Just got back to fixing most of the issues you pointed out, excepting these:
> 
> On 03.11.2019 13:19, Jonathan Cameron wrote:
> 
> > +  
> >> +static const struct iio_chan_spec hdc200x_channels[] = {
> >> +    {
> >> +        .type = IIO_TEMP,
> >> +        .extend_name = "Temperature",  
> > Any use of extend_name changes the ABI and should be done extremely
> > carefully.  It basically means that generic userspace code cannot
> > use your driver.
> >
> > Here I can't see any advantage in doing so at all so drop it.  
> 
> If I have two temperature channels and provide no extend_name to at least one of them, they fail to register.
This only worked on the assumption that you could use PEAK below so only
have one channel for both.

Alternative would be to index them, but that doesn't make much sense here either.

> 
> >  
> >> +        },
> >> +    },
> >> +    {
> >> +        .type = IIO_TEMP,
> >> +        .extend_name = "Temperature_MAX",  
> > Could we use the IIO_CHAN_INFO_PEAK element for this?  Given
> > the different scale, we'd need to do some work to make it
> > have the same scale as temp.  
> 
> Started looking into this.
> Are there any examples or docs of using IIO_CHAN_INFO_PEAK? Couldn't find much in the IIO subtree.
> Is it used together with INFO_RAW? And temp&max temp channels have different scales already.

ah. I missed they had different scale values.  That's unfortunate.
A simple work around for this might be to just multiply the output in the _MAX
case by 256.  That way the two would have the same scale which is assumed if using
the IIO_RAW and IIO_PEAK together.

> 
> >> +{
> >> +    char tmp = (~mask & data->drdy_config) | val;
> >> +    int ret;
> >> +
> >> +    ret = i2c_smbus_write_byte_data(data->client,
> >> +                    HDC200X_REG_RESET_DRDY_INT_CONF, tmp);
> >> +    if (!ret)
> >> +        data->drdy_config = tmp;
> >> +
> >> +    return ret;
> >> +}
> >> +
> >> +static int hdc200x_get_measurement_word(struct hdc200x_data *data,
> >> +                    struct iio_chan_spec const *chan)  
> > These wrappers add relatively little.  I'd prefer that you just call
> > the i2c calls directly instead.  Less code and ultimately a tiny
> > bit easier to review.  
> 
> Removed wrappers that are called once. Leaving the wrapper called in different places, makes intent more clear IMO.
Hmm. It's always a trade off.  Will see what the result looks
like!

Jonathan

> 
> --
> 
>   Eugene
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2019-11-23 14:15 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <71176abd-4997-70f8-8132-137fadda7768@norphonic.com>
2019-11-03 12:19 ` [PATCH 0/1] Add support for TI HDC200x humidity and temperature sensors Jonathan Cameron
2019-11-04 14:06   ` Eugene Zaikonnikov
2019-11-22 14:50   ` Eugene Zaikonnikov
2019-11-23 14:15     ` Jonathan Cameron

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).