Message-ID: <568D3127.5090901@roeck-us.net>
Date:	Wed, 6 Jan 2016 07:22:15 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Mike Looijmans <mike.looijmans@...ic.nl>, lm-sensors@...sensors.org
Cc:	jdelvare@...e.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hwmon: Add LTC2990 sensor driver

Hello Mike,

On 01/06/2016 12:07 AM, Mike Looijmans wrote:
> This adds support for the Linear Technology LTC2990  I2C System Monitor.

s/  / /

> The LTC2990 supports a combination of voltage, current and temperature
> monitoring, but this driver currently only supports reading two currents
> by measuring two differential voltages across series resistors.
>
Plus VCC, plus the internal temperature.

> This is sufficient to support the Topic Miami SOM which uses this chip
> to monitor the currents flowing into the FPGA and the CPU parts.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@...ic.nl>
> ---
>   drivers/hwmon/Kconfig   |  15 +++
>   drivers/hwmon/Makefile  |   1 +
>   drivers/hwmon/ltc2990.c | 273 ++++++++++++++++++++++++++++++++++++++++++++++++

Please also provide Documentation/hwmon/ltc2990.

Also, please read and follow Documentation/hwmon/submitting-patches.

>   3 files changed, 289 insertions(+)
>   create mode 100644 drivers/hwmon/ltc2990.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 80a73bf..b3eef31 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -685,6 +685,21 @@ config SENSORS_LTC2945
>   	  This driver can also be built as a module. If so, the module will
>   	  be called ltc2945.
>
> +config SENSORS_LTC2990
> +	tristate "Linear Technology LTC2990 (current monitoring mode only)"
> +	depends on I2C
> +	select REGMAP_I2C

Using regmap for the driver might be a good idea, but you don't.

> +	default n

Not necessary.

> +	help
> +	  If you say yes here you get support for Linear Technology LTC2990
> +	  I2C System Monitor. The LTC2990 supports a combination of voltage,
> +	  current and temperature monitoring, but this driver currently only
> +	  supports reading two currents by measuring two differential voltages
> +	  across series resistors.
> +
> +	  This driver can also be built as a module. If so, the module will
> +	  be called ltc2990.
> +
>   config SENSORS_LTC4151
>   	tristate "Linear Technology LTC4151"
>   	depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 12a3239..e4bd15b 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -101,6 +101,7 @@ obj-$(CONFIG_SENSORS_LM95234)	+= lm95234.o
>   obj-$(CONFIG_SENSORS_LM95241)	+= lm95241.o
>   obj-$(CONFIG_SENSORS_LM95245)	+= lm95245.o
>   obj-$(CONFIG_SENSORS_LTC2945)	+= ltc2945.o
> +obj-$(CONFIG_SENSORS_LTC2990)	+= ltc2990.o
>   obj-$(CONFIG_SENSORS_LTC4151)	+= ltc4151.o
>   obj-$(CONFIG_SENSORS_LTC4215)	+= ltc4215.o
>   obj-$(CONFIG_SENSORS_LTC4222)	+= ltc4222.o
> diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
> new file mode 100644
> index 0000000..161d995
> --- /dev/null
> +++ b/drivers/hwmon/ltc2990.c
> @@ -0,0 +1,273 @@
> +/*
> + * driver for Linear Technology LTC2990 power monitor

Driver

> + *
> + * Copyright (C) 2014 Topic Embedded Products

2015 ?

> + * Author: Mike Looijmans <mike.looijmans@...ic.nl>
> + *
> + * License: GPLv2
> + *
> + * This driver assumes the chip is wired as a dual current monitor, and
> + * reports the voltage drop across two series resistors.

It also monitors the temperature and VCC.

> + */
> +
> +#include <linux/bug.h>

Is this used anywhere in the driver ?

> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/i2c.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +
> +#define LTC2990_STATUS	0x00
> +#define LTC2990_CONTROL	0x01
> +#define LTC2990_TRIGGER	0x02
> +#define LTC2990_TINT_MSB	0x04
> +#define LTC2990_TINT_LSB	0x05
> +#define LTC2990_V1_MSB	0x06
> +#define LTC2990_V1_LSB	0x07
> +#define LTC2990_V2_MSB	0x08
> +#define LTC2990_V2_LSB	0x09
> +#define LTC2990_V3_MSB	0x0A
> +#define LTC2990_V3_LSB	0x0B
> +#define LTC2990_V4_MSB	0x0C
> +#define LTC2990_V4_LSB	0x0D
> +#define LTC2990_VCC_MSB	0x0E
> +#define LTC2990_VCC_LSB	0x0F
> +
> +#define LTC2990_STATUS_BUSY	BIT(0)
> +#define LTC2990_STATUS_TINT	BIT(1)
> +#define LTC2990_STATUS_V1	BIT(2)
> +#define LTC2990_STATUS_V2	BIT(3)
> +#define LTC2990_STATUS_V3	BIT(4)
> +#define LTC2990_STATUS_V4	BIT(5)
> +#define LTC2990_STATUS_VCC	BIT(6)
> +
> +/* Only define control settings we actually use */
> +#define LTC2990_CONTROL_KELVIN		BIT(7)
> +#define LTC2990_CONTROL_SINGLE		BIT(6)
> +#define LTC2990_CONTROL_MEASURE_ALL	(0x3 << 3)
> +#define LTC2990_CONTROL_MODE_CURRENT	0x06
> +#define LTC2990_CONTROL_MODE_VOLTAGE	0x07
> +
> +struct ltc2990_data {
> +	struct device *hwmon_dev;
> +	struct mutex update_lock;
> +	unsigned long last_updated;
> +	short values[6];

u16 ?

> +	bool valid;
> +	u8 update_counter;

Not used anywhere.

> +};
> +
> +static int ltc2990_write(struct i2c_client *i2c, u8 reg, u8 value)
> +{
> +	return i2c_smbus_write_byte_data(i2c, reg, value);
> +}
> +
> +static int ltc2990_read_byte(struct i2c_client *i2c, u8 reg)
> +{
> +	return i2c_smbus_read_byte_data(i2c, reg);
> +}
> +

Useless shim functions.

