Re: [PATCH] hwmon (pmbus): Add client driver for IR35221
Sam, On Fri, Apr 21, 2017 at 02:25:05PM +1000, Samuel Mendoza-Jonas wrote: > IR35221 is a Digital DC-DC Multiphase Converter > > Signed-off-by: Samuel Mendoza-Jonas> --- > - Tested on a ppc64 system which includes several of these devices. > - This patch re-implements the linear reg2data/data2reg functions from > pmbus-core like some other drivers in order to scale some results. Is > this something that would be better off being made generic for pmbus > drivers to call? > - The resolution of iout0 is apparently configurable between two values, > however the documentation I have access to does not specify how this is > actually configured - currently it is left at the default resolution in > the driver. > > Documentation/hwmon/ir35221 | 87 > drivers/hwmon/pmbus/Kconfig | 11 ++ > drivers/hwmon/pmbus/Makefile | 1 + > drivers/hwmon/pmbus/ir35221.c | 322 > ++ > 4 files changed, 421 insertions(+) > create mode 100644 Documentation/hwmon/ir35221 > create mode 100644 drivers/hwmon/pmbus/ir35221.c Thanks for working on this. Would it be possible to enhance it in a follow up to support an 'inN_target' also? I see this is not documented by the sysfs-interface for hwmon but we likely need support for this. There are voltage slewing operations we do in system manufacturing. Without an hwmon interface for programming the target voltage we're going to have to unbind the device and manually do the i2c operations. Guenter, I mention 'inN_target' to match 'fanN_target'. Do you have any opposition to either formally adding that as an option for voltage readings or adding it to this specific driver? -- Patrick Williams signature.asc Description: Digital signature
Re: [PATCH] hwmon: (ibmpowernv) Add min/max attributes and current sensors
Hello Shilpasri, On 04/21/2017 06:31 AM, Shilpasri G Bhat wrote: > Add support for adding min/max values for the inband sensors copied by > OCC to main memory. And also add current(mA) sensors to the list. > > Signed-off-by: Shilpasri G Bhat> --- > drivers/hwmon/ibmpowernv.c | 55 > -- > 1 file changed, 53 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c > index 6d2e660..1f329fa8 100644 > --- a/drivers/hwmon/ibmpowernv.c > +++ b/drivers/hwmon/ibmpowernv.c > @@ -50,6 +50,7 @@ enum sensors { > TEMP, > POWER_SUPPLY, > POWER_INPUT, > + CURRENT, > MAX_SENSOR_TYPE, > }; > > @@ -65,7 +66,8 @@ enum sensors { > {"fan", "ibm,opal-sensor-cooling-fan"}, > {"temp", "ibm,opal-sensor-amb-temp"}, > {"in", "ibm,opal-sensor-power-supply"}, > - {"power", "ibm,opal-sensor-power"} > + {"power", "ibm,opal-sensor-power"}, > + {"curr"}, /* Follows newer device tree compatible ibm,opal-sensor */ why isn't there a compatible string ? > }; > > struct sensor_data { > @@ -287,6 +289,7 @@ static int populate_attr_groups(struct platform_device > *pdev) > opal = of_find_node_by_path("/ibm,opal/sensors"); > for_each_child_of_node(opal, np) { > const char *label; > + int len; > > if (np->name == NULL) > continue; > @@ -298,10 +301,14 @@ static int populate_attr_groups(struct platform_device > *pdev) > sensor_groups[type].attr_count++; > > /* > - * add a new attribute for labels > + * add attributes for labels, min and max >*/ > if (!of_property_read_string(np, "label", )) > sensor_groups[type].attr_count++; We are negating of_property_read_string() above, but not below. I wonder why ? > + if (of_find_property(np, "sensor-data-min", )) > + sensor_groups[type].attr_count++; > + if (of_find_property(np, "sensor-data-max", )) > + sensor_groups[type].attr_count++; > } > > of_node_put(opal); > @@ -428,6 +435,50 @@ static int create_device_attrs(struct platform_device > *pdev) > pgroups[type]->attrs[sensor_groups[type].attr_count++] = > [count++].dev_attr.attr; > } > + > + if (!of_property_read_u32(np, "sensor-data-max", _id)) { > + switch (type) { > + case POWER_INPUT: > + attr_name = "input_highest"; > + break; > + case TEMP: > + attr_name = "max"; > + break; > + default: > + attr_name = "highest"; > + break; > + } May be we could use a converting routine here ? create_device_attrs() is getting big. > + sdata[count].id = sensor_id; > + sdata[count].type = type; > + sdata[count].hwmon_index = sdata[count - 1].hwmon_index; > + create_hwmon_attr([count], attr_name, > + show_sensor); > + pgroups[type]->attrs[sensor_groups[type].attr_count++] = > + [count++].dev_attr.attr; > + } > + > + if (!of_property_read_u32(np, "sensor-data-min", _id)) { > + switch (type) { > + case POWER_INPUT: > + attr_name = "input_lowest"; > + break; > + case TEMP: > + attr_name = "min"; > + break; > + default: > + attr_name = "lowest"; > + break; > + } same here. Thanks, C. > + sdata[count].id = sensor_id; > + sdata[count].type = type; > + sdata[count].hwmon_index = sdata[count - 1].hwmon_index; > + create_hwmon_attr([count], attr_name, > + show_sensor); > + pgroups[type]->attrs[sensor_groups[type].attr_count++] = > + [count++].dev_attr.attr; > + } > } > > exit_put_node: > -- To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hwmon: ina209: Handled signed registers
On Tue, Apr 18, 2017 at 07:15:50AM -0500, Joe Schaack wrote: > The shunt voltage and current registers are signed 16-bit values so > handle them as such. > > Signed-off-by: Joe Schaack> Reviewed-by: Aaron Sierra Applied. Thanks, Guenter > --- > drivers/hwmon/ina209.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwmon/ina209.c b/drivers/hwmon/ina209.c > index 5378fde..9fa975d 100644 > --- a/drivers/hwmon/ina209.c > +++ b/drivers/hwmon/ina209.c > @@ -117,7 +117,7 @@ static long ina209_from_reg(const u8 reg, const u16 val) > case INA209_SHUNT_VOLTAGE_POS_WARN: > case INA209_SHUNT_VOLTAGE_NEG_WARN: > /* LSB=10 uV. Convert to mV. */ > - return DIV_ROUND_CLOSEST(val, 100); > + return DIV_ROUND_CLOSEST((s16)val, 100); > > case INA209_BUS_VOLTAGE: > case INA209_BUS_VOLTAGE_MAX_PEAK: > @@ -146,7 +146,7 @@ static long ina209_from_reg(const u8 reg, const u16 val) > > case INA209_CURRENT: > /* LSB=1 mA (selected). Is in mA */ > - return val; > + return (s16)val; > } > > /* programmer goofed */ -- To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hwmon: (adt7475) set start bit in probe
The ADT7475 and ADT7476 have the STRT bit cleared by default[1]. Before any monitoring activities the STRT bit needs to be set. Logically this needs to happen before any of the sensors are read so the probe() function seems the best place for it. [1] - https://www.onsemi.com/pub/Collateral/ADT7475-D.PDF Signed-off-by: Chris Packham--- drivers/hwmon/adt7475.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c index fcfa48222145..c803e3c5fcd4 100644 --- a/drivers/hwmon/adt7475.c +++ b/drivers/hwmon/adt7475.c @@ -59,6 +59,8 @@ #define REG_VENDID 0x3E #define REG_DEVID2 0x3F +#define REG_CONFIG10x40 + #define REG_STATUS10x41 #define REG_STATUS20x42 @@ -1371,6 +1373,17 @@ static int adt7475_probe(struct i2c_client *client, for (i = 0; i < ADT7475_PWM_COUNT; i++) adt7475_read_pwm(client, i); + /* Start monitoring */ + switch (chip) { + case adt7475: + case adt7476: + i2c_smbus_write_byte_data(client, REG_CONFIG1, + adt7475_read(REG_CONFIG1) | 0x01); + break; + default: + break; + } + ret = sysfs_create_group(>dev.kobj, _attr_group); if (ret) return ret; -- 2.11.0.24.ge6920cf -- To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hwmon (pmbus): Add client driver for IR35221
On 04/20/2017 09:25 PM, Samuel Mendoza-Jonas wrote: IR35221 is a Digital DC-DC Multiphase Converter Signed-off-by: Samuel Mendoza-Jonas--- - Tested on a ppc64 system which includes several of these devices. - This patch re-implements the linear reg2data/data2reg functions from pmbus-core like some other drivers in order to scale some results. Is this something that would be better off being made generic for pmbus drivers to call? That might make sense. The only other driver is zl6100, or am I missing something ? Trying to understand the code, the data format seems to be linear11 with an added exponent on top of it. Is that correct ? If so, I wonder if we should make that configurable, ie store the additional exponent in R and handle it in the pmbus core. Would that help ? If so, and if you have time, feel free to provide patches the modify the pmbus core code accordingly. - The resolution of iout0 is apparently configurable between two values, however the documentation I have access to does not specify how this is actually configured - currently it is left at the default resolution in the driver. Nothing we can do about that, but it might make sense to add a note somewhere in the driver. Documentation/hwmon/ir35221 | 87 drivers/hwmon/pmbus/Kconfig | 11 ++ drivers/hwmon/pmbus/Makefile | 1 + drivers/hwmon/pmbus/ir35221.c | 322 ++ 4 files changed, 421 insertions(+) create mode 100644 Documentation/hwmon/ir35221 create mode 100644 drivers/hwmon/pmbus/ir35221.c diff --git a/Documentation/hwmon/ir35221 b/Documentation/hwmon/ir35221 new file mode 100644 index ..f7e112752c04 --- /dev/null +++ b/Documentation/hwmon/ir35221 @@ -0,0 +1,87 @@ +Kernel driver ir35221 += + +Supported chips: + * Infinion IR35221 +Prefix: 'ir35221' +Addresses scanned: - +Datasheet: Datasheet is not publicly available. The chip doesn't even publicly exist, which is really annoying :-(. + +Author: Samuel Mendoza-Jonas + + +Description +--- + +IR35221 is a Digital DC-DC Multiphase Converter + + +Usage Notes +--- + +This driver does not probe for PMBus devices. You will have to instantiate +devices explicitly. + +Example: the following commands will load the driver for an IR35221 +at address 0x70 on I2C bus #4: + +# modprobe ir35221 +# echo ir35221 0x70 > /sys/bus/i2c/devices/i2c-4/new_device + + +Sysfs attributes + + +curr1_label"iin" +curr1_inputMeasured input current +curr1_max Maximum current +curr1_max_alarmCurrent high alarm + +curr[2-3]_label"iout[1-2]" +curr[2-3]_inputMeasured output current +curr[2-3]_crit Critical maximum current +curr[2-3]_crit_alarm Current critical high alarm +curr[2-3]_highest Highest output current +curr[2-3]_lowest Lowest output current +curr[2-3]_max Maximum current +curr[2-3]_max_alarmCurrent high alarm + +in1_label "vin" +in1_input Measured input voltage +in1_crit Critical maximum input voltage +in1_crit_alarm Input voltage critical high alarm +in1_highestHighest input voltage +in1_lowest Lowest input voltage +in1_minMinimum input voltage +in1_min_alarm Input voltage low alarm + +in[2-3]_label "vout[1-2]" +in[2-3]_input Measured output voltage +in[2-3]_lcrit Critical minimum output voltage +in[2-3]_lcrit_alarmOutput voltage critical low alarm +in[2-3]_crit Critical maximum output voltage +in[2-3]_crit_alarm Output voltage critical high alarm +in[2-3]_highestHighest output voltage +in[2-3]_lowest Lowest output voltage +in[2-3]_maxMaximum output voltage +in[2-3]_max_alarm Output voltage high alarm +in[2-3]_minMinimum output voltage +in[2-3]_min_alarm Output voltage low alarm + +power1_label "pin" +power1_input Measured input power +power1_alarm Input power high alarm +power1_max Input power limit + +power[2-3]_label "pout[1-2]" +power[2-3]_input Measured output power +power[2-3]_max Output power limit +power[2-3]_max_alarm Output power high alarm + +temp[1-2]_inputMeasured temperature +temp[1-2]_crit Critical high temperature +temp[1-2]_crit_alarm Chip temperature critical high alarm +temp[1-2]_highest Highest temperature +temp[1-2]_lowest Lowest temperature +temp[1-2]_max Maximum temperature +temp[1-2]_max_alarmChip temperature high alarm diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig index cad1229b7e17..88c7d6b116f8 100644 --- a/drivers/hwmon/pmbus/Kconfig +++ b/drivers/hwmon/pmbus/Kconfig @@ -159,4 +159,15 @@ config
Re: [PATCH] hwmon: (ibmpowernv) Add min/max attributes and current sensors
Hi Cedric, On 04/21/2017 05:17 PM, Cédric Le Goater wrote: > Hello Shilpasri, > > On 04/21/2017 06:31 AM, Shilpasri G Bhat wrote: >> Add support for adding min/max values for the inband sensors copied by >> OCC to main memory. And also add current(mA) sensors to the list. >> >> Signed-off-by: Shilpasri G Bhat>> --- >> drivers/hwmon/ibmpowernv.c | 55 >> -- >> 1 file changed, 53 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c >> index 6d2e660..1f329fa8 100644 >> --- a/drivers/hwmon/ibmpowernv.c >> +++ b/drivers/hwmon/ibmpowernv.c >> @@ -50,6 +50,7 @@ enum sensors { >> TEMP, >> POWER_SUPPLY, >> POWER_INPUT, >> +CURRENT, >> MAX_SENSOR_TYPE, >> }; >> >> @@ -65,7 +66,8 @@ enum sensors { >> {"fan", "ibm,opal-sensor-cooling-fan"}, >> {"temp", "ibm,opal-sensor-amb-temp"}, >> {"in", "ibm,opal-sensor-power-supply"}, >> -{"power", "ibm,opal-sensor-power"} >> +{"power", "ibm,opal-sensor-power"}, >> +{"curr"}, /* Follows newer device tree compatible ibm,opal-sensor */ > > why isn't there a compatible string ? > Skiboot exports "ibm,opal-sensor" as compatible string for all the inband sensors. Now if I define that as the compatible string here, then all the sensors would get identified as "curr" type of sensor by the driver. >> }; >> >> struct sensor_data { >> @@ -287,6 +289,7 @@ static int populate_attr_groups(struct platform_device >> *pdev) >> opal = of_find_node_by_path("/ibm,opal/sensors"); >> for_each_child_of_node(opal, np) { >> const char *label; >> +int len; >> >> if (np->name == NULL) >> continue; >> @@ -298,10 +301,14 @@ static int populate_attr_groups(struct platform_device >> *pdev) >> sensor_groups[type].attr_count++; >> >> /* >> - * add a new attribute for labels >> + * add attributes for labels, min and max >> */ >> if (!of_property_read_string(np, "label", )) >> sensor_groups[type].attr_count++; > > We are negating of_property_read_string() above, but not below. > I wonder why ? of_find_property() returns 'struct property *' while of_property_read_string() returns 0 on success. > >> +if (of_find_property(np, "sensor-data-min", )) >> +sensor_groups[type].attr_count++; >> +if (of_find_property(np, "sensor-data-max", )) >> +sensor_groups[type].attr_count++; >> } >> >> of_node_put(opal); >> @@ -428,6 +435,50 @@ static int create_device_attrs(struct platform_device >> *pdev) >> pgroups[type]->attrs[sensor_groups[type].attr_count++] = >> [count++].dev_attr.attr; >> } >> + >> +if (!of_property_read_u32(np, "sensor-data-max", _id)) { >> +switch (type) { >> +case POWER_INPUT: >> +attr_name = "input_highest"; >> +break; >> +case TEMP: >> +attr_name = "max"; >> +break; >> +default: >> +attr_name = "highest"; >> +break; >> +} > > May be we could use a converting routine here ? create_device_attrs() > is getting big. Okay will do. > >> +sdata[count].id = sensor_id; >> +sdata[count].type = type; >> +sdata[count].hwmon_index = sdata[count - 1].hwmon_index; >> +create_hwmon_attr([count], attr_name, >> + show_sensor); >> +pgroups[type]->attrs[sensor_groups[type].attr_count++] = >> +[count++].dev_attr.attr; >> +} >> + >> +if (!of_property_read_u32(np, "sensor-data-min", _id)) { >> +switch (type) { >> +case POWER_INPUT: >> +attr_name = "input_lowest"; >> +break; >> +case TEMP: >> +attr_name = "min"; >> +break; >> +default: >> +attr_name = "lowest"; >> +break; >> +} > > same here. Sure. Thanks and Regards, Shilpa > > Thanks, > > C. >> +sdata[count].id = sensor_id; >> +sdata[count].type = type; >> +sdata[count].hwmon_index = sdata[count - 1].hwmon_index; >> +create_hwmon_attr([count], attr_name, >> + show_sensor); >> +