Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1524603 > unrolled thread

Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes

Started byGuenter Roeck <linux@roeck-us.net>
First post2016-11-17 18:50 +0100
Last post2016-11-18 15:20 +0100
Articles 7 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes Guenter Roeck <linux@roeck-us.net> - 2016-11-17 18:50 +0100
    Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes Mike Looijmans <mike.looijmans@topic.nl> - 2016-11-17 19:50 +0100
      Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes Guenter Roeck <linux@roeck-us.net> - 2016-11-17 20:00 +0100
        Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes Mike Looijmans <mike.looijmans@topic.nl> - 2016-11-17 21:30 +0100
          Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes Guenter Roeck <linux@roeck-us.net> - 2016-11-17 23:00 +0100
            Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes Guenter Roeck <linux@roeck-us.net> - 2016-11-18 00:50 +0100
              Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes Guenter Roeck <linux@roeck-us.net> - 2016-11-18 15:20 +0100

#1524603 — Re: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes

FromGuenter Roeck <linux@roeck-us.net>
Date2016-11-17 18:50 +0100
SubjectRe: [PATCH v2 3/3] hwmon: ltc2990: support all measurement modes
Message-ID<sEyYV-3Mb-19@gated-at.bofh.it>
On 11/17/2016 04:10 AM, Tom Levens wrote:
> Updated version of the ltc2990 driver which supports all measurement
> modes available in the chip. The mode can be set through a devicetree
> attribute.

property

>
> Signed-off-by: Tom Levens <tom.levens@cern.ch>
> ---
>
> Changes since v1:
>   * Refactored value conversion (patch 1/3)
>   * Split the devicetree binding into separate patch (patch 2/3)
>   * Specifying an invalid mode now returns -EINVAL, previously this
>     only issued a warning and used the default value
>   * Removed the "mode" sysfs attribute, as the mode of the chip is
>     hardware specific and should not be user configurable. This allows much
>     simpler code as a result.
>
>  Documentation/hwmon/ltc2990 |   24 ++++---
>  drivers/hwmon/Kconfig       |    7 +--
>  drivers/hwmon/ltc2990.c     |  167 ++++++++++++++++++++++++++++++++++++-------
>  3 files changed, 159 insertions(+), 39 deletions(-)
>
> diff --git a/Documentation/hwmon/ltc2990 b/Documentation/hwmon/ltc2990
> index c25211e..3ed68f6 100644
> --- a/Documentation/hwmon/ltc2990
> +++ b/Documentation/hwmon/ltc2990
> @@ -8,6 +8,7 @@ Supported chips:
>      Datasheet: http://www.linear.com/product/ltc2990
>
>  Author: Mike Looijmans <mike.looijmans@topic.nl>
> +        Tom Levens <tom.levens@cern.ch>
>
>
>  Description
> @@ -16,10 +17,8 @@ Description
>  LTC2990 is a Quad I2C Voltage, Current and Temperature Monitor.
>  The chip's inputs can measure 4 voltages, or two inputs together (1+2 and 3+4)
>  can be combined to measure a differential voltage, which is typically used to
> -measure current through a series resistor, or a temperature.
> -
> -This driver currently uses the 2x differential mode only. In order to support
> -other modes, the driver will need to be expanded.
> +measure current through a series resistor, or a temperature with an external
> +diode.
>
>
>  Usage Notes
> @@ -32,12 +31,19 @@ devices explicitly.
>  Sysfs attributes
>  ----------------
>
> +in0_input     Voltage at Vcc pin in millivolt (range 2.5V to 5V)
> +temp1_input   Internal chip temperature in millidegrees Celcius
> +
> +A subset of the following attributes are visible, depending on the measurement
> +mode of the chip.
> +
> +in[1-4]_input Voltage at V[1-4] pin in millivolt
> +temp2_input   External temperature sensor TR1 in millidegrees Celcius
> +temp3_input   External temperature sensor TR2 in millidegrees Celcius
> +curr1_input   Current in mA across V1-V2 assuming a 1mOhm sense resistor
> +curr2_input   Current in mA across V3-V4 assuming a 1mOhm sense resistor
> +
>  The "curr*_input" measurements actually report the voltage drop across the
>  input pins in microvolts. This is equivalent to the current through a 1mOhm
>  sense resistor. Divide the reported value by the actual sense resistor value
>  in mOhm to get the actual value.
> -
> -in0_input     Voltage at Vcc pin in millivolt (range 2.5V to 5V)
> -temp1_input   Internal chip temperature in millidegrees Celcius
> -curr1_input   Current in mA across v1-v2 assuming a 1mOhm sense resistor.
> -curr2_input   Current in mA across v3-v4 assuming a 1mOhm sense resistor.
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 45cef3d..f7096ca 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -699,15 +699,12 @@ config SENSORS_LTC2945
>  	  be called ltc2945.
>
>  config SENSORS_LTC2990
> -	tristate "Linear Technology LTC2990 (current monitoring mode only)"
> +	tristate "Linear Technology LTC2990"
>  	depends on I2C
>  	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 in addition to the Vcc supply
> -	  voltage and chip temperature, this driver currently only supports
> -	  reading two currents by measuring two differential voltages across
> -	  series resistors.
> +	  current and temperature monitoring.
>
>  	  This driver can also be built as a module. If so, the module will
>  	  be called ltc2990.
> diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
> index 0ec4102..e8d36f5 100644
> --- a/drivers/hwmon/ltc2990.c
> +++ b/drivers/hwmon/ltc2990.c
> @@ -6,11 +6,7 @@
>   *
>   * 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 reports
> - * the chip's internal temperature and Vcc power supply voltage.
> - *
> - * Value conversion refactored
> + * Value conversion refactored and support for all measurement modes added
>   * by Tom Levens <tom.levens@cern.ch>
>   */
>
> @@ -21,6 +17,7 @@
>  #include <linux/i2c.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
> +#include <linux/of.h>
>
>  #define LTC2990_STATUS	0x00
>  #define LTC2990_CONTROL	0x01
> @@ -35,32 +32,96 @@
>  #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
> +#define LTC2990_CONTROL_MODE_DEFAULT	0x06

I think LTC2990_CONTROL_MODE_CURRENT was better - it describes the actual mode.
Changing the define to _DEFAULT does not really improve code readability.