> +static int ltc2990_read_word(struct i2c_client *i2c, u8 reg)
> +{
> +	int result = i2c_smbus_read_word_data(i2c, reg);
> +	/* Result is MSB first, but smbus specs say LSB first, so swap the
> +	 * result */

Bad multi-line comment.

> +	return result < 0 ? result : swab16(result);

Please use i2c_smbus_read_word_swapped() and drop the shim function.

> +}
> +
> +static struct ltc2990_data *ltc2990_update_device(struct device *dev)
> +{
> +	struct i2c_client *i2c = to_i2c_client(dev);
> +	struct ltc2990_data *data = i2c_get_clientdata(i2c);
> +	struct ltc2990_data *ret = data;
> +	unsigned int timeout;
> +
> +	mutex_lock(&data->update_lock);
> +
> +	/* Update about 4 times per second max */
> +	if (time_after(jiffies, data->last_updated + HZ / 4) || !data->valid) {
> +		int val;
> +		int i;
> +

Please consider using continuous conversion. This would simplify the code significantly
and reduce read delays.

> +		/* Trigger ADC, any value will do */
> +		val = ltc2990_write(i2c, LTC2990_TRIGGER, 1);
> +		if (unlikely(val < 0)) {
> +			ret = ERR_PTR(val);
> +			goto abort;
> +		}
> +
> +		/* Wait for conversion complete */
> +		timeout = 200;
> +		for (;;) {
> +			usleep_range(2000, 4000);
> +			val = ltc2990_read_byte(i2c, LTC2990_STATUS);
> +			if (unlikely(val < 0)) {
> +				ret = ERR_PTR(val);
> +				goto abort;
> +			}
> +			/* Single-shot mode, wait for conversion to complete */
> +			if ((val & LTC2990_STATUS_BUSY) == 0)

			if (!(...))

> +				break;
> +			if (--timeout == 0) {
> +				ret = ERR_PTR(-ETIMEDOUT);
> +				goto abort;
> +			}
> +		}

Again, please consider using continuous conversion mode.

If this is not feasible for some reason, you might as well just wait for the
minimum conversion time before trying to read for the first time. If so,
please use a fixed timeout by comparing the elapsed time instead of looping
for a maximum number of times. Not even counting the time for executing the
code, the maximum delay is between 400 ms and 800 ms, which is way too high
(chip spec says 167 ms worst case, if three temperature sensors are configured).

> +
> +		/* Read all registers */
> +		for (i = 0; i < ARRAY_SIZE(data->values); ++i) {
> +			val = ltc2990_read_word(i2c, (i<<1) + LTC2990_TINT_MSB);

Missing spaces around <<

> +			if (unlikely(val < 0)) {
> +				dev_dbg(dev,
> +					"Failed to read ADC value: error %d\n",
> +					val);
> +				ret = ERR_PTR(val);
> +				goto abort;
> +			}
> +			data->values[i] = val & 0x7FFF; /* Strip 'new' bit */

The bit is never evaluated, so you might as well store the raw value.

> +		}
> +		data->last_updated = jiffies;
> +		data->valid = 1;

	= true;

> +
> +		/*
> +		 *  Quirk: Second trigger is ignored? After this, the BUSY will
> +		 * still be set to "0" and no conversion performed.
> +		 */
> +		val = ltc2990_write(i2c, LTC2990_TRIGGER, 0);
> +	}
> +abort:
> +	mutex_unlock(&data->update_lock);
> +	return ret;
> +}
> +
> +/* Return the converted value from the given register in uV or mC */
> +static int ltc2990_get_value(struct ltc2990_data *data, u8 index)
> +{
> +	s32 result;
> +	s16 v;
> +
> +	if (index == 0) { /* internal temp, 0.0625 degrees/LSB, 12-bit  */
> +		v = data->values[index] << 3;
> +		result = (s32)v * 1000 >> 7;
> +	} else if (index < 5) { /* Vx-Vy, 19.42uV/LSB, 14-bit */
> +		v = data->values[index] << 2;

Datasheet says that the sign bit is in bit 14, so this drops the sign bit.

> +		result = (s32)v * 1942 / (4 * 100);
> +	} else { /* Vcc, 305.18μV/LSB, 2.5V offset, 14-bit */
> +		v = data->values[index] << 2;
> +		result = (s32)v * 30518 / (4 * 100);
> +		result += 2500000;
> +	}
> +	return result;
> +}
> +
> +static ssize_t ltc2990_show_value(struct device *dev,
> +				  struct device_attribute *da, char *buf)
> +{
> +	struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
> +	struct ltc2990_data *data = ltc2990_update_device(dev);
> +	int value;
> +
> +	if (IS_ERR(data))
> +		return PTR_ERR(data);
> +
> +	value = ltc2990_get_value(data, attr->index);
> +	return snprintf(buf, PAGE_SIZE, "%d\n", value);
> +}
> +
> +static SENSOR_DEVICE_ATTR(temp_int, S_IRUGO, ltc2990_show_value, NULL, 0);
> +static SENSOR_DEVICE_ATTR(v1v2_diff, S_IRUGO, ltc2990_show_value, NULL, 1);
> +static SENSOR_DEVICE_ATTR(v3v4_diff, S_IRUGO, ltc2990_show_value, NULL, 3);
> +static SENSOR_DEVICE_ATTR(vcc, S_IRUGO, ltc2990_show_value, NULL, 5);
> +

Please use standard attribute names (and units) as per Documentation/hwmon/sysfs-interface.

> +static struct attribute *ltc2990_attributes[] = {
> +	&sensor_dev_attr_temp_int.dev_attr.attr,
> +	&sensor_dev_attr_v1v2_diff.dev_attr.attr,
> +	&sensor_dev_attr_v3v4_diff.dev_attr.attr,
> +	&sensor_dev_attr_vcc.dev_attr.attr,
> +	NULL,
> +};
> +
> +static const struct attribute_group ltc2990_group = {
> +	.attrs = ltc2990_attributes,
> +};
> +

