* [PATCH 1/3] docs: hwmon: (pmbus/ltc2978): Update datasheet URLs to analog.com.
@ 2020-01-28 17:59 Mike Jones
2020-01-28 17:59 ` [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions Mike Jones
2020-01-28 18:00 ` [PATCH 3/3] hwmon: (pmbus/ltc2978): add support for more parts Mike Jones
0 siblings, 2 replies; 9+ messages in thread
From: Mike Jones @ 2020-01-28 17:59 UTC (permalink / raw)
To: linux-hwmon, devicetree, linux-doc, linux-kernel
Cc: linux, jdelvare, robh+dt, corbet, Mike Jones
Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
---
Documentation/hwmon/ltc2978.rst | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/hwmon/ltc2978.rst b/Documentation/hwmon/ltc2978.rst
index 01a24fd..42fd841 100644
--- a/Documentation/hwmon/ltc2978.rst
+++ b/Documentation/hwmon/ltc2978.rst
@@ -9,7 +9,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltc2974
+ Datasheet: https://www.analog.com/en/products/ltc2974
* Linear Technology LTC2975
@@ -17,7 +17,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltc2975
+ Datasheet: https://www.analog.com/en/products/ltc2975
* Linear Technology LTC2977
@@ -25,7 +25,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltc2977
+ Datasheet: https://www.analog.com/en/products/ltc2977
* Linear Technology LTC2978, LTC2978A
@@ -33,9 +33,9 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltc2978
+ Datasheet: https://www.analog.com/en/products/ltc2978
- http://www.linear.com/product/ltc2978a
+ https://www.analog.com/en/products/ltc2978a
* Linear Technology LTC2980
@@ -43,7 +43,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltc2980
+ Datasheet: https://www.analog.com/en/products/ltc2980
* Linear Technology LTC3880
@@ -51,7 +51,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltc3880
+ Datasheet: https://www.analog.com/en/products/ltc3880
* Linear Technology LTC3882
@@ -59,7 +59,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltc3882
+ Datasheet: https://www.analog.com/en/products/ltc3882
* Linear Technology LTC3883
@@ -67,7 +67,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltc3883
+ Datasheet: https://www.analog.com/en/products/ltc3883
* Linear Technology LTC3886
@@ -75,7 +75,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltc3886
+ Datasheet: https://www.analog.com/en/products/ltc3886
* Linear Technology LTC3887
@@ -83,7 +83,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltc3887
+ Datasheet: https://www.analog.com/en/products/ltc3887
* Linear Technology LTM2987
@@ -91,7 +91,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltm2987
+ Datasheet: https://www.analog.com/en/products/ltm2987
* Linear Technology LTM4675
@@ -99,7 +99,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltm4675
+ Datasheet: https://www.analog.com/en/products/ltm4675
* Linear Technology LTM4676
@@ -107,7 +107,7 @@ Supported chips:
Addresses scanned: -
- Datasheet: http://www.linear.com/product/ltm4676
+ Datasheet: https://www.analog.com/en/products/ltm4676
* Analog Devices LTM4686
--
2.7.4
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
2020-01-28 17:59 [PATCH 1/3] docs: hwmon: (pmbus/ltc2978): Update datasheet URLs to analog.com Mike Jones
@ 2020-01-28 17:59 ` Mike Jones
2020-01-28 19:13 ` Guenter Roeck
2020-01-28 18:00 ` [PATCH 3/3] hwmon: (pmbus/ltc2978): add support for more parts Mike Jones
1 sibling, 1 reply; 9+ messages in thread
From: Mike Jones @ 2020-01-28 17:59 UTC (permalink / raw)
To: linux-hwmon, devicetree, linux-doc, linux-kernel
Cc: linux, jdelvare, robh+dt, corbet, Mike Jones
Change 21537dc driver PMBus polling of MFR_COMMON from bits 5/4 to
bits 6/5. This fixs a LTC297X family bug where polling always returns
not busy even when the part is busy. This fixes a LTC388X and
LTM467X bug where polling used PEND and NOT_IN_TRANS, and BUSY was
not polled, which can lead to NACKing of commands. LTC388X and
LTM467X modules now poll BUSY and PEND, increasing reliability by
eliminating NACKing of commands.
Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
---
drivers/hwmon/pmbus/ltc2978.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hwmon/pmbus/ltc2978.c b/drivers/hwmon/pmbus/ltc2978.c
index f01f488..a91ed01 100644
--- a/drivers/hwmon/pmbus/ltc2978.c
+++ b/drivers/hwmon/pmbus/ltc2978.c
@@ -82,8 +82,8 @@ enum chips { ltc2974, ltc2975, ltc2977, ltc2978, ltc2980, ltc3880, ltc3882,
#define LTC_POLL_TIMEOUT 100 /* in milli-seconds */
-#define LTC_NOT_BUSY BIT(5)
-#define LTC_NOT_PENDING BIT(4)
+#define LTC_NOT_BUSY BIT(6)
+#define LTC_NOT_PENDING BIT(5)
/*
* LTC2978 clears peak data whenever the CLEAR_FAULTS command is executed, which
--
2.7.4
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 3/3] hwmon: (pmbus/ltc2978): add support for more parts.
2020-01-28 17:59 [PATCH 1/3] docs: hwmon: (pmbus/ltc2978): Update datasheet URLs to analog.com Mike Jones
2020-01-28 17:59 ` [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions Mike Jones
@ 2020-01-28 18:00 ` Mike Jones
2020-02-06 17:12 ` Rob Herring
1 sibling, 1 reply; 9+ messages in thread
From: Mike Jones @ 2020-01-28 18:00 UTC (permalink / raw)
To: linux-hwmon, devicetree, linux-doc, linux-kernel
Cc: linux, jdelvare, robh+dt, corbet, Mike Jones
LTC2972, LTC2979, LTC3884, LTC3889, LTC7880, LTM4664, LTM4677,
LTM4678, LTM4680, LTM4700.
Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
---
.../devicetree/bindings/hwmon/ltc2978.txt | 22 ++-
Documentation/hwmon/ltc2978.rst | 164 ++++++++++++++++-----
drivers/hwmon/pmbus/Kconfig | 11 +-
drivers/hwmon/pmbus/ltc2978.c | 92 +++++++++++-
4 files changed, 238 insertions(+), 51 deletions(-)
diff --git a/Documentation/devicetree/bindings/hwmon/ltc2978.txt b/Documentation/devicetree/bindings/hwmon/ltc2978.txt
index b428a70..4e7f621 100644
--- a/Documentation/devicetree/bindings/hwmon/ltc2978.txt
+++ b/Documentation/devicetree/bindings/hwmon/ltc2978.txt
@@ -2,20 +2,30 @@ ltc2978
Required properties:
- compatible: should contain one of:
+ * "lltc,ltc2972"
* "lltc,ltc2974"
* "lltc,ltc2975"
* "lltc,ltc2977"
* "lltc,ltc2978"
+ * "lltc,ltc2979"
* "lltc,ltc2980"
* "lltc,ltc3880"
* "lltc,ltc3882"
* "lltc,ltc3883"
+ * "lltc,ltc3884"
* "lltc,ltc3886"
* "lltc,ltc3887"
+ * "lltc,ltc3889"
+ * "lltc,ltc7880"
* "lltc,ltm2987"
+ * "lltc,ltm4664"
* "lltc,ltm4675"
* "lltc,ltm4676"
+ * "lltc,ltm4677"
+ * "lltc,ltm4678"
+ * "lltc,ltm4680"
* "lltc,ltm4686"
+ * "lltc,ltm4700"
- reg: I2C slave address
Optional properties:
@@ -25,13 +35,17 @@ Optional properties:
standard binding for regulators; see regulator.txt.
Valid names of regulators depend on number of supplies supported per device:
+ * ltc2972 vout0 - vout1
* ltc2974, ltc2975 : vout0 - vout3
- * ltc2977, ltc2980, ltm2987 : vout0 - vout7
+ * ltc2977, ltc2979, ltc2980, ltm2987 : vout0 - vout7
* ltc2978 : vout0 - vout7
- * ltc3880, ltc3882, ltc3886 : vout0 - vout1
+ * ltc3880, ltc3882, ltc3884, ltc3886, ltc3887, ltc3889 : vout0 - vout1
+ * ltc7880 : vout0 - vout1
* ltc3883 : vout0
- * ltm4676 : vout0 - vout1
- * ltm4686 : vout0 - vout1
+ * ltm4664 : vout0 - vout1
+ * ltm4675, ltm4676, ltm4677, ltm4678 : vout0 - vout1
+ * ltm4680, ltm4686 : vout0 - vout1
+ * ltm4700 : vout0 - vout1
Example:
ltc2978@5e {
diff --git a/Documentation/hwmon/ltc2978.rst b/Documentation/hwmon/ltc2978.rst
index 42fd841..58838d4 100644
--- a/Documentation/hwmon/ltc2978.rst
+++ b/Documentation/hwmon/ltc2978.rst
@@ -3,6 +3,14 @@ Kernel driver ltc2978
Supported chips:
+ * Linear Technology LTC2972
+
+ Prefix: 'ltc2972'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/ltc2972.html
+
* Linear Technology LTC2974
Prefix: 'ltc2974'
@@ -37,6 +45,14 @@ Supported chips:
https://www.analog.com/en/products/ltc2978a
+ * Linear Technology LTC2979
+
+ Prefix: 'ltc2979'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/ltc2979
+
* Linear Technology LTC2980
Prefix: 'ltc2980'
@@ -69,6 +85,14 @@ Supported chips:
Datasheet: https://www.analog.com/en/products/ltc3883
+ * Linear Technology LTC3884
+
+ Prefix: 'ltc3884'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/ltc3884
+
* Linear Technology LTC3886
Prefix: 'ltc3886'
@@ -85,6 +109,22 @@ Supported chips:
Datasheet: https://www.analog.com/en/products/ltc3887
+ * Linear Technology LTC3889
+
+ Prefix: 'ltc3889'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/ltc3889
+
+ * Linear Technology LTC7880
+
+ Prefix: 'ltc7880'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/ltc7880
+
* Linear Technology LTM2987
Prefix: 'ltm2987'
@@ -93,7 +133,15 @@ Supported chips:
Datasheet: https://www.analog.com/en/products/ltm2987
- * Linear Technology LTM4675
+ * Linear Technology LTM4644
+
+ Prefix: 'ltm4644'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/ltm4644
+
+ * Linear Technology LTM4675
Prefix: 'ltm4675'
@@ -109,6 +157,30 @@ Supported chips:
Datasheet: https://www.analog.com/en/products/ltm4676
+ * Linear Technology LTM4677
+
+ Prefix: 'ltm4677'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/ltm4677
+
+ * Linear Technology LTM4678
+
+ Prefix: 'ltm4678'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/ltm4678
+
+ * Analog Devices LTM4680
+
+ Prefix: 'ltm4680'
+
+ Addresses scanned: -
+
+ Datasheet: http://www.analog.com/ltm4680
+
* Analog Devices LTM4686
Prefix: 'ltm4686'
@@ -117,6 +189,15 @@ Supported chips:
Datasheet: http://www.analog.com/ltm4686
+ * Analog Devices LTM4700
+
+ Prefix: 'ltm4700'
+
+ Addresses scanned: -
+
+ Datasheet: http://www.analog.com/ltm4700
+
+
Author: Guenter Roeck <linux@roeck-us.net>
@@ -166,13 +247,13 @@ in1_min Minimum input voltage.
in1_max Maximum input voltage.
- LTC2974, LTC2975, LTC2977, LTC2980, LTC2978, and
- LTM2987 only.
+ LTC2974, LTC2975, LTC2977, LTC2980, LTC2978,
+ LTC2979 and LTM2987 only.
in1_lcrit Critical minimum input voltage.
- LTC2974, LTC2975, LTC2977, LTC2980, LTC2978, and
- LTM2987 only.
+ LTC2972, LTC2974, LTC2975, LTC2977, LTC2980, LTC2978,
+ LTC2979 and LTM2987 only.
in1_crit Critical maximum input voltage.
@@ -180,17 +261,17 @@ in1_min_alarm Input voltage low alarm.
in1_max_alarm Input voltage high alarm.
- LTC2974, LTC2975, LTC2977, LTC2980, LTC2978, and
- LTM2987 only.
+ LTC2972, LTC2974, LTC2975, LTC2977, LTC2980, LTC2978,
+ LTC2979 and LTM2987 only.
in1_lcrit_alarm Input voltage critical low alarm.
- LTC2974, LTC2975, LTC2977, LTC2980, LTC2978, and
- LTM2987 only.
+ LTC2972, LTC2974, LTC2975, LTC2977, LTC2980, LTC2978,
+ LTC2979 and LTM2987 only.
in1_crit_alarm Input voltage critical high alarm.
in1_lowest Lowest input voltage.
- LTC2974, LTC2975, LTC2977, LTC2980, LTC2978, and
+ LTC2972, LTC2974, LTC2975, LTC2977, LTC2980, LTC2978, and
LTM2987 only.
in1_highest Highest input voltage.
@@ -198,11 +279,13 @@ in1_reset_history Reset input voltage history.
in[N]_label "vout[1-8]".
+ - LTC2972: N=2-3
- LTC2974, LTC2975: N=2-5
- - LTC2977, LTC2980, LTM2987: N=2-9
+ - LTC2977, LTC2979, LTC2980, LTM2987: N=2-9
- LTC2978: N=2-9
- - LTC3880, LTC3882, LTC23886 LTC3887, LTM4675, LTM4676:
- N=2-3
+ - LTC3880, LTC3882, LTC3884, LTC23886 LTC3887, LTC3889,
+ LTC7880, LTM4644, LTM4675, LTM4676, LTM4677, LTM4678,
+ LTM4680, LTM4700: N=2-3
- LTC3883: N=2
in[N]_input Measured output voltage.
@@ -226,7 +309,7 @@ in[N]_crit_alarm Output voltage critical high alarm.
in[N]_lowest Lowest output voltage.
- LTC2974, LTC2975,and LTC2978 only.
+ LTC2972, LTC2974, LTC2975,and LTC2978 only.
in[N]_highest Highest output voltage.
@@ -234,20 +317,24 @@ in[N]_reset_history Reset output voltage history.
temp[N]_input Measured temperature.
+ - On LTC2972, temp[1-2] report external temperatures,
+ and temp 3 reports the chip temperature.
- On LTC2974 and LTC2975, temp[1-4] report external
temperatures, and temp5 reports the chip temperature.
- - On LTC2977, LTC2980, LTC2978, and LTM2987, only one
- temperature measurement is supported and reports
- the chip temperature.
- - On LTC3880, LTC3882, LTC3887, LTM4675, and LTM4676,
- temp1 and temp2 report external temperatures, and
- temp3 reports the chip temperature.
+ - On LTC2977, LTC2979, LTC2980, LTC2978, and LTM2987,
+ only one temperature measurement is supported and
+ reports the chip temperature.
+ - On LTC3880, LTC3882, LTC3886, LTC3887, LTC3889,
+ LTM4664, LTM4675, LTM4676, LTM4677, LTM4678, LTM4680,
+ and LTM4700, temp1 and temp2 report external
+ temperatures, and temp3 reports the chip temperature.
- On LTC3883, temp1 reports an external temperature,
and temp2 reports the chip temperature.
temp[N]_min Mimimum temperature.
- LTC2974, LCT2977, LTM2980, LTC2978, and LTM2987 only.
+ LTC2972, LTC2974, LCT2977, LTM2980, LTC2978,
+ LTC2979, and LTM2987 only.
temp[N]_max Maximum temperature.
@@ -257,8 +344,8 @@ temp[N]_crit Critical high temperature.
temp[N]_min_alarm Temperature low alarm.
- LTC2974, LTC2975, LTC2977, LTM2980, LTC2978, and
- LTM2987 only.
+ LTC2972, LTC2974, LTC2975, LTC2977, LTM2980, LTC2978,
+ LTC2979, and LTM2987 only.
temp[N]_max_alarm Temperature high alarm.
@@ -269,8 +356,8 @@ temp[N]_crit_alarm Temperature critical high alarm.
temp[N]_lowest Lowest measured temperature.
- - LTC2974, LTC2975, LTC2977, LTM2980, LTC2978, and
- LTM2987 only.
+ - LTC2972, LTC2974, LTC2975, LTC2977, LTM2980, LTC2978,
+ LTC2979, and LTM2987 only.
- Not supported for chip temperature sensor on LTC2974
and LTC2975.
@@ -290,19 +377,22 @@ power1_input Measured input power.
power[N]_label "pout[1-4]".
+ - LTC2972: N=1-2
- LTC2974, LTC2975: N=1-4
- - LTC2977, LTC2980, LTM2987: Not supported
+ - LTC2977, LTC2979, LTC2980, LTM2987: Not supported
- LTC2978: Not supported
- - LTC3880, LTC3882, LTC3886, LTC3887, LTM4675, LTM4676:
- N=1-2
+ - LTC3880, LTC3882, LTC3884, LTC3886, LTC3887, LTC3889,
+ LTM4664, LTM4675, LTM4676, LTM4677, LTM4678, LTM4680,
+ LTM4700: N=1-2
- LTC3883: N=2
power[N]_input Measured output power.
curr1_label "iin".
- LTC3880, LTC3883, LTC3886, LTC3887, LTM4675,
- and LTM4676 only.
+ LTC3880, LTC3883, LTC3884, LTC3886, LTC3887, LTC3889,
+ LTM4644, LTM4675, LTM4676, LTM4677, LTM4678, LTM4680,
+ and LTM4700 only.
curr1_input Measured input current.
@@ -320,11 +410,13 @@ curr1_reset_history Reset input current history.
curr[N]_label "iout[1-4]".
+ - LTC2972: N-1-2
- LTC2974, LTC2975: N=1-4
- - LTC2977, LTC2980, LTM2987: not supported
+ - LTC2977, LTC2979, LTC2980, LTM2987: not supported
- LTC2978: not supported
- - LTC3880, LTC3882, LTC3886, LTC3887, LTM4675, LTM4676:
- N=2-3
+ - LTC3880, LTC3882, LTC3884, LTC3886, LTC3887, LTC3889,
+ LTM4664, LTM4675, LTM4676, LTM4677, LTM4678, LTM4680,
+ LTM4700: N=2-3
- LTC3883: N=2
curr[N]_input Measured output current.
@@ -335,7 +427,7 @@ curr[N]_crit Critical high output current.
curr[N]_lcrit Critical low output current.
- LTC2974 and LTC2975 only.
+ LTC2972, LTC2974 and LTC2975 only.
curr[N]_max_alarm Output current high alarm.
@@ -343,11 +435,11 @@ curr[N]_crit_alarm Output current critical high alarm.
curr[N]_lcrit_alarm Output current critical low alarm.
- LTC2974 and LTC2975 only.
+ LTC2972, LTC2974 and LTC2975 only.
curr[N]_lowest Lowest output current.
- LTC2974 and LTC2975 only.
+ LTC2972, LTC2974 and LTC2975 only.
curr[N]_highest Highest output current.
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 5985997..92f26f3 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -113,8 +113,8 @@ config SENSORS_LTC2978
tristate "Linear Technologies LTC2978 and compatibles"
help
If you say yes here you get hardware monitoring support for Linear
- Technology LTC2974, LTC2975, LTC2977, LTC2978, LTC2980, LTC3880,
- LTC3883, LTC3886, LTC3887, LTCM2987, LTM4675, and LTM4676.
+ Technology LTC2972, LTC2974, LTC2975, LTC2977, LTC2978, LTC2979,
+ LTC2980, and LTM2987.
This driver can also be built as a module. If so, the module will
be called ltc2978.
@@ -123,9 +123,10 @@ config SENSORS_LTC2978_REGULATOR
bool "Regulator support for LTC2978 and compatibles"
depends on SENSORS_LTC2978 && REGULATOR
help
- If you say yes here you get regulator support for Linear
- Technology LTC2974, LTC2977, LTC2978, LTC3880, LTC3883, LTM4676
- and LTM4686.
+ If you say yes here you get regulator support for Linear Technology
+ LTC3880, LTC3883, LTC3884, LTC3886, LTC3887, LTC3889, LTC7880,
+ LTM4644, LTM4675, LTM4676, LTM4677, LTM4678, LTM4680, LTM4686,
+ and LTM4700.
config SENSORS_LTC3815
tristate "Linear Technologies LTC3815"
diff --git a/drivers/hwmon/pmbus/ltc2978.c b/drivers/hwmon/pmbus/ltc2978.c
index a91ed01..8f619d0 100644
--- a/drivers/hwmon/pmbus/ltc2978.c
+++ b/drivers/hwmon/pmbus/ltc2978.c
@@ -19,8 +19,10 @@
#include <linux/regulator/driver.h>
#include "pmbus.h"
-enum chips { ltc2974, ltc2975, ltc2977, ltc2978, ltc2980, ltc3880, ltc3882,
- ltc3883, ltc3886, ltc3887, ltm2987, ltm4675, ltm4676, ltm4686 };
+enum chips { ltc2972, ltc2974, ltc2975, ltc2977, ltc2978, ltc2979, ltc2980, /* Managers */
+ ltc3880, ltc3882, ltc3883, ltc3884, ltc3886, ltc3887, ltc3889, ltc7880, /* Controllers */
+ ltm2987, ltm4664, ltm4675, ltm4676, ltm4677, ltm4678, ltm4680, ltm4686, ltm4700 /* Modules */
+};
/* Common for all chips */
#define LTC2978_MFR_VOUT_PEAK 0xdd
@@ -43,9 +45,10 @@ enum chips { ltc2974, ltc2975, ltc2977, ltc2978, ltc2980, ltc3880, ltc3882,
#define LTC3880_MFR_CLEAR_PEAKS 0xe3
#define LTC3880_MFR_TEMPERATURE2_PEAK 0xf4
-/* LTC3883 and LTC3886 only */
+/* LTC3883, LTC3884, LTC3886, LTC3889 and LTC7880 only */
#define LTC3883_MFR_IIN_PEAK 0xe1
+
/* LTC2975 only */
#define LTC2975_MFR_IIN_PEAK 0xc4
#define LTC2975_MFR_IIN_MIN 0xc5
@@ -54,27 +57,41 @@ enum chips { ltc2974, ltc2975, ltc2977, ltc2978, ltc2980, ltc3880, ltc3882,
#define LTC2978_ID_MASK 0xfff0
+#define LTC2972_ID 0x0310
#define LTC2974_ID 0x0210
#define LTC2975_ID 0x0220
#define LTC2977_ID 0x0130
#define LTC2978_ID_REV1 0x0110 /* Early revision */
#define LTC2978_ID_REV2 0x0120
+#define LTC2979_ID_A 0x8060
+#define LTC2979_ID_B 0x8070
#define LTC2980_ID_A 0x8030 /* A/B for two die IDs */
#define LTC2980_ID_B 0x8040
#define LTC3880_ID 0x4020
#define LTC3882_ID 0x4200
#define LTC3882_ID_D1 0x4240 /* Dash 1 */
#define LTC3883_ID 0x4300
+#define LTC3884_ID 0x4C00
#define LTC3886_ID 0x4600
#define LTC3887_ID 0x4700
#define LTM2987_ID_A 0x8010 /* A/B for two die IDs */
#define LTM2987_ID_B 0x8020
+#define LTC3889_ID 0x4900
+#define LTC7880_ID 0x49E0
+#define LTM4664_ID 0x4120
#define LTM4675_ID 0x47a0
#define LTM4676_ID_REV1 0x4400
#define LTM4676_ID_REV2 0x4480
#define LTM4676A_ID 0x47e0
+#define LTM4677_ID_REV1 0x47B0
+#define LTM4677_ID_REV2 0x47D0
+#define LTM4678_ID_REV1 0x4100
+#define LTM4678_ID_REV2 0x4110
+#define LTM4680_ID 0x4140
#define LTM4686_ID 0x4770
+#define LTM4700_ID 0x4130
+#define LTC2972_NUM_PAGES 2
#define LTC2974_NUM_PAGES 4
#define LTC2978_NUM_PAGES 8
#define LTC3880_NUM_PAGES 2
@@ -492,20 +509,30 @@ static int ltc2978_write_word_data(struct i2c_client *client, int page,
}
static const struct i2c_device_id ltc2978_id[] = {
+ {"ltc2972", ltc2972},
{"ltc2974", ltc2974},
{"ltc2975", ltc2975},
{"ltc2977", ltc2977},
{"ltc2978", ltc2978},
+ {"ltc2979", ltc2979},
{"ltc2980", ltc2980},
{"ltc3880", ltc3880},
{"ltc3882", ltc3882},
{"ltc3883", ltc3883},
+ {"ltc3884", ltc3884},
{"ltc3886", ltc3886},
{"ltc3887", ltc3887},
+ {"ltc3889", ltc3889},
+ {"ltc7880", ltc7880},
{"ltm2987", ltm2987},
+ {"ltm4664", ltm4664},
{"ltm4675", ltm4675},
{"ltm4676", ltm4676},
+ {"ltm4677", ltm4677},
+ {"ltm4678", ltm4678},
+ {"ltm4680", ltm4680},
{"ltm4686", ltm4686},
+ {"ltm4700", ltm4700},
{}
};
MODULE_DEVICE_TABLE(i2c, ltc2978_id);
@@ -555,7 +582,9 @@ static int ltc2978_get_id(struct i2c_client *client)
chip_id &= LTC2978_ID_MASK;
- if (chip_id == LTC2974_ID)
+ if (chip_id == LTC2972_ID)
+ return ltc2972;
+ else if (chip_id == LTC2974_ID)
return ltc2974;
else if (chip_id == LTC2975_ID)
return ltc2975;
@@ -563,6 +592,8 @@ static int ltc2978_get_id(struct i2c_client *client)
return ltc2977;
else if (chip_id == LTC2978_ID_REV1 || chip_id == LTC2978_ID_REV2)
return ltc2978;
+ else if (chip_id == LTC2979_ID_A || chip_id == LTC2979_ID_B)
+ return ltc2979;
else if (chip_id == LTC2980_ID_A || chip_id == LTC2980_ID_B)
return ltc2980;
else if (chip_id == LTC3880_ID)
@@ -571,19 +602,34 @@ static int ltc2978_get_id(struct i2c_client *client)
return ltc3882;
else if (chip_id == LTC3883_ID)
return ltc3883;
+ else if (chip_id == LTC3884_ID)
+ return ltc3884;
else if (chip_id == LTC3886_ID)
return ltc3886;
else if (chip_id == LTC3887_ID)
return ltc3887;
+ else if (chip_id == LTC3889_ID)
+ return ltc3889;
+ else if (chip_id == LTC7880_ID)
+ return ltc7880;
else if (chip_id == LTM2987_ID_A || chip_id == LTM2987_ID_B)
return ltm2987;
+ else if (chip_id == LTM4664_ID)
+ return ltm4664;
else if (chip_id == LTM4675_ID)
return ltm4675;
- else if (chip_id == LTM4676_ID_REV1 || chip_id == LTM4676_ID_REV2 ||
- chip_id == LTM4676A_ID)
+ else if (chip_id == LTM4676_ID_REV1 || chip_id == LTM4676_ID_REV2 || chip_id == LTM4676A_ID)
return ltm4676;
+ else if (chip_id == LTM4677_ID_REV1 || chip_id == LTM4677_ID_REV2)
+ return ltm4677;
+ else if (chip_id == LTM4678_ID_REV1 || chip_id == LTM4678_ID_REV2)
+ return ltm4678;
+ else if (chip_id == LTM4680_ID)
+ return ltm4680;
else if (chip_id == LTM4686_ID)
return ltm4686;
+ else if (chip_id == LTM4700_ID)
+ return ltm4700;
dev_err(&client->dev, "Unsupported chip ID 0x%x\n", chip_id);
return -ENODEV;
@@ -637,6 +683,19 @@ static int ltc2978_probe(struct i2c_client *client,
data->temp2_max = 0x7c00;
switch (data->id) {
+ case ltc2972:
+ info->read_word_data = ltc2975_read_word_data;
+ info->pages = LTC2972_NUM_PAGES;
+ info->func[0] = PMBUS_HAVE_IIN | PMBUS_HAVE_PIN
+ | PMBUS_HAVE_VIN | PMBUS_HAVE_STATUS_INPUT
+ | PMBUS_HAVE_TEMP2;
+ for (i = 0; i < info->pages; i++) {
+ info->func[i] |= PMBUS_HAVE_VOUT
+ | PMBUS_HAVE_STATUS_VOUT | PMBUS_HAVE_POUT
+ | PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP
+ | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT;
+ }
+ break;
case ltc2974:
info->read_word_data = ltc2974_read_word_data;
info->pages = LTC2974_NUM_PAGES;
@@ -662,8 +721,10 @@ static int ltc2978_probe(struct i2c_client *client,
| PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT;
}
break;
+
case ltc2977:
case ltc2978:
+ case ltc2979:
case ltc2980:
case ltm2987:
info->read_word_data = ltc2978_read_word_data;
@@ -680,6 +741,7 @@ static int ltc2978_probe(struct i2c_client *client,
case ltc3887:
case ltm4675:
case ltm4676:
+ case ltm4677:
case ltm4686:
data->features |= FEAT_CLEAR_PEAKS | FEAT_NEEDS_POLLING;
info->read_word_data = ltc3880_read_word_data;
@@ -721,7 +783,14 @@ static int ltc2978_probe(struct i2c_client *client,
| PMBUS_HAVE_PIN | PMBUS_HAVE_POUT | PMBUS_HAVE_TEMP
| PMBUS_HAVE_TEMP2 | PMBUS_HAVE_STATUS_TEMP;
break;
+ case ltc3884:
case ltc3886:
+ case ltc3889:
+ case ltc7880:
+ case ltm4664:
+ case ltm4678:
+ case ltm4680:
+ case ltm4700:
data->features |= FEAT_CLEAR_PEAKS | FEAT_NEEDS_POLLING;
info->read_word_data = ltc3883_read_word_data;
info->pages = LTC3880_NUM_PAGES;
@@ -752,22 +821,33 @@ static int ltc2978_probe(struct i2c_client *client,
return pmbus_do_probe(client, id, info);
}
+
#ifdef CONFIG_OF
static const struct of_device_id ltc2978_of_match[] = {
+ { .compatible = "lltc,ltc2972" },
{ .compatible = "lltc,ltc2974" },
{ .compatible = "lltc,ltc2975" },
{ .compatible = "lltc,ltc2977" },
{ .compatible = "lltc,ltc2978" },
+ { .compatible = "lltc,ltc2979" },
{ .compatible = "lltc,ltc2980" },
{ .compatible = "lltc,ltc3880" },
{ .compatible = "lltc,ltc3882" },
{ .compatible = "lltc,ltc3883" },
+ { .compatible = "lltc,ltc3884" },
{ .compatible = "lltc,ltc3886" },
{ .compatible = "lltc,ltc3887" },
+ { .compatible = "lltc,ltc3889" },
+ { .compatible = "lltc,ltc7880" },
{ .compatible = "lltc,ltm2987" },
+ { .compatible = "lltc,ltm4664" },
{ .compatible = "lltc,ltm4675" },
{ .compatible = "lltc,ltm4676" },
+ { .compatible = "lltc,ltm4677" },
+ { .compatible = "lltc,ltm4678" },
+ { .compatible = "lltc,ltm4680" },
{ .compatible = "lltc,ltm4686" },
+ { .compatible = "lltc,ltm4700" },
{ }
};
MODULE_DEVICE_TABLE(of, ltc2978_of_match);
--
2.7.4
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
2020-01-28 17:59 ` [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions Mike Jones
@ 2020-01-28 19:13 ` Guenter Roeck
2020-01-28 21:16 ` Jones, Michael-A1
0 siblings, 1 reply; 9+ messages in thread
From: Guenter Roeck @ 2020-01-28 19:13 UTC (permalink / raw)
To: Mike Jones
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, jdelvare,
robh+dt, corbet
On Tue, Jan 28, 2020 at 10:59:59AM -0700, Mike Jones wrote:
> Change 21537dc driver PMBus polling of MFR_COMMON from bits 5/4 to
> bits 6/5. This fixs a LTC297X family bug where polling always returns
> not busy even when the part is busy. This fixes a LTC388X and
> LTM467X bug where polling used PEND and NOT_IN_TRANS, and BUSY was
> not polled, which can lead to NACKing of commands. LTC388X and
> LTM467X modules now poll BUSY and PEND, increasing reliability by
> eliminating NACKing of commands.
>
> Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
Fixes: e04d1ce9bbb49 ("hwmon: (ltc2978) Add polling for chips requiring it")
> ---
> drivers/hwmon/pmbus/ltc2978.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/pmbus/ltc2978.c b/drivers/hwmon/pmbus/ltc2978.c
> index f01f488..a91ed01 100644
> --- a/drivers/hwmon/pmbus/ltc2978.c
> +++ b/drivers/hwmon/pmbus/ltc2978.c
> @@ -82,8 +82,8 @@ enum chips { ltc2974, ltc2975, ltc2977, ltc2978, ltc2980, ltc3880, ltc3882,
>
> #define LTC_POLL_TIMEOUT 100 /* in milli-seconds */
>
> -#define LTC_NOT_BUSY BIT(5)
> -#define LTC_NOT_PENDING BIT(4)
> +#define LTC_NOT_BUSY BIT(6)
> +#define LTC_NOT_PENDING BIT(5)
>
In ltc_wait_ready(), we have:
/*
* LTC3883 does not support LTC_NOT_PENDING, even though
* the datasheet claims that it does.
*/
mask = LTC_NOT_BUSY;
if (data->id != ltc3883)
mask |= LTC_NOT_PENDING;
The semantics of this code is now different: It means that on
LTC3883 only bit 6 is checked; previously, it was bit 5. I agree
that the above change makes sense, but it doesn't seem correct
to drop the check for bit 5 on LTC3883. Maybe remove the if() above
and always check for bit 5 and 6 ? Or should bit 4 be checked
on parts other than LTC3883 ?
#define LTC_NOT_TRANSITIONING BIT(4)
...
mask = LTC_NOT_BUSY | LTC_NOT_PENDING;
if (data->id != ltc3883)
mask |= LTC_NOT_TRANSITIONING;
Thanks,
Guenter
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
2020-01-28 19:13 ` Guenter Roeck
@ 2020-01-28 21:16 ` Jones, Michael-A1
2020-01-28 21:31 ` Guenter Roeck
0 siblings, 1 reply; 9+ messages in thread
From: Jones, Michael-A1 @ 2020-01-28 21:16 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, jdelvare,
robh+dt, corbet
Guenter,
The decision to not poll PEND was based on some other non-driver code based on /dev/i2c that looked like this:
// Set to 0 for LTC3883 which does not support PEND
#define USE_PEND 1
#define NOT_BUSY 1 << 6
#define NOT_TRANS 1 << 4
#if (USE_PEND)
#define NOT_PENDING 1 << 5
#else
#define NOT_PENDING 0
#endif
My recollection is that came from the datasheet, many years ago.
I talked to the designer, and if the above is correct, it has not been correct since 2012. The designer was not interested in researching artifacts that far back in history. So we know it has been in the part for at least 8 years.
There seems to be two choices:
A) Leave it as is
B) Poll the PEND bit and possibly break compatibility on ancient hardware
Generally, unused status bits in this kind are high when reserved or not used. That is good for polling.
The shipping volume of LTC3888 has always been very low compared to other parts, so exposure is very small, certainly Cisco/Juniper type companies would not be effected.
I would feel ok with polling PEND on this part. Let me know your opinion.
On a related matter, bit 4 is asserted low when the output is changing value. Hwmon cannot cause this because it only performs telemetry.
A user application could change VOUT and cause this to happen. Telemetry would reflect the last measured value from a 100ms internal polling loop, which may be a before, after, or during value. I have always judged that checking this bit has no value, and it can be problematic. If the part is set to have a very long transition rate, like 5 seconds, this would hang the call for a long time. That seemed bad to me, and is why I did not poll this bit.
Mike
-----Original Message-----
From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
Sent: Tuesday, January 28, 2020 12:13 PM
To: Jones, Michael-A1 <Michael-A1.Jones@analog.com>
Cc: linux-hwmon@vger.kernel.org; devicetree@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; jdelvare@suse.com; robh+dt@kernel.org; corbet@lwn.net
Subject: Re: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
[External]
On Tue, Jan 28, 2020 at 10:59:59AM -0700, Mike Jones wrote:
> Change 21537dc driver PMBus polling of MFR_COMMON from bits 5/4 to
> bits 6/5. This fixs a LTC297X family bug where polling always returns
> not busy even when the part is busy. This fixes a LTC388X and LTM467X
> bug where polling used PEND and NOT_IN_TRANS, and BUSY was not polled,
> which can lead to NACKing of commands. LTC388X and LTM467X modules now
> poll BUSY and PEND, increasing reliability by eliminating NACKing of
> commands.
>
> Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
Fixes: e04d1ce9bbb49 ("hwmon: (ltc2978) Add polling for chips requiring it")
> ---
> drivers/hwmon/pmbus/ltc2978.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/pmbus/ltc2978.c
> b/drivers/hwmon/pmbus/ltc2978.c index f01f488..a91ed01 100644
> --- a/drivers/hwmon/pmbus/ltc2978.c
> +++ b/drivers/hwmon/pmbus/ltc2978.c
> @@ -82,8 +82,8 @@ enum chips { ltc2974, ltc2975, ltc2977, ltc2978,
> ltc2980, ltc3880, ltc3882,
>
> #define LTC_POLL_TIMEOUT 100 /* in milli-seconds */
>
> -#define LTC_NOT_BUSY BIT(5)
> -#define LTC_NOT_PENDING BIT(4)
> +#define LTC_NOT_BUSY BIT(6)
> +#define LTC_NOT_PENDING BIT(5)
>
In ltc_wait_ready(), we have:
/*
* LTC3883 does not support LTC_NOT_PENDING, even though
* the datasheet claims that it does.
*/
mask = LTC_NOT_BUSY;
if (data->id != ltc3883)
mask |= LTC_NOT_PENDING;
The semantics of this code is now different: It means that on
LTC3883 only bit 6 is checked; previously, it was bit 5. I agree that the above change makes sense, but it doesn't seem correct to drop the check for bit 5 on LTC3883. Maybe remove the if() above and always check for bit 5 and 6 ? Or should bit 4 be checked on parts other than LTC3883 ?
#define LTC_NOT_TRANSITIONING BIT(4)
...
mask = LTC_NOT_BUSY | LTC_NOT_PENDING;
if (data->id != ltc3883)
mask |= LTC_NOT_TRANSITIONING;
Thanks,
Guenter
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
2020-01-28 21:16 ` Jones, Michael-A1
@ 2020-01-28 21:31 ` Guenter Roeck
2020-01-28 21:35 ` Jones, Michael-A1
0 siblings, 1 reply; 9+ messages in thread
From: Guenter Roeck @ 2020-01-28 21:31 UTC (permalink / raw)
To: Jones, Michael-A1
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, jdelvare,
robh+dt, corbet
On Tue, Jan 28, 2020 at 09:16:39PM +0000, Jones, Michael-A1 wrote:
> Guenter,
>
> The decision to not poll PEND was based on some other non-driver code based on /dev/i2c that looked like this:
>
> // Set to 0 for LTC3883 which does not support PEND
> #define USE_PEND 1
>
> #define NOT_BUSY 1 << 6
> #define NOT_TRANS 1 << 4
> #if (USE_PEND)
> #define NOT_PENDING 1 << 5
> #else
> #define NOT_PENDING 0
> #endif
>
> My recollection is that came from the datasheet, many years ago.
>
> I talked to the designer, and if the above is correct, it has not been correct since 2012. The designer was not interested in researching artifacts that far back in history. So we know it has been in the part for at least 8 years.
>
> There seems to be two choices:
>
> A) Leave it as is
> B) Poll the PEND bit and possibly break compatibility on ancient hardware
>
> Generally, unused status bits in this kind are high when reserved or not used. That is good for polling.
>
> The shipping volume of LTC3888 has always been very low compared to other parts, so exposure is very small, certainly Cisco/Juniper type companies would not be effected.
>
I assume you mean LTC3883, not LTC3888.
> I would feel ok with polling PEND on this part. Let me know your opinion.
>
> On a related matter, bit 4 is asserted low when the output is changing value. Hwmon cannot cause this because it only performs telemetry.
>
> A user application could change VOUT and cause this to happen. Telemetry would reflect the last measured value from a 100ms internal polling loop, which may be a before, after, or during value. I have always judged that checking this bit has no value, and it can be problematic. If the part is set to have a very long transition rate, like 5 seconds, this would hang the call for a long time. That seemed bad to me, and is why I did not poll this bit.
>
Your call, really. My major concern was that bit 5 is no longer polled
on LTC3883. From the above, it looks like it actually _is_ the pending
bit (5) that isn't supported on LTC3883. With that in mind, I'll apply
the series as-is and add the Fixes: tag myself; no need to resend.
Thanks,
Guenter
> Mike
>
> -----Original Message-----
> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> Sent: Tuesday, January 28, 2020 12:13 PM
> To: Jones, Michael-A1 <Michael-A1.Jones@analog.com>
> Cc: linux-hwmon@vger.kernel.org; devicetree@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; jdelvare@suse.com; robh+dt@kernel.org; corbet@lwn.net
> Subject: Re: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
>
> [External]
>
> On Tue, Jan 28, 2020 at 10:59:59AM -0700, Mike Jones wrote:
> > Change 21537dc driver PMBus polling of MFR_COMMON from bits 5/4 to
> > bits 6/5. This fixs a LTC297X family bug where polling always returns
> > not busy even when the part is busy. This fixes a LTC388X and LTM467X
> > bug where polling used PEND and NOT_IN_TRANS, and BUSY was not polled,
> > which can lead to NACKing of commands. LTC388X and LTM467X modules now
> > poll BUSY and PEND, increasing reliability by eliminating NACKing of
> > commands.
> >
> > Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
>
> Fixes: e04d1ce9bbb49 ("hwmon: (ltc2978) Add polling for chips requiring it")
>
> > ---
> > drivers/hwmon/pmbus/ltc2978.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hwmon/pmbus/ltc2978.c
> > b/drivers/hwmon/pmbus/ltc2978.c index f01f488..a91ed01 100644
> > --- a/drivers/hwmon/pmbus/ltc2978.c
> > +++ b/drivers/hwmon/pmbus/ltc2978.c
> > @@ -82,8 +82,8 @@ enum chips { ltc2974, ltc2975, ltc2977, ltc2978,
> > ltc2980, ltc3880, ltc3882,
> >
> > #define LTC_POLL_TIMEOUT 100 /* in milli-seconds */
> >
> > -#define LTC_NOT_BUSY BIT(5)
> > -#define LTC_NOT_PENDING BIT(4)
> > +#define LTC_NOT_BUSY BIT(6)
> > +#define LTC_NOT_PENDING BIT(5)
> >
>
> In ltc_wait_ready(), we have:
>
> /*
> * LTC3883 does not support LTC_NOT_PENDING, even though
> * the datasheet claims that it does.
> */
> mask = LTC_NOT_BUSY;
> if (data->id != ltc3883)
> mask |= LTC_NOT_PENDING;
>
> The semantics of this code is now different: It means that on
> LTC3883 only bit 6 is checked; previously, it was bit 5. I agree that the above change makes sense, but it doesn't seem correct to drop the check for bit 5 on LTC3883. Maybe remove the if() above and always check for bit 5 and 6 ? Or should bit 4 be checked on parts other than LTC3883 ?
>
> #define LTC_NOT_TRANSITIONING BIT(4)
> ...
> mask = LTC_NOT_BUSY | LTC_NOT_PENDING;
> if (data->id != ltc3883)
> mask |= LTC_NOT_TRANSITIONING;
>
> Thanks,
> Guenter
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
2020-01-28 21:31 ` Guenter Roeck
@ 2020-01-28 21:35 ` Jones, Michael-A1
2020-01-28 22:38 ` Guenter Roeck
0 siblings, 1 reply; 9+ messages in thread
From: Jones, Michael-A1 @ 2020-01-28 21:35 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, jdelvare,
robh+dt, corbet
Guentar,
Yes, LTC3883. Slip of the finger.
I am happy as is. If LTC3883 starts selling like hotcakes, I'll update it later.
This is my first attempt at doing things the linux way, so if you see something I should do different, let me know. I left off Tested-by, assuming that Signed-off-by was good enough. But I do test the changes using a DLN-2 and demo boards.
Mike
-----Original Message-----
From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
Sent: Tuesday, January 28, 2020 2:31 PM
To: Jones, Michael-A1 <Michael-A1.Jones@analog.com>
Cc: linux-hwmon@vger.kernel.org; devicetree@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; jdelvare@suse.com; robh+dt@kernel.org; corbet@lwn.net
Subject: Re: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
[External]
On Tue, Jan 28, 2020 at 09:16:39PM +0000, Jones, Michael-A1 wrote:
> Guenter,
>
> The decision to not poll PEND was based on some other non-driver code based on /dev/i2c that looked like this:
>
> // Set to 0 for LTC3883 which does not support PEND
> #define USE_PEND 1
>
> #define NOT_BUSY 1 << 6
> #define NOT_TRANS 1 << 4
> #if (USE_PEND)
> #define NOT_PENDING 1 << 5
> #else
> #define NOT_PENDING 0
> #endif
>
> My recollection is that came from the datasheet, many years ago.
>
> I talked to the designer, and if the above is correct, it has not been correct since 2012. The designer was not interested in researching artifacts that far back in history. So we know it has been in the part for at least 8 years.
>
> There seems to be two choices:
>
> A) Leave it as is
> B) Poll the PEND bit and possibly break compatibility on ancient
> hardware
>
> Generally, unused status bits in this kind are high when reserved or not used. That is good for polling.
>
> The shipping volume of LTC3888 has always been very low compared to other parts, so exposure is very small, certainly Cisco/Juniper type companies would not be effected.
>
I assume you mean LTC3883, not LTC3888.
> I would feel ok with polling PEND on this part. Let me know your opinion.
>
> On a related matter, bit 4 is asserted low when the output is changing value. Hwmon cannot cause this because it only performs telemetry.
>
> A user application could change VOUT and cause this to happen. Telemetry would reflect the last measured value from a 100ms internal polling loop, which may be a before, after, or during value. I have always judged that checking this bit has no value, and it can be problematic. If the part is set to have a very long transition rate, like 5 seconds, this would hang the call for a long time. That seemed bad to me, and is why I did not poll this bit.
>
Your call, really. My major concern was that bit 5 is no longer polled on LTC3883. From the above, it looks like it actually _is_ the pending bit (5) that isn't supported on LTC3883. With that in mind, I'll apply the series as-is and add the Fixes: tag myself; no need to resend.
Thanks,
Guenter
> Mike
>
> -----Original Message-----
> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> Sent: Tuesday, January 28, 2020 12:13 PM
> To: Jones, Michael-A1 <Michael-A1.Jones@analog.com>
> Cc: linux-hwmon@vger.kernel.org; devicetree@vger.kernel.org;
> linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> jdelvare@suse.com; robh+dt@kernel.org; corbet@lwn.net
> Subject: Re: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
>
> [External]
>
> On Tue, Jan 28, 2020 at 10:59:59AM -0700, Mike Jones wrote:
> > Change 21537dc driver PMBus polling of MFR_COMMON from bits 5/4 to
> > bits 6/5. This fixs a LTC297X family bug where polling always
> > returns not busy even when the part is busy. This fixes a LTC388X
> > and LTM467X bug where polling used PEND and NOT_IN_TRANS, and BUSY
> > was not polled, which can lead to NACKing of commands. LTC388X and
> > LTM467X modules now poll BUSY and PEND, increasing reliability by
> > eliminating NACKing of commands.
> >
> > Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
>
> Fixes: e04d1ce9bbb49 ("hwmon: (ltc2978) Add polling for chips
> requiring it")
>
> > ---
> > drivers/hwmon/pmbus/ltc2978.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hwmon/pmbus/ltc2978.c
> > b/drivers/hwmon/pmbus/ltc2978.c index f01f488..a91ed01 100644
> > --- a/drivers/hwmon/pmbus/ltc2978.c
> > +++ b/drivers/hwmon/pmbus/ltc2978.c
> > @@ -82,8 +82,8 @@ enum chips { ltc2974, ltc2975, ltc2977, ltc2978,
> > ltc2980, ltc3880, ltc3882,
> >
> > #define LTC_POLL_TIMEOUT 100 /* in milli-seconds */
> >
> > -#define LTC_NOT_BUSY BIT(5)
> > -#define LTC_NOT_PENDING BIT(4)
> > +#define LTC_NOT_BUSY BIT(6)
> > +#define LTC_NOT_PENDING BIT(5)
> >
>
> In ltc_wait_ready(), we have:
>
> /*
> * LTC3883 does not support LTC_NOT_PENDING, even though
> * the datasheet claims that it does.
> */
> mask = LTC_NOT_BUSY;
> if (data->id != ltc3883)
> mask |= LTC_NOT_PENDING;
>
> The semantics of this code is now different: It means that on
> LTC3883 only bit 6 is checked; previously, it was bit 5. I agree that the above change makes sense, but it doesn't seem correct to drop the check for bit 5 on LTC3883. Maybe remove the if() above and always check for bit 5 and 6 ? Or should bit 4 be checked on parts other than LTC3883 ?
>
> #define LTC_NOT_TRANSITIONING BIT(4)
> ...
> mask = LTC_NOT_BUSY | LTC_NOT_PENDING;
> if (data->id != ltc3883)
> mask |= LTC_NOT_TRANSITIONING;
>
> Thanks,
> Guenter
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
2020-01-28 21:35 ` Jones, Michael-A1
@ 2020-01-28 22:38 ` Guenter Roeck
0 siblings, 0 replies; 9+ messages in thread
From: Guenter Roeck @ 2020-01-28 22:38 UTC (permalink / raw)
To: Jones, Michael-A1
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, jdelvare,
robh+dt, corbet
Hi Mike,
On Tue, Jan 28, 2020 at 09:35:49PM +0000, Jones, Michael-A1 wrote:
> Guentar,
>
> Yes, LTC3883. Slip of the finger.
>
> I am happy as is. If LTC3883 starts selling like hotcakes, I'll update it later.
>
> This is my first attempt at doing things the linux way, so if you see something I should do different, let me know. I left off Tested-by, assuming that Signed-off-by was good enough. But I do test the changes using a DLN-2 and demo boards.
>
Don't top post, and split your lines at 80 columns. Tested-by: only makes
sense if someone else tested your code; that you have tested it yourself
is (or should be) implied in the Signed-off-by: tag (that people sometimes
send patches which don't even compile is no excuse).
Thanks,
Guenter
> Mike
>
> -----Original Message-----
> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> Sent: Tuesday, January 28, 2020 2:31 PM
> To: Jones, Michael-A1 <Michael-A1.Jones@analog.com>
> Cc: linux-hwmon@vger.kernel.org; devicetree@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; jdelvare@suse.com; robh+dt@kernel.org; corbet@lwn.net
> Subject: Re: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
>
> [External]
>
> On Tue, Jan 28, 2020 at 09:16:39PM +0000, Jones, Michael-A1 wrote:
> > Guenter,
> >
> > The decision to not poll PEND was based on some other non-driver code based on /dev/i2c that looked like this:
> >
> > // Set to 0 for LTC3883 which does not support PEND
> > #define USE_PEND 1
> >
> > #define NOT_BUSY 1 << 6
> > #define NOT_TRANS 1 << 4
> > #if (USE_PEND)
> > #define NOT_PENDING 1 << 5
> > #else
> > #define NOT_PENDING 0
> > #endif
> >
> > My recollection is that came from the datasheet, many years ago.
> >
> > I talked to the designer, and if the above is correct, it has not been correct since 2012. The designer was not interested in researching artifacts that far back in history. So we know it has been in the part for at least 8 years.
> >
> > There seems to be two choices:
> >
> > A) Leave it as is
> > B) Poll the PEND bit and possibly break compatibility on ancient
> > hardware
> >
> > Generally, unused status bits in this kind are high when reserved or not used. That is good for polling.
> >
> > The shipping volume of LTC3888 has always been very low compared to other parts, so exposure is very small, certainly Cisco/Juniper type companies would not be effected.
> >
> I assume you mean LTC3883, not LTC3888.
>
> > I would feel ok with polling PEND on this part. Let me know your opinion.
> >
> > On a related matter, bit 4 is asserted low when the output is changing value. Hwmon cannot cause this because it only performs telemetry.
> >
> > A user application could change VOUT and cause this to happen. Telemetry would reflect the last measured value from a 100ms internal polling loop, which may be a before, after, or during value. I have always judged that checking this bit has no value, and it can be problematic. If the part is set to have a very long transition rate, like 5 seconds, this would hang the call for a long time. That seemed bad to me, and is why I did not poll this bit.
> >
>
> Your call, really. My major concern was that bit 5 is no longer polled on LTC3883. From the above, it looks like it actually _is_ the pending bit (5) that isn't supported on LTC3883. With that in mind, I'll apply the series as-is and add the Fixes: tag myself; no need to resend.
>
> Thanks,
> Guenter
>
> > Mike
> >
> > -----Original Message-----
> > From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> > Sent: Tuesday, January 28, 2020 12:13 PM
> > To: Jones, Michael-A1 <Michael-A1.Jones@analog.com>
> > Cc: linux-hwmon@vger.kernel.org; devicetree@vger.kernel.org;
> > linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
> > jdelvare@suse.com; robh+dt@kernel.org; corbet@lwn.net
> > Subject: Re: [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions.
> >
> > [External]
> >
> > On Tue, Jan 28, 2020 at 10:59:59AM -0700, Mike Jones wrote:
> > > Change 21537dc driver PMBus polling of MFR_COMMON from bits 5/4 to
> > > bits 6/5. This fixs a LTC297X family bug where polling always
> > > returns not busy even when the part is busy. This fixes a LTC388X
> > > and LTM467X bug where polling used PEND and NOT_IN_TRANS, and BUSY
> > > was not polled, which can lead to NACKing of commands. LTC388X and
> > > LTM467X modules now poll BUSY and PEND, increasing reliability by
> > > eliminating NACKing of commands.
> > >
> > > Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
> >
> > Fixes: e04d1ce9bbb49 ("hwmon: (ltc2978) Add polling for chips
> > requiring it")
> >
> > > ---
> > > drivers/hwmon/pmbus/ltc2978.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/hwmon/pmbus/ltc2978.c
> > > b/drivers/hwmon/pmbus/ltc2978.c index f01f488..a91ed01 100644
> > > --- a/drivers/hwmon/pmbus/ltc2978.c
> > > +++ b/drivers/hwmon/pmbus/ltc2978.c
> > > @@ -82,8 +82,8 @@ enum chips { ltc2974, ltc2975, ltc2977, ltc2978,
> > > ltc2980, ltc3880, ltc3882,
> > >
> > > #define LTC_POLL_TIMEOUT 100 /* in milli-seconds */
> > >
> > > -#define LTC_NOT_BUSY BIT(5)
> > > -#define LTC_NOT_PENDING BIT(4)
> > > +#define LTC_NOT_BUSY BIT(6)
> > > +#define LTC_NOT_PENDING BIT(5)
> > >
> >
> > In ltc_wait_ready(), we have:
> >
> > /*
> > * LTC3883 does not support LTC_NOT_PENDING, even though
> > * the datasheet claims that it does.
> > */
> > mask = LTC_NOT_BUSY;
> > if (data->id != ltc3883)
> > mask |= LTC_NOT_PENDING;
> >
> > The semantics of this code is now different: It means that on
> > LTC3883 only bit 6 is checked; previously, it was bit 5. I agree that the above change makes sense, but it doesn't seem correct to drop the check for bit 5 on LTC3883. Maybe remove the if() above and always check for bit 5 and 6 ? Or should bit 4 be checked on parts other than LTC3883 ?
> >
> > #define LTC_NOT_TRANSITIONING BIT(4)
> > ...
> > mask = LTC_NOT_BUSY | LTC_NOT_PENDING;
> > if (data->id != ltc3883)
> > mask |= LTC_NOT_TRANSITIONING;
> >
> > Thanks,
> > Guenter
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 3/3] hwmon: (pmbus/ltc2978): add support for more parts.
2020-01-28 18:00 ` [PATCH 3/3] hwmon: (pmbus/ltc2978): add support for more parts Mike Jones
@ 2020-02-06 17:12 ` Rob Herring
0 siblings, 0 replies; 9+ messages in thread
From: Rob Herring @ 2020-02-06 17:12 UTC (permalink / raw)
To: Mike Jones
Cc: linux-hwmon, devicetree, linux-doc, linux-kernel, linux,
jdelvare, corbet
On Tue, Jan 28, 2020 at 11:00:00AM -0700, Mike Jones wrote:
> LTC2972, LTC2979, LTC3884, LTC3889, LTC7880, LTM4664, LTM4677,
> LTM4678, LTM4680, LTM4700.
>
> Signed-off-by: Mike Jones <michael-a1.jones@analog.com>
> ---
> .../devicetree/bindings/hwmon/ltc2978.txt | 22 ++-
DT bindings should be a separate patch.
> Documentation/hwmon/ltc2978.rst | 164 ++++++++++++++++-----
> drivers/hwmon/pmbus/Kconfig | 11 +-
> drivers/hwmon/pmbus/ltc2978.c | 92 +++++++++++-
> 4 files changed, 238 insertions(+), 51 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/ltc2978.txt b/Documentation/devicetree/bindings/hwmon/ltc2978.txt
> index b428a70..4e7f621 100644
> --- a/Documentation/devicetree/bindings/hwmon/ltc2978.txt
> +++ b/Documentation/devicetree/bindings/hwmon/ltc2978.txt
> @@ -2,20 +2,30 @@ ltc2978
>
> Required properties:
> - compatible: should contain one of:
> + * "lltc,ltc2972"
> * "lltc,ltc2974"
> * "lltc,ltc2975"
> * "lltc,ltc2977"
> * "lltc,ltc2978"
> + * "lltc,ltc2979"
> * "lltc,ltc2980"
> * "lltc,ltc3880"
> * "lltc,ltc3882"
> * "lltc,ltc3883"
> + * "lltc,ltc3884"
> * "lltc,ltc3886"
> * "lltc,ltc3887"
> + * "lltc,ltc3889"
> + * "lltc,ltc7880"
> * "lltc,ltm2987"
> + * "lltc,ltm4664"
> * "lltc,ltm4675"
> * "lltc,ltm4676"
> + * "lltc,ltm4677"
> + * "lltc,ltm4678"
> + * "lltc,ltm4680"
> * "lltc,ltm4686"
> + * "lltc,ltm4700"
> - reg: I2C slave address
>
> Optional properties:
> @@ -25,13 +35,17 @@ Optional properties:
> standard binding for regulators; see regulator.txt.
>
> Valid names of regulators depend on number of supplies supported per device:
> + * ltc2972 vout0 - vout1
> * ltc2974, ltc2975 : vout0 - vout3
> - * ltc2977, ltc2980, ltm2987 : vout0 - vout7
> + * ltc2977, ltc2979, ltc2980, ltm2987 : vout0 - vout7
> * ltc2978 : vout0 - vout7
> - * ltc3880, ltc3882, ltc3886 : vout0 - vout1
> + * ltc3880, ltc3882, ltc3884, ltc3886, ltc3887, ltc3889 : vout0 - vout1
> + * ltc7880 : vout0 - vout1
> * ltc3883 : vout0
> - * ltm4676 : vout0 - vout1
> - * ltm4686 : vout0 - vout1
> + * ltm4664 : vout0 - vout1
> + * ltm4675, ltm4676, ltm4677, ltm4678 : vout0 - vout1
> + * ltm4680, ltm4686 : vout0 - vout1
> + * ltm4700 : vout0 - vout1
>
> Example:
> ltc2978@5e {
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-02-06 20:47 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-28 17:59 [PATCH 1/3] docs: hwmon: (pmbus/ltc2978): Update datasheet URLs to analog.com Mike Jones
2020-01-28 17:59 ` [PATCH 2/3] hwmon: (pmbus/ltc2978): Fix PMBus polling of MFR_COMMON definitions Mike Jones
2020-01-28 19:13 ` Guenter Roeck
2020-01-28 21:16 ` Jones, Michael-A1
2020-01-28 21:31 ` Guenter Roeck
2020-01-28 21:35 ` Jones, Michael-A1
2020-01-28 22:38 ` Guenter Roeck
2020-01-28 18:00 ` [PATCH 3/3] hwmon: (pmbus/ltc2978): add support for more parts Mike Jones
2020-02-06 17:12 ` Rob Herring
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).