> +#define LTC2990_CONTROL_MODE_MAX	0x07
> +
> +#define LTC2990_IN0	BIT(0)
> +#define LTC2990_IN1	BIT(1)
> +#define LTC2990_IN2	BIT(2)
> +#define LTC2990_IN3	BIT(3)
> +#define LTC2990_IN4	BIT(4)
> +#define LTC2990_CURR1	BIT(5)
> +#define LTC2990_CURR2	BIT(6)
> +#define LTC2990_TEMP1	BIT(7)
> +#define LTC2990_TEMP2	BIT(8)
> +#define LTC2990_TEMP3	BIT(9)
> +
> +static const int ltc2990_attrs_ena[] = {
> +	LTC2990_IN1 | LTC2990_IN2 | LTC2990_TEMP3,
> +	LTC2990_CURR1 | LTC2990_TEMP3,
> +	LTC2990_CURR1 | LTC2990_IN3 | LTC2990_IN4,
> +	LTC2990_TEMP2 | LTC2990_IN3 | LTC2990_IN4,
> +	LTC2990_TEMP2 | LTC2990_CURR2,
> +	LTC2990_TEMP2 | LTC2990_TEMP3,
> +	LTC2990_CURR1 | LTC2990_CURR2,
> +	LTC2990_IN1 | LTC2990_IN2 | LTC2990_IN3 | LTC2990_IN4
> +};
> +
> +struct ltc2990_data {
> +	struct i2c_client *i2c;
> +	u32 mode;
> +};
>
>  /* Return the converted value from the given register in uV or mC */
> -static int ltc2990_get_value(struct i2c_client *i2c, u8 reg, s32 *result)
> +static int ltc2990_get_value(struct i2c_client *i2c, int index, s32 *result)
>  {
>  	s32 val;
> +	u8 reg;
> +
> +	switch (index) {
> +	case LTC2990_IN0:
> +		reg = LTC2990_VCC_MSB;
> +		break;
> +	case LTC2990_IN1:
> +	case LTC2990_CURR1:
> +	case LTC2990_TEMP2:
> +		reg = LTC2990_V1_MSB;
> +		break;
> +	case LTC2990_IN2:
> +		reg = LTC2990_V2_MSB;
> +		break;
> +	case LTC2990_IN3:
> +	case LTC2990_CURR2:
> +	case LTC2990_TEMP3:
> +		reg = LTC2990_V3_MSB;
> +		break;
> +	case LTC2990_IN4:
> +		reg = LTC2990_V4_MSB;
> +		break;
> +	case LTC2990_TEMP1:
> +		reg = LTC2990_TINT_MSB;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
>
>  	val = i2c_smbus_read_word_swapped(i2c, reg);
>  	if (unlikely(val < 0))
>  		return val;
>
> -	switch (reg) {
> -	case LTC2990_TINT_MSB:
> -		/* internal temp, 0.0625 degrees/LSB, 13-bit  */
> +	switch (index) {
> +	case LTC2990_TEMP1:
> +	case LTC2990_TEMP2:
> +	case LTC2990_TEMP3:
> +		/* temp, 0.0625 degrees/LSB, 13-bit  */
>  		*result = sign_extend32(val, 12) * 1000 / 16;
>  		break;
> -	case LTC2990_V1_MSB:
> -	case LTC2990_V3_MSB:
> -		 /* Vx-Vy, 19.42uV/LSB. Depends on mode. */
> +	case LTC2990_CURR1:
> +	case LTC2990_CURR2:
> +		 /* Vx-Vy, 19.42uV/LSB */
>  		*result = sign_extend32(val, 14) * 1942 / 100;
>  		break;
> -	case LTC2990_VCC_MSB:
> -		/* Vcc, 305.18μV/LSB, 2.5V offset */
> +	case LTC2990_IN0:
> +		/* Vcc, 305.18uV/LSB, 2.5V offset */
>  		*result = sign_extend32(val, 14) * 30518 / (100 * 1000) + 2500;
>  		break;
> +	case LTC2990_IN1:
> +	case LTC2990_IN2:
> +	case LTC2990_IN3:
> +	case LTC2990_IN4:
> +		/* Vx: 305.18uV/LSB */
> +		*result = sign_extend32(val, 14) * 30518 / (100 * 1000);
> +		break;
>  	default:
>  		return -EINVAL; /* won't happen, keep compiler happy */
>  	}
> @@ -72,48 +133,104 @@ 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 = dev_get_drvdata(dev);
>  	s32 value;
>  	int ret;
>
> -	ret = ltc2990_get_value(dev_get_drvdata(dev), attr->index, &value);
> +	ret = ltc2990_get_value(data->i2c, attr->index, &value);
>  	if (unlikely(ret < 0))
>  		return ret;
>
>  	return snprintf(buf, PAGE_SIZE, "%d\n", value);
>  }
>
> +static umode_t ltc2990_attrs_visible(struct kobject *kobj,
> +				     struct attribute *a, int n)
> +{
> +	struct device *dev = container_of(kobj, struct device, kobj);
> +	struct ltc2990_data *data = dev_get_drvdata(dev);
> +	struct device_attribute *da =
> +			container_of(a, struct device_attribute, attr);
> +	struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
> +
> +	if (attr->index == LTC2990_TEMP1 ||
> +	    attr->index == LTC2990_IN0 ||
> +	    attr->index & ltc2990_attrs_ena[data->mode])
> +		return a->mode;
> +	else

Unnecessary else

> +		return 0;
> +}
> +
>  static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, ltc2990_show_value, NULL,
> -			  LTC2990_TINT_MSB);
> +			  LTC2990_TEMP1);
> +static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, ltc2990_show_value, NULL,
> +			  LTC2990_TEMP2);
> +static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, ltc2990_show_value, NULL,
> +			  LTC2990_TEMP3);
>  static SENSOR_DEVICE_ATTR(curr1_input, S_IRUGO, ltc2990_show_value, NULL,
> -			  LTC2990_V1_MSB);
> +			  LTC2990_CURR1);
>  static SENSOR_DEVICE_ATTR(curr2_input, S_IRUGO, ltc2990_show_value, NULL,
> -			  LTC2990_V3_MSB);
> +			  LTC2990_CURR2);
>  static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, ltc2990_show_value, NULL,
> -			  LTC2990_VCC_MSB);
> +			  LTC2990_IN0);
> +static SENSOR_DEVICE_ATTR(in1_input, S_IRUGO, ltc2990_show_value, NULL,
> +			  LTC2990_IN1);
> +static SENSOR_DEVICE_ATTR(in2_input, S_IRUGO, ltc2990_show_value, NULL,
> +			  LTC2990_IN2);
> +static SENSOR_DEVICE_ATTR(in3_input, S_IRUGO, ltc2990_show_value, NULL,
> +			  LTC2990_IN3);
> +static SENSOR_DEVICE_ATTR(in4_input, S_IRUGO, ltc2990_show_value, NULL,
> +			  LTC2990_IN4);
>
>  static struct attribute *ltc2990_attrs[] = {
>  	&sensor_dev_attr_temp1_input.dev_attr.attr,
> +	&sensor_dev_attr_temp2_input.dev_attr.attr,
> +	&sensor_dev_attr_temp3_input.dev_attr.attr,
>  	&sensor_dev_attr_curr1_input.dev_attr.attr,
>  	&sensor_dev_attr_curr2_input.dev_attr.attr,
>  	&sensor_dev_attr_in0_input.dev_attr.attr,
> +	&sensor_dev_attr_in1_input.dev_attr.attr,
> +	&sensor_dev_attr_in2_input.dev_attr.attr,
> +	&sensor_dev_attr_in3_input.dev_attr.attr,
> +	&sensor_dev_attr_in4_input.dev_attr.attr,
>  	NULL,
>  };
> -ATTRIBUTE_GROUPS(ltc2990);
> +
> +static const struct attribute_group ltc2990_group = {
> +	.attrs = ltc2990_attrs,
> +	.is_visible = ltc2990_attrs_visible,
> +};
> +__ATTRIBUTE_GROUPS(ltc2990);
>
>  static int ltc2990_i2c_probe(struct i2c_client *i2c,
>  			     const struct i2c_device_id *id)
>  {
>  	int ret;
>  	struct device *hwmon_dev;
> +	struct ltc2990_data *data;
> +	struct device_node *of_node = i2c->dev.of_node;
>
>  	if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_SMBUS_BYTE_DATA |
>  				     I2C_FUNC_SMBUS_WORD_DATA))
>  		return -ENODEV;
>
> -	/* Setup continuous mode, current monitor */
> +	data = devm_kzalloc(&i2c->dev, sizeof(struct ltc2990_data), GFP_KERNEL);
> +	if (unlikely(!data))
> +		return -ENOMEM;
> +	data->i2c = i2c;
> +
> +	if (!of_node || of_property_read_u32(of_node, "lltc,mode", &data->mode))
> +		data->mode = LTC2990_CONTROL_MODE_DEFAULT;

Iam arguing with myself if we should still do this or if we should read the mode
from the chip instead if it isn't provided (after all, it may have been initialized
by the BIOS/ROMMON).

Mike, would that break your application, or can you specify the mode in devicetree ?

Thanks,
Guenter

> +
> +	if (data->mode > LTC2990_CONTROL_MODE_MAX) {
> +		dev_err(&i2c->dev, "Error: Invalid mode %d.\n", data->mode);
> +		return -EINVAL;
> +	}
> +
> +	/* Setup continuous mode */
>  	ret = i2c_smbus_write_byte_data(i2c, LTC2990_CONTROL,
>  					LTC2990_CONTROL_MEASURE_ALL |
> -					LTC2990_CONTROL_MODE_CURRENT);
> +					data->mode);
>  	if (ret < 0) {
>  		dev_err(&i2c->dev, "Error: Failed to set control mode.\n");
>  		return ret;
> @@ -127,7 +244,7 @@ static int ltc2990_i2c_probe(struct i2c_client *i2c,
>
>  	hwmon_dev = devm_hwmon_device_register_with_groups(&i2c->dev,
>  							   i2c->name,
> -							   i2c,
> +							   data,
>  							   ltc2990_groups);
>
>  	return PTR_ERR_OR_ZERO(hwmon_dev);
>

[toc] | [next] | [standalone]

#1524710

FromMike Looijmans <mike.looijmans@topic.nl>
Date2016-11-17 19:50 +0100
Message-ID<sEzUZ-4p4-5@gated-at.bofh.it>
In reply to#1524603
On 17-11-16 17:56, Guenter Roeck wrote:
> On 11/17/2016 04:10 AM, Tom Levens wrote:
>> Updated version of the ltc2990 driver which supports all measurement
>> modes available in the chip. The mode can be set through a devicetree
>> attribute.
>
> property
>
>>
>> Signed-off-by: Tom Levens <tom.levens@cern.ch>
>> ---
>>
>> Changes since v1:
>>   * Refactored value conversion (patch 1/3)
>>   * Split the devicetree binding into separate patch (patch 2/3)
>>   * Specifying an invalid mode now returns -EINVAL, previously this
>>     only issued a warning and used the default value
>>   * Removed the "mode" sysfs attribute, as the mode of the chip is
>>     hardware specific and should not be user configurable. This allows
>> much
>>     simpler code as a result.
>>
>>  Documentation/hwmon/ltc2990 |   24 ++++---
>>  drivers/hwmon/Kconfig       |    7 +--
>>  drivers/hwmon/ltc2990.c     |  167
>> ++++++++++++++++++++++++++++++++++++-------
>>  3 files changed, 159 insertions(+), 39 deletions(-)
>>
>> diff --git a/Documentation/hwmon/ltc2990 b/Documentation/hwmon/ltc2990
>> index c25211e..3ed68f6 100644
>> --- a/Documentation/hwmon/ltc2990
>> +++ b/Documentation/hwmon/ltc2990
>> @@ -8,6 +8,7 @@ Supported chips:
>>      Datasheet: http://www.linear.com/product/ltc2990
>>
>>  Author: Mike Looijmans <mike.looijmans@topic.nl>
>> +        Tom Levens <tom.levens@cern.ch>
>>
>>
>>  Description
>> @@ -16,10 +17,8 @@ Description
>>  LTC2990 is a Quad I2C Voltage, Current and Temperature Monitor.
>>  The chip's inputs can measure 4 voltages, or two inputs together (1+2
>> and 3+4)
>>  can be combined to measure a differential voltage, which is typically
>> used to
>> -measure current through a series resistor, or a temperature.
>> -
>> -This driver currently uses the 2x differential mode only. In order to
>> support
>> -other modes, the driver will need to be expanded.
>> +measure current through a series resistor, or a temperature with an
>> external
>> +diode.
>>
>>
>>  Usage Notes
>> @@ -32,12 +31,19 @@ devices explicitly.
>>  Sysfs attributes
>>  ----------------
>>
>> +in0_input     Voltage at Vcc pin in millivolt (range 2.5V to 5V)
>> +temp1_input   Internal chip temperature in millidegrees Celcius
>> +
>> +A subset of the following attributes are visible, depending on the
>> measurement
>> +mode of the chip.
>> +
>> +in[1-4]_input Voltage at V[1-4] pin in millivolt
>> +temp2_input   External temperature sensor TR1 in millidegrees Celcius
>> +temp3_input   External temperature sensor TR2 in millidegrees Celcius
>> +curr1_input   Current in mA across V1-V2 assuming a 1mOhm sense resistor
>> +curr2_input   Current in mA across V3-V4 assuming a 1mOhm sense resistor
>> +
>>  The "curr*_input" measurements actually report the voltage drop
>> across the
>>  input pins in microvolts. This is equivalent to the current through a
>> 1mOhm
>>  sense resistor. Divide the reported value by the actual sense
>> resistor value
>>  in mOhm to get the actual value.
>> -
>> -in0_input     Voltage at Vcc pin in millivolt (range 2.5V to 5V)
>> -temp1_input   Internal chip temperature in millidegrees Celcius
>> -curr1_input   Current in mA across v1-v2 assuming a 1mOhm sense
>> resistor.
>> -curr2_input   Current in mA across v3-v4 assuming a 1mOhm sense
>> resistor.
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 45cef3d..f7096ca 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -699,15 +699,12 @@ config SENSORS_LTC2945
>>        be called ltc2945.
>>
>>  config SENSORS_LTC2990
>> -    tristate "Linear Technology LTC2990 (current monitoring mode only)"
>> +    tristate "Linear Technology LTC2990"
>>      depends on I2C
>>      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 in addition to the Vcc
>> supply
>> -      voltage and chip temperature, this driver currently only supports
>> -      reading two currents by measuring two differential voltages across
>> -      series resistors.
>> +      current and temperature monitoring.
>>
>>        This driver can also be built as a module. If so, the module will
>>        be called ltc2990.
>> diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
>> index 0ec4102..e8d36f5 100644
>> --- a/drivers/hwmon/ltc2990.c
>> +++ b/drivers/hwmon/ltc2990.c
>> @@ -6,11 +6,7 @@
>>   *
>>   * 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 reports
>> - * the chip's internal temperature and Vcc power supply voltage.
>> - *
>> - * Value conversion refactored
>> + * Value conversion refactored and support for all measurement modes
>> added
>>   * by Tom Levens <tom.levens@cern.ch>
>>   */
>>
>> @@ -21,6 +17,7 @@
>>  #include <linux/i2c.h>
>>  #include <linux/kernel.h>
>>  #include <linux/module.h>
>> +#include <linux/of.h>
>>
>>  #define LTC2990_STATUS    0x00
>>  #define LTC2990_CONTROL    0x01
>> @@ -35,32 +32,96 @@
>>  #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
>> +#define LTC2990_CONTROL_MODE_DEFAULT    0x06
>
> I think LTC2990_CONTROL_MODE_CURRENT was better - it describes the
> actual mode.
> Changing the define to _DEFAULT does not really improve code readability.

I think I understand what the author intended - the mode becomes an 
index into the array.

But I think the define can be dropped altogether, see below.

>
>> +#define LTC2990_CONTROL_MODE_MAX    0x07
>> +
>> +#define LTC2990_IN0    BIT(0)
>> +#define LTC2990_IN1    BIT(1)
>> +#define LTC2990_IN2    BIT(2)
>> +#define LTC2990_IN3    BIT(3)
>> +#define LTC2990_IN4    BIT(4)
>> +#define LTC2990_CURR1    BIT(5)
>> +#define LTC2990_CURR2    BIT(6)
>> +#define LTC2990_TEMP1    BIT(7)
>> +#define LTC2990_TEMP2    BIT(8)
>> +#define LTC2990_TEMP3    BIT(9)
>> +
>> +static const int ltc2990_attrs_ena[] = {
>> +    LTC2990_IN1 | LTC2990_IN2 | LTC2990_TEMP3,
>> +    LTC2990_CURR1 | LTC2990_TEMP3,
>> +    LTC2990_CURR1 | LTC2990_IN3 | LTC2990_IN4,
>> +    LTC2990_TEMP2 | LTC2990_IN3 | LTC2990_IN4,
>> +    LTC2990_TEMP2 | LTC2990_CURR2,
>> +    LTC2990_TEMP2 | LTC2990_TEMP3,
>> +    LTC2990_CURR1 | LTC2990_CURR2,
>> +    LTC2990_IN1 | LTC2990_IN2 | LTC2990_IN3 | LTC2990_IN4
>> +};
>> +
>> +struct ltc2990_data {
>> +    struct i2c_client *i2c;
>> +    u32 mode;
>> +};
>>
>>  /* Return the converted value from the given register in uV or mC */
>> -static int ltc2990_get_value(struct i2c_client *i2c, u8 reg, s32
>> *result)
>> +static int ltc2990_get_value(struct i2c_client *i2c, int index, s32
>> *result)
>>  {
>>      s32 val;
>> +    u8 reg;
>> +
>> +    switch (index) {
>> +    case LTC2990_IN0:
>> +        reg = LTC2990_VCC_MSB;
>> +        break;
>> +    case LTC2990_IN1:
>> +    case LTC2990_CURR1:
>> +    case LTC2990_TEMP2:
>> +        reg = LTC2990_V1_MSB;
>> +        break;
>> +    case LTC2990_IN2:
>> +        reg = LTC2990_V2_MSB;
>> +        break;
>> +    case LTC2990_IN3:
>> +    case LTC2990_CURR2:
>> +    case LTC2990_TEMP3:
>> +        reg = LTC2990_V3_MSB;
>> +        break;
>> +    case LTC2990_IN4:
>> +        reg = LTC2990_V4_MSB;
>> +        break;
>> +    case LTC2990_TEMP1:
>> +        reg = LTC2990_TINT_MSB;
>> +        break;
>> +    default:
>> +        return -EINVAL;
>> +    }
>>
>>      val = i2c_smbus_read_word_swapped(i2c, reg);
>>      if (unlikely(val < 0))
>>          return val;
>>
>> -    switch (reg) {
>> -    case LTC2990_TINT_MSB:
>> -        /* internal temp, 0.0625 degrees/LSB, 13-bit  */
>> +    switch (index) {
>> +    case LTC2990_TEMP1:
>> +    case LTC2990_TEMP2:
>> +    case LTC2990_TEMP3:
>> +        /* temp, 0.0625 degrees/LSB, 13-bit  */
>>          *result = sign_extend32(val, 12) * 1000 / 16;
>>          break;
>> -    case LTC2990_V1_MSB:
>> -    case LTC2990_V3_MSB:
>> -         /* Vx-Vy, 19.42uV/LSB. Depends on mode. */
>> +    case LTC2990_CURR1:
>> +    case LTC2990_CURR2:
>> +         /* Vx-Vy, 19.42uV/LSB */
>>          *result = sign_extend32(val, 14) * 1942 / 100;
>>          break;
>> -    case LTC2990_VCC_MSB:
>> -        /* Vcc, 305.18μV/LSB, 2.5V offset */
>> +    case LTC2990_IN0:
>> +        /* Vcc, 305.18uV/LSB, 2.5V offset */
>>          *result = sign_extend32(val, 14) * 30518 / (100 * 1000) + 2500;
>>          break;
>> +    case LTC2990_IN1:
>> +    case LTC2990_IN2:
>> +    case LTC2990_IN3:
>> +    case LTC2990_IN4:
>> +        /* Vx: 305.18uV/LSB */
>> +        *result = sign_extend32(val, 14) * 30518 / (100 * 1000);
>> +        break;
>>      default:
>>          return -EINVAL; /* won't happen, keep compiler happy */
>>      }
>> @@ -72,48 +133,104 @@ 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 = dev_get_drvdata(dev);
>>      s32 value;
>>      int ret;
>>
>> -    ret = ltc2990_get_value(dev_get_drvdata(dev), attr->index, &value);
>> +    ret = ltc2990_get_value(data->i2c, attr->index, &value);
>>      if (unlikely(ret < 0))
>>          return ret;
>>
>>      return snprintf(buf, PAGE_SIZE, "%d\n", value);
>>  }
>>
>> +static umode_t ltc2990_attrs_visible(struct kobject *kobj,
>> +                     struct attribute *a, int n)
>> +{
>> +    struct device *dev = container_of(kobj, struct device, kobj);
>> +    struct ltc2990_data *data = dev_get_drvdata(dev);
>> +    struct device_attribute *da =
>> +            container_of(a, struct device_attribute, attr);
>> +    struct sensor_device_attribute *attr = to_sensor_dev_attr(da);
>> +
>> +    if (attr->index == LTC2990_TEMP1 ||
>> +        attr->index == LTC2990_IN0 ||
>> +        attr->index & ltc2990_attrs_ena[data->mode])
>> +        return a->mode;
>> +    else
>
> Unnecessary else
>
>> +        return 0;
>> +}
>> +
>>  static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, ltc2990_show_value,
>> NULL,
>> -              LTC2990_TINT_MSB);
>> +              LTC2990_TEMP1);
>> +static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, ltc2990_show_value,
>> NULL,
>> +              LTC2990_TEMP2);
>> +static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, ltc2990_show_value,
>> NULL,
>> +              LTC2990_TEMP3);
>>  static SENSOR_DEVICE_ATTR(curr1_input, S_IRUGO, ltc2990_show_value,
>> NULL,
>> -              LTC2990_V1_MSB);
>> +              LTC2990_CURR1);
>>  static SENSOR_DEVICE_ATTR(curr2_input, S_IRUGO, ltc2990_show_value,
>> NULL,
>> -              LTC2990_V3_MSB);
>> +              LTC2990_CURR2);
>>  static SENSOR_DEVICE_ATTR(in0_input, S_IRUGO, ltc2990_show_value, NULL,
>> -              LTC2990_VCC_MSB);
>> +              LTC2990_IN0);
>> +static SENSOR_DEVICE_ATTR(in1_input, S_IRUGO, ltc2990_show_value, NULL,
>> +              LTC2990_IN1);
>> +static SENSOR_DEVICE_ATTR(in2_input, S_IRUGO, ltc2990_show_value, NULL,
>> +              LTC2990_IN2);
>> +static SENSOR_DEVICE_ATTR(in3_input, S_IRUGO, ltc2990_show_value, NULL,
>> +              LTC2990_IN3);
>> +static SENSOR_DEVICE_ATTR(in4_input, S_IRUGO, ltc2990_show_value, NULL,
>> +              LTC2990_IN4);
>>
>>  static struct attribute *ltc2990_attrs[] = {
>>      &sensor_dev_attr_temp1_input.dev_attr.attr,
>> +    &sensor_dev_attr_temp2_input.dev_attr.attr,
>> +    &sensor_dev_attr_temp3_input.dev_attr.attr,
>>      &sensor_dev_attr_curr1_input.dev_attr.attr,
>>      &sensor_dev_attr_curr2_input.dev_attr.attr,
>>      &sensor_dev_attr_in0_input.dev_attr.attr,
>> +    &sensor_dev_attr_in1_input.dev_attr.attr,
>> +    &sensor_dev_attr_in2_input.dev_attr.attr,
>> +    &sensor_dev_attr_in3_input.dev_attr.attr,
>> +    &sensor_dev_attr_in4_input.dev_attr.attr,
>>      NULL,
>>  };
>> -ATTRIBUTE_GROUPS(ltc2990);
>> +
>> +static const struct attribute_group ltc2990_group = {
>> +    .attrs = ltc2990_attrs,
>> +    .is_visible = ltc2990_attrs_visible,
>> +};
>> +__ATTRIBUTE_GROUPS(ltc2990);
>>
>>  static int ltc2990_i2c_probe(struct i2c_client *i2c,
>>                   const struct i2c_device_id *id)
>>  {
>>      int ret;
>>      struct device *hwmon_dev;
>> +    struct ltc2990_data *data;
>> +    struct device_node *of_node = i2c->dev.of_node;
>>
>>      if (!i2c_check_functionality(i2c->adapter,
>> I2C_FUNC_SMBUS_BYTE_DATA |
>>                       I2C_FUNC_SMBUS_WORD_DATA))
>>          return -ENODEV;
>>
>> -    /* Setup continuous mode, current monitor */
>> +    data = devm_kzalloc(&i2c->dev, sizeof(struct ltc2990_data),
>> GFP_KERNEL);
>> +    if (unlikely(!data))
>> +        return -ENOMEM;
>> +    data->i2c = i2c;
>> +
>> +    if (!of_node || of_property_read_u32(of_node, "lltc,mode",
>> &data->mode))
>> +        data->mode = LTC2990_CONTROL_MODE_DEFAULT;
>
> Iam arguing with myself if we should still do this or if we should read
> the mode
> from the chip instead if it isn't provided (after all, it may have been
> initialized
> by the BIOS/ROMMON).

I think the mode should be explicitly set, without default. There's no 
way to tell whether the BIOS or bootloader has really set it up or 
whether the chip is just reporting whatever it happened to default to. 
And given the chip's function, it's unlikely a bootloader would want to 
initialize it.

My advice would be to make it a required property. If not set, display 
an error and bail out.

> Mike, would that break your application, or can you specify the mode in
> devicetree ?

I'm fine with specifying this in the devicetree. It will break things 
for me, but I've been warned and willing to bow for the greater good :)

>
> Thanks,
> Guenter
>
>> +
>> +    if (data->mode > LTC2990_CONTROL_MODE_MAX) {
>> +        dev_err(&i2c->dev, "Error: Invalid mode %d.\n", data->mode);
>> +        return -EINVAL;
>> +    }
>> +
>> +    /* Setup continuous mode */
>>      ret = i2c_smbus_write_byte_data(i2c, LTC2990_CONTROL,
>>                      LTC2990_CONTROL_MEASURE_ALL |
>> -                    LTC2990_CONTROL_MODE_CURRENT);
>> +                    data->mode);
>>      if (ret < 0) {
>>          dev_err(&i2c->dev, "Error: Failed to set control mode.\n");
>>          return ret;
>> @@ -127,7 +244,7 @@ static int ltc2990_i2c_probe(struct i2c_client *i2c,
>>
>>      hwmon_dev = devm_hwmon_device_register_with_groups(&i2c->dev,
>>                                 i2c->name,
>> -                               i2c,
>> +                               data,
>>                                 ltc2990_groups);
>>
>>      return PTR_ERR_OR_ZERO(hwmon_dev);
>>
>


-- 
Mike Looijmans


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

[toc] | [prev] | [next] | [standalone]

#1524725

FromGuenter Roeck <linux@roeck-us.net>
Date2016-11-17 20:00 +0100
Message-ID<sEA4F-4sG-3@gated-at.bofh.it>
In reply to#1524710
On Thu, Nov 17, 2016 at 06:40:17PM +0100, Mike Looijmans wrote:
> On 17-11-16 17:56, Guenter Roeck wrote:
> >On 11/17/2016 04:10 AM, Tom Levens wrote:
> >>Updated version of the ltc2990 driver which supports all measurement
> >>modes available in the chip. The mode can be set through a devicetree
> >>attribute.
> >
[ ... ] 

> >>
> >> static int ltc2990_i2c_probe(struct i2c_client *i2c,
> >>                  const struct i2c_device_id *id)
> >> {
> >>     int ret;
> >>     struct device *hwmon_dev;
> >>+    struct ltc2990_data *data;
> >>+    struct device_node *of_node = i2c->dev.of_node;
> >>
> >>     if (!i2c_check_functionality(i2c->adapter,
> >>I2C_FUNC_SMBUS_BYTE_DATA |
> >>                      I2C_FUNC_SMBUS_WORD_DATA))
> >>         return -ENODEV;
> >>
> >>-    /* Setup continuous mode, current monitor */
> >>+    data = devm_kzalloc(&i2c->dev, sizeof(struct ltc2990_data),
> >>GFP_KERNEL);
> >>+    if (unlikely(!data))
> >>+        return -ENOMEM;
> >>+    data->i2c = i2c;
> >>+
> >>+    if (!of_node || of_property_read_u32(of_node, "lltc,mode",
> >>&data->mode))
> >>+        data->mode = LTC2990_CONTROL_MODE_DEFAULT;
> >
> >Iam arguing with myself if we should still do this or if we should read
> >the mode
> >from the chip instead if it isn't provided (after all, it may have been
> >initialized
> >by the BIOS/ROMMON).
> 
> I think the mode should be explicitly set, without default. There's no way
> to tell whether the BIOS or bootloader has really set it up or whether the
> chip is just reporting whatever it happened to default to. And given the
> chip's function, it's unlikely a bootloader would want to initialize it.
> 
Unlikely but possible. Even if we all agree that the chip should be configured
by the driver, I don't like imposing that view on everyone else.

> My advice would be to make it a required property. If not set, display an
> error and bail out.
> 
It is not that easy, unfortunately. It also has to work on a non-devicetree
system. I would not object to making the property mandatory, but we would
still need to provide non-DT support.

My "use case" for taking the current mode from the chip if not specified
is that it would enable me to run a module test with all modes. I consider
this extremely valuable.

> >Mike, would that break your application, or can you specify the mode in
> >devicetree ?
> 
> I'm fine with specifying this in the devicetree. It will break things for
> me, but I've been warned and willing to bow for the greater good :)
> 
I should have asked if your system uses devicetree. If it does, the problem
should be easy to fix for you. If not, we'll need to find a solution
for your use case.

Thanks,
Guenter

[toc] | [prev] | [next] | [standalone]

#1524801

FromMike Looijmans <mike.looijmans@topic.nl>
Date2016-11-17 21:30 +0100
Message-ID<sEBtM-5wM-23@gated-at.bofh.it>
In reply to#1524725
On 17-11-2016 19:56, Guenter Roeck wrote:
> On Thu, Nov 17, 2016 at 06:40:17PM +0100, Mike Looijmans wrote:
>> On 17-11-16 17:56, Guenter Roeck wrote:
>>> On 11/17/2016 04:10 AM, Tom Levens wrote:
>>>> Updated version of the ltc2990 driver which supports all measurement
>>>> modes available in the chip. The mode can be set through a devicetree
>>>> attribute.
>>>
> [ ... ]
>
>>>>
>>>> static int ltc2990_i2c_probe(struct i2c_client *i2c,
>>>>                   const struct i2c_device_id *id)
>>>> {
>>>>      int ret;
>>>>      struct device *hwmon_dev;
>>>> +    struct ltc2990_data *data;
>>>> +    struct device_node *of_node = i2c->dev.of_node;
>>>>
>>>>      if (!i2c_check_functionality(i2c->adapter,
>>>> I2C_FUNC_SMBUS_BYTE_DATA |
>>>>                       I2C_FUNC_SMBUS_WORD_DATA))
>>>>          return -ENODEV;
>>>>
>>>> -    /* Setup continuous mode, current monitor */
>>>> +    data = devm_kzalloc(&i2c->dev, sizeof(struct ltc2990_data),
>>>> GFP_KERNEL);
>>>> +    if (unlikely(!data))
>>>> +        return -ENOMEM;
>>>> +    data->i2c = i2c;
>>>> +
>>>> +    if (!of_node || of_property_read_u32(of_node, "lltc,mode",
>>>> &data->mode))
>>>> +        data->mode = LTC2990_CONTROL_MODE_DEFAULT;
>>>
>>> Iam arguing with myself if we should still do this or if we should read
>>> the mode
>> >from the chip instead if it isn't provided (after all, it may have been
>>> initialized
>>> by the BIOS/ROMMON).
>>
>> I think the mode should be explicitly set, without default. There's no way
>> to tell whether the BIOS or bootloader has really set it up or whether the
>> chip is just reporting whatever it happened to default to. And given the
>> chip's function, it's unlikely a bootloader would want to initialize it.
>>
> Unlikely but possible. Even if we all agree that the chip should be configured
> by the driver, I don't like imposing that view on everyone else.
>
>> My advice would be to make it a required property. If not set, display an
>> error and bail out.
>>
> It is not that easy, unfortunately. It also has to work on a non-devicetree
> system. I would not object to making the property mandatory, but we would
> still need to provide non-DT support.
>
> My "use case" for taking the current mode from the chip if not specified
> is that it would enable me to run a module test with all modes. I consider
> this extremely valuable.

Good point.

The chip defaults to measuring internal temperature only, and the mode 
defaults to "0".

Choosing a mode that doesn't match the actual circuitry could be bad for 
the chip or the board (though unlikely, it'll probably just be useless) 
since it will actively drive some of the inputs in the temperature modes 
(which is default for V3/V4 pins).

Instead of failing, one could choose to set the default mode to "7", 
which just measures the 4 voltages, which would be a harmless mode in 
all cases.

As a way to let a bootloader set things up, I think it would be a good 
check to see if CONTROL register bits 4:3 are set. If "00", the chip is 
not acquiring data at all, and probably needs configuration still. In 
that case, the mode must be provided by the devicetree (or the default "7").
If bits 4:3 are "11", it has already been set up to measure its inputs, 
and it's okay to continue doing just that and use the current value of 
2:0 register as default mode (if the devicetree didn't specify any mode 
at all).

The reason I wanted the property to be mandatory is to trigger users 
like me (probably I'm the only other user so far) to update their 
devicetree. But I'd notice quickly enough if it defaults to something 
else. So that's not very compelling.

>>> Mike, would that break your application, or can you specify the mode in
>>> devicetree ?
>>
>> I'm fine with specifying this in the devicetree. It will break things for
>> me, but I've been warned and willing to bow for the greater good :)
>>
> I should have asked if your system uses devicetree. If it does, the problem
> should be easy to fix for you. If not, we'll need to find a solution
> for your use case.

I'm using devicetree. I planned to 'mainline' the boards some time this 
year...

>
> Thanks,
> Guenter
>


-- 
Mike Looijmans


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

[toc] | [prev] | [next] | [standalone]

#1524838

FromGuenter Roeck <linux@roeck-us.net>
Date2016-11-17 23:00 +0100
Message-ID<sECSS-6iy-17@gated-at.bofh.it>
In reply to#1524801
On Thu, Nov 17, 2016 at 08:52:12PM +0100, Mike Looijmans wrote:
> On 17-11-2016 19:56, Guenter Roeck wrote:
> >On Thu, Nov 17, 2016 at 06:40:17PM +0100, Mike Looijmans wrote:
> >>On 17-11-16 17:56, Guenter Roeck wrote:
> >>>On 11/17/2016 04:10 AM, Tom Levens wrote:
> >>>>Updated version of the ltc2990 driver which supports all measurement
> >>>>modes available in the chip. The mode can be set through a devicetree
> >>>>attribute.
> >>>
> >[ ... ]
> >
> >>>>
> >>>>static int ltc2990_i2c_probe(struct i2c_client *i2c,
> >>>>                  const struct i2c_device_id *id)
> >>>>{
> >>>>     int ret;
> >>>>     struct device *hwmon_dev;
> >>>>+    struct ltc2990_data *data;
> >>>>+    struct device_node *of_node = i2c->dev.of_node;
> >>>>
> >>>>     if (!i2c_check_functionality(i2c->adapter,
> >>>>I2C_FUNC_SMBUS_BYTE_DATA |
> >>>>                      I2C_FUNC_SMBUS_WORD_DATA))
> >>>>         return -ENODEV;
> >>>>
> >>>>-    /* Setup continuous mode, current monitor */
> >>>>+    data = devm_kzalloc(&i2c->dev, sizeof(struct ltc2990_data),
> >>>>GFP_KERNEL);
> >>>>+    if (unlikely(!data))
> >>>>+        return -ENOMEM;
> >>>>+    data->i2c = i2c;
> >>>>+
> >>>>+    if (!of_node || of_property_read_u32(of_node, "lltc,mode",
> >>>>&data->mode))
> >>>>+        data->mode = LTC2990_CONTROL_MODE_DEFAULT;
> >>>
> >>>Iam arguing with myself if we should still do this or if we should read
> >>>the mode
> >>>from the chip instead if it isn't provided (after all, it may have been
> >>>initialized
> >>>by the BIOS/ROMMON).
> >>
> >>I think the mode should be explicitly set, without default. There's no way
> >>to tell whether the BIOS or bootloader has really set it up or whether the
> >>chip is just reporting whatever it happened to default to. And given the
> >>chip's function, it's unlikely a bootloader would want to initialize it.
> >>
> >Unlikely but possible. Even if we all agree that the chip should be configured
> >by the driver, I don't like imposing that view on everyone else.
> >
> >>My advice would be to make it a required property. If not set, display an
> >>error and bail out.
> >>
> >It is not that easy, unfortunately. It also has to work on a non-devicetree
> >system. I would not object to making the property mandatory, but we would
> >still need to provide non-DT support.
> >
> >My "use case" for taking the current mode from the chip if not specified
> >is that it would enable me to run a module test with all modes. I consider
> >this extremely valuable.
> 
> Good point.
> 
> The chip defaults to measuring internal temperature only, and the mode
> defaults to "0".
> 
> Choosing a mode that doesn't match the actual circuitry could be bad for the
> chip or the board (though unlikely, it'll probably just be useless) since it
> will actively drive some of the inputs in the temperature modes (which is
> default for V3/V4 pins).
> 
> Instead of failing, one could choose to set the default mode to "7", which
> just measures the 4 voltages, which would be a harmless mode in all cases.
> 
> As a way to let a bootloader set things up, I think it would be a good check
> to see if CONTROL register bits 4:3 are set. If "00", the chip is not
> acquiring data at all, and probably needs configuration still. In that case,
> the mode must be provided by the devicetree (or the default "7").
> If bits 4:3 are "11", it has already been set up to measure its inputs, and
> it's okay to continue doing just that and use the current value of 2:0
> register as default mode (if the devicetree didn't specify any mode at all).
> 

At first glance, agreed, though by default b[3:4] are 00, and only the
internal temperature is measured. Actually, the 5 mode bits are all
relevant to determine what is measured. Maybe it would be better to take
all 5 bits into account instead of blindly setting b[34]:=11 and a specific
setting of b[0:2]. Sure, that would make the mode table a bit larger,
but then ltc2990_attrs_ena[] could be made an u16 array, and a table size
of 64 bytes would not be that bad.

What do you think ?

Thanks,
Guenter

[toc] | [prev] | [next] | [standalone]

#1524896

FromGuenter Roeck <linux@roeck-us.net>
Date2016-11-18 00:50 +0100
Message-ID<sEEBj-7vt-9@gated-at.bofh.it>
In reply to#1524838
On Thu, Nov 17, 2016 at 11:25:30PM +0000, Tom Levens wrote:
> On 17 Nov 2016, at 22:54, Guenter Roeck <linux@roeck-us.net> wrote:
> > On Thu, Nov 17, 2016 at 08:52:12PM +0100, Mike Looijmans wrote:
> >> On 17-11-2016 19:56, Guenter Roeck wrote:
> >>> On Thu, Nov 17, 2016 at 06:40:17PM +0100, Mike Looijmans wrote:
> >>>> On 17-11-16 17:56, Guenter Roeck wrote:
> >>>>> On 11/17/2016 04:10 AM, Tom Levens wrote:
> >>>>>> Updated version of the ltc2990 driver which supports all measurement
> >>>>>> modes available in the chip. The mode can be set through a devicetree
> >>>>>> attribute.
> >>>>> 
> >>> [ ... ]
> >>> 
> >>>>>> 
> >>>>>> static int ltc2990_i2c_probe(struct i2c_client *i2c,
> >>>>>>                 const struct i2c_device_id *id)
> >>>>>> {
> >>>>>>    int ret;
> >>>>>>    struct device *hwmon_dev;
> >>>>>> +    struct ltc2990_data *data;
> >>>>>> +    struct device_node *of_node = i2c->dev.of_node;
> >>>>>> 
> >>>>>>    if (!i2c_check_functionality(i2c->adapter,
> >>>>>> I2C_FUNC_SMBUS_BYTE_DATA |
> >>>>>>                     I2C_FUNC_SMBUS_WORD_DATA))
> >>>>>>        return -ENODEV;
> >>>>>> 
> >>>>>> -    /* Setup continuous mode, current monitor */
> >>>>>> +    data = devm_kzalloc(&i2c->dev, sizeof(struct ltc2990_data),
> >>>>>> GFP_KERNEL);
> >>>>>> +    if (unlikely(!data))
> >>>>>> +        return -ENOMEM;
> >>>>>> +    data->i2c = i2c;
> >>>>>> +
> >>>>>> +    if (!of_node || of_property_read_u32(of_node, "lltc,mode",
> >>>>>> &data->mode))
> >>>>>> +        data->mode = LTC2990_CONTROL_MODE_DEFAULT;
> >>>>> 
> >>>>> Iam arguing with myself if we should still do this or if we should read
> >>>>> the mode
> >>>>> from the chip instead if it isn't provided (after all, it may have been
> >>>>> initialized
> >>>>> by the BIOS/ROMMON).
> >>>> 
> >>>> I think the mode should be explicitly set, without default. There's no way
> >>>> to tell whether the BIOS or bootloader has really set it up or whether the
> >>>> chip is just reporting whatever it happened to default to. And given the
> >>>> chip's function, it's unlikely a bootloader would want to initialize it.
> >>>> 
> >>> Unlikely but possible. Even if we all agree that the chip should be configured
> >>> by the driver, I don't like imposing that view on everyone else.
> >>> 
> >>>> My advice would be to make it a required property. If not set, display an
> >>>> error and bail out.
> >>>> 
> >>> It is not that easy, unfortunately. It also has to work on a non-devicetree
> >>> system. I would not object to making the property mandatory, but we would
> >>> still need to provide non-DT support.
> >>> 
> >>> My "use case" for taking the current mode from the chip if not specified
> >>> is that it would enable me to run a module test with all modes. I consider
> >>> this extremely valuable.
> >> 
> >> Good point.
> >> 
> >> The chip defaults to measuring internal temperature only, and the mode
> >> defaults to "0".
> >> 
> >> Choosing a mode that doesn't match the actual circuitry could be bad for the
> >> chip or the board (though unlikely, it'll probably just be useless) since it
> >> will actively drive some of the inputs in the temperature modes (which is
> >> default for V3/V4 pins).
> >> 
> >> Instead of failing, one could choose to set the default mode to "7", which
> >> just measures the 4 voltages, which would be a harmless mode in all cases.
> >> 
> >> As a way to let a bootloader set things up, I think it would be a good check
> >> to see if CONTROL register bits 4:3 are set. If "00", the chip is not
> >> acquiring data at all, and probably needs configuration still. In that case,
> >> the mode must be provided by the devicetree (or the default "7").
> >> If bits 4:3 are "11", it has already been set up to measure its inputs, and
> >> it's okay to continue doing just that and use the current value of 2:0
> >> register as default mode (if the devicetree didn't specify any mode at all).
> >> 
> > 
> > At first glance, agreed, though by default b[3:4] are 00, and only the
> > internal temperature is measured. Actually, the 5 mode bits are all
> > relevant to determine what is measured. Maybe it would be better to take
> > all 5 bits into account instead of blindly setting b[34]:=11 and a specific
> > setting of b[0:2]. Sure, that would make the mode table a bit larger,
> > but then ltc2990_attrs_ena[] could be made an u16 array, and a table size
> > of 64 bytes would not be that bad.
> 
> I would tend to agree that it should be possible to configure all 5 mode
> bits through the devicetree. What I would propose is as follows.
> 
> If a devicetree node exists, the mode parameter(s?) are required and the 
> chip is initialised.
> 
> If a devicetree node doesn't exist, it is assumed that the chip has 
> already been configured (by the BIOS, etc). The mode is read from the 
> chip to set the visibility of the sysfs attributes. In the worst case, where the 
> chip has not been configured by another source, it would only be possible
> to measure the internal temperature -- but I think this is an acceptable
> limitation.
> 
SGTM.

> The only case that this does not cover is if the device tree node 
> exists but the chip is expected to be configured by some other source. 
> Maybe I am wrong, but I would not expect this to be a terribly common
> situation.
> 
> What do you think?
> 
I would not bother about this case. Just make the mode property mandatory.

Thanks,
Guenter

[toc] | [prev] | [next] | [standalone]

#1525369

FromGuenter Roeck <linux@roeck-us.net>
Date2016-11-18 15:20 +0100
Message-ID<sESbg-8gx-31@gated-at.bofh.it>
In reply to#1524896
On 11/18/2016 04:23 AM, Tom Levens wrote:
>
>
> On Fri, 18 Nov 2016, Guenter Roeck wrote:
>
>> On Thu, Nov 17, 2016 at 11:25:30PM +0000, Tom Levens wrote:
>>> On 17 Nov 2016, at 22:54, Guenter Roeck <linux@roeck-us.net> wrote:
>>>> On Thu, Nov 17, 2016 at 08:52:12PM +0100, Mike Looijmans wrote:
>>>>> On 17-11-2016 19:56, Guenter Roeck wrote:
>>>>>> On Thu, Nov 17, 2016 at 06:40:17PM +0100, Mike Looijmans wrote:
>>>>>>> On 17-11-16 17:56, Guenter Roeck wrote:
>>>>>>>> On 11/17/2016 04:10 AM, Tom Levens wrote:
>>>>>>>>> Updated version of the ltc2990 driver which supports all measurement
>>>>>>>>> modes available in the chip. The mode can be set through a devicetree
>>>>>>>>> attribute.
>>>>>>>>
>>>>>> [ ... ]
>>>>>>
>>>>>>>>>
>>>>>>>>> static int ltc2990_i2c_probe(struct i2c_client *i2c,
>>>>>>>>>                 const struct i2c_device_id *id)
>>>>>>>>> {
>>>>>>>>>    int ret;
>>>>>>>>>    struct device *hwmon_dev;
>>>>>>>>> +    struct ltc2990_data *data;
>>>>>>>>> +    struct device_node *of_node = i2c->dev.of_node;
>>>>>>>>>
>>>>>>>>>    if (!i2c_check_functionality(i2c->adapter,
>>>>>>>>> I2C_FUNC_SMBUS_BYTE_DATA |
>>>>>>>>>                     I2C_FUNC_SMBUS_WORD_DATA))
>>>>>>>>>        return -ENODEV;
>>>>>>>>>
>>>>>>>>> -    /* Setup continuous mode, current monitor */
>>>>>>>>> +    data = devm_kzalloc(&i2c->dev, sizeof(struct ltc2990_data),
>>>>>>>>> GFP_KERNEL);
>>>>>>>>> +    if (unlikely(!data))
>>>>>>>>> +        return -ENOMEM;
>>>>>>>>> +    data->i2c = i2c;
>>>>>>>>> +
>>>>>>>>> +    if (!of_node || of_property_read_u32(of_node, "lltc,mode",
>>>>>>>>> &data->mode))
>>>>>>>>> +        data->mode = LTC2990_CONTROL_MODE_DEFAULT;
>>>>>>>>
>>>>>>>> Iam arguing with myself if we should still do this or if we should read
>>>>>>>> the mode
>>>>>>>> from the chip instead if it isn't provided (after all, it may have been
>>>>>>>> initialized
>>>>>>>> by the BIOS/ROMMON).
>>>>>>>
>>>>>>> I think the mode should be explicitly set, without default. There's no way
>>>>>>> to tell whether the BIOS or bootloader has really set it up or whether the
>>>>>>> chip is just reporting whatever it happened to default to. And given the
>>>>>>> chip's function, it's unlikely a bootloader would want to initialize it.
>>>>>>>
>>>>>> Unlikely but possible. Even if we all agree that the chip should be configured
>>>>>> by the driver, I don't like imposing that view on everyone else.
>>>>>>
>>>>>>> My advice would be to make it a required property. If not set, display an
>>>>>>> error and bail out.
>>>>>>>
>>>>>> It is not that easy, unfortunately. It also has to work on a non-devicetree
>>>>>> system. I would not object to making the property mandatory, but we would
>>>>>> still need to provide non-DT support.
>>>>>>
>>>>>> My "use case" for taking the current mode from the chip if not specified
>>>>>> is that it would enable me to run a module test with all modes. I consider
>>>>>> this extremely valuable.
>>>>>
>>>>> Good point.
>>>>>
>>>>> The chip defaults to measuring internal temperature only, and the mode
>>>>> defaults to "0".
>>>>>
>>>>> Choosing a mode that doesn't match the actual circuitry could be bad for the
>>>>> chip or the board (though unlikely, it'll probably just be useless) since it
>>>>> will actively drive some of the inputs in the temperature modes (which is
>>>>> default for V3/V4 pins).
>>>>>
>>>>> Instead of failing, one could choose to set the default mode to "7", which
>>>>> just measures the 4 voltages, which would be a harmless mode in all cases.
>>>>>
>>>>> As a way to let a bootloader set things up, I think it would be a good check
>>>>> to see if CONTROL register bits 4:3 are set. If "00", the chip is not
>>>>> acquiring data at all, and probably needs configuration still. In that case,
>>>>> the mode must be provided by the devicetree (or the default "7").
>>>>> If bits 4:3 are "11", it has already been set up to measure its inputs, and
>>>>> it's okay to continue doing just that and use the current value of 2:0
>>>>> register as default mode (if the devicetree didn't specify any mode at all).
>>>>>
>>>>
>>>> At first glance, agreed, though by default b[3:4] are 00, and only the
>>>> internal temperature is measured. Actually, the 5 mode bits are all
>>>> relevant to determine what is measured. Maybe it would be better to take
>>>> all 5 bits into account instead of blindly setting b[34]:=11 and a specific
>>>> setting of b[0:2]. Sure, that would make the mode table a bit larger,
>>>> but then ltc2990_attrs_ena[] could be made an u16 array, and a table size
>>>> of 64 bytes would not be that bad.
>>>
>>> I would tend to agree that it should be possible to configure all 5 mode
>>> bits through the devicetree. What I would propose is as follows.
>>>
>>> If a devicetree node exists, the mode parameter(s?) are required and the
>>> chip is initialised.
>>>
>>> If a devicetree node doesn't exist, it is assumed that the chip has
>>> already been configured (by the BIOS, etc). The mode is read from the
>>> chip to set the visibility of the sysfs attributes. In the worst case, where the
>>> chip has not been configured by another source, it would only be possible
>>> to measure the internal temperature -- but I think this is an acceptable
>>> limitation.
>>>
>> SGTM.
>>
>>> The only case that this does not cover is if the device tree node
>>> exists but the chip is expected to be configured by some other source.
>>> Maybe I am wrong, but I would not expect this to be a terribly common
>>> situation.
>>>
>>> What do you think?
>>>
>> I would not bother about this case. Just make the mode property mandatory.
>
> What do you think about making the devicetree property a list of two integers? Something like
>
> lltc,mode = <7 3>;
>
> which would set mode[2..0]=7 and mode[4..3]=3.
>
I would personally just use a single value for b[4..0]. But that is really up for bikeshedding
(eg should it be <7 3> or <3 7>. I'll leave that up to Rob to decide - he knows better than me
of what makes more sense from a DT perspective.

Guenter

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web