Please use the ATTRIBUTE_GROUPS() macro. Also see below.

> +static int ltc2990_i2c_probe(
> +	struct i2c_client *i2c, const struct i2c_device_id *id)

Please split as

static int ltc2990_i2c_probe(struct i2c_client *i2c,
			     const struct i2c_device_id *id)

> +{
> +	int ret;
> +	struct ltc2990_data *ltc2990;
> +
> +	if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
> +		return -ENODEV;
> +
> +	ltc2990 = devm_kzalloc(&i2c->dev,
> +		sizeof(struct ltc2990_data), GFP_KERNEL);

Please align continuation lines with '('.

> +	if (ltc2990 == NULL)
> +		return -ENOMEM;
> +
> +	ret = ltc2990_read_byte(i2c, 0);
> +	if (ret < 0) {
> +		dev_err(&i2c->dev, "Could not read LTC2990 on i2c bus.\n");
> +		return ret;
> +	}

The write below would also return an error if the chip isn't there,
so this additional read does not provide any real value.

> +	ret = ltc2990_write(i2c, LTC2990_CONTROL,
> +		LTC2990_CONTROL_SINGLE | LTC2990_CONTROL_MEASURE_ALL |
> +		LTC2990_CONTROL_MODE_CURRENT);

I'll have to think about this. While it addresses your use case,
it limits the scope of this driver significantly. Looking into the board
specifications, you might as well do it right and determine (and set)
the correct configuration using devicetree data instead of forcing your
use case on everyone.

Sure, you may argue that you don't care, but we will be the ones who will have
to handle error reports that the driver unexpectedly changes the configuration
in other use cases (where, for example, the mode may have been pre-set by
the BIOS or ROMMON).

> +	if (ret < 0) {
> +		dev_err(&i2c->dev, "Error: Failed to set control mode.\n");
> +		return ret;
> +	}
> +
> +	mutex_init(&ltc2990->update_lock);
> +	i2c_set_clientdata(i2c, ltc2990);
> +
> +	/* Register sysfs hooks */
> +	ret = sysfs_create_group(&i2c->dev.kobj, &ltc2990_group);
> +	if (ret)
> +		return ret;
> +
> +	ltc2990->hwmon_dev = hwmon_device_register(&i2c->dev);

Please use devm_hwmon_device_register_with_groups().

> +	if (IS_ERR(ltc2990->hwmon_dev)) {
> +		ret = PTR_ERR(ltc2990->hwmon_dev);
> +		goto out_hwmon_device_register;
> +	}
> +
> +	return 0;
> +
> +out_hwmon_device_register:
> +	sysfs_remove_group(&i2c->dev.kobj, &ltc2990_group);
> +	return ret;
> +}
> +
> +static int ltc2990_i2c_remove(struct i2c_client *i2c)
> +{
> +	struct ltc2990_data *ltc2990 = i2c_get_clientdata(i2c);
> +
> +	hwmon_device_unregister(ltc2990->hwmon_dev);
> +	sysfs_remove_group(&i2c->dev.kobj, &ltc2990_group);
> +	return 0;
> +}
> +
> +static const struct i2c_device_id ltc2990_i2c_id[] = {
> +	{ "ltc2990", 0 },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(i2c, ltc2990_i2c_id);
> +
> +static struct i2c_driver ltc2990_i2c_driver = {
> +	.driver = {
> +		.name = "ltc2990",
> +	},
> +	.probe    = ltc2990_i2c_probe,
> +	.remove   = ltc2990_i2c_remove,
> +	.id_table = ltc2990_i2c_id,
> +};
> +
> +module_i2c_driver(ltc2990_i2c_driver);
> +
> +MODULE_DESCRIPTION("LTC2990 Sensor Driver");
> +MODULE_AUTHOR("Topic Embedded Products");
> +MODULE_LICENSE("GPL v2");
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists