hwmon: Add LTC4245 driver

Add Linux support for the Linear Technology LTC4245 Multiple Supply Hot Swap controller I2C monitoring interface.

---
 Documentation/hwmon/ltc4245 |   63 ++++++
 drivers/hwmon/Kconfig       |   11 +
 drivers/hwmon/Makefile      |    1 +
 drivers/hwmon/ltc4245.c     |  471 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 546 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/hwmon/ltc4245
 create mode 100644 drivers/hwmon/ltc4245.c

As the subject says, this is RFC. I was not sure how to make the alarms on this chip fit into the alarms framework specified in sysfs-interface, so I left them out. I'm completely open to suggestions on what to do. I also exposed a number of registers straight from the chip to userspace (via sysfs). I don't know what the policy is for this.

Take it easy on me, this is my first hwmon driver :) I'd love suggestions for improvements, however.

new file mode 100644
index 0000000..5694ef0
@@ -0,0 +1,63 @@
+Kernel driver ltc4245
+==========+
+Supported chips:
+  * Linear Technology LTC4245
+    Prefix: 'ltc4245'
+    Addresses scanned: 0x20-0x3f
+    Datasheet:
+        http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1006,C1140,P19392,D13517
+
+Author: Ira W. Snyder <[email protected]>
+
+
+Description
+-----------
+
+The LTC4245 controller allows a board to be safely inserted and removed
+from a live backplane in multiple supply systems such as CompactPCI and
+PCI Express.
+
+
+Sysfs entries
+-------------
+
+The LTC4245 has built-in limits for over and under current warnings. This
+makes it very likely that the reference circuit will be used.
+
+This driver uses the values in the datasheet to change the register values
+into the values specified in the sysfs-interface document.
+
+The fault registers were not exposed because I am not sure how to make them
+fit into the alarm interface defined in the sysfs-interface document.
+
+in0_input	12v input  voltage (mV)
+in1_input	12v sense  voltage (mV)
+in2_input	12v output voltage (mV)
+in3_input	5v  input  voltage (mV)
+in4_input	5v  sense  voltage (mV)
+in5_input	5v  output voltage (mV)
+in6_input	3v  input  voltage (mV)
+in7_input	3v  sense  voltage (mV)
+in8_input	3v  output voltage (mV)
+in9_input	VEEout input  voltage (mV)
+in10_input	VEEout sense  voltage (mV)
+in11_input	VEEout output voltage (mV)
+in12_input	GPIO #0 voltage (mV)
+in13_input	GPIO #1 voltage (mV)
+in14_input	GPIO #2 voltage (mV)
+in15_input	GPIO #3 voltage (mV)
+
+
+The following registers just return the value that is in the corresponding
+register in the chip. Read the datasheet to interpret them.
+
+status		Status register
+alert		Alert register
+control		Control register
+on		On register (enable/disable supplies)
+fault1		Overcurrent and Undervoltage faults
+fault2		Power Bad and other misc faults
+gpio		GPIO control/status register
+adcadr		ADC address register (for non free-running mode)
+

index d402e8d..91bec8a 100644
@@ -836,6 +836,17 @@ config SENSORS_APPLESMC
 	  Say Y here if you have an applicable laptop and want to experience
 	  the awesome power of applesmc.
 
+config SENSORS_LTC4245
+	tristate "Linear Technology LTC4245"
+	depends on I2C && EXPERIMENTAL
+	default n
+	help
+	  If you say yes here you get support for Linear Technology LTC4245
+	  Multiple Supply Hot Swap Controller I2C interface.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called ltc4245.
+
 config HWMON_DEBUG_CHIP
 	bool "Hardware Monitoring Chip debugging messages"
 	default n

index 950134a..0ed56ac 100644
@@ -59,6 +59,7 @@ obj-$(CONFIG_SENSORS_LM87)	+= lm87.o
 obj-$(CONFIG_SENSORS_LM90)	+= lm90.o
 obj-$(CONFIG_SENSORS_LM92)	+= lm92.o
 obj-$(CONFIG_SENSORS_LM93)	+= lm93.o
+obj-$(CONFIG_SENSORS_LTC4245)	+= ltc4245.o
 obj-$(CONFIG_SENSORS_MAX1619)	+= max1619.o
 obj-$(CONFIG_SENSORS_MAX6650)	+= max6650.o
 obj-$(CONFIG_SENSORS_PC87360)	+= pc87360.o

1.5.4.3


_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Hi Ira,

Welcome to our (small) hwmon community.

I've reviewed your driver, and I'm happy to report the code looks good! However as you already indicated yourself the sysfs interface needs some work. I've been reading the data sheet and I think I have a solution for most of the sysfs issues.

The policy is to never, ever do this. We made this mistake in the past and we really don't want to repeat this. Device drivers should abstract hardware so userspace can talk to a device of a certain type/class without needing to know which device it is talking to, exporting registers directly is pretty much thhe opposite of hardware abstraction! Well with that lecture done, lets start looking into a solution for this :)

I think we can atleast represent the Overcurrent and Undervoltage faults in a standard way, as for the other features I think it would be best to ignore those, esp. the ability to turn on/off certain power rails certainly leaves the realm of hardware *monitoring*

So on to the Overcurrent and Undervoltage faults, those are quite easy actually once we get the input rights, currently you use the following representation for for example the 12V inputs:

in0_input 12v input voltage (mV), range 0 - 14xxx mv
in1_input 12v sense voltage (mV), range 0 - 63 mv
in2_input 12v output voltage (mV), range 0 - 14xxx mv

Notice the very strange scale for the 12v sense voltage, this is because this is not an absolute voltage, but a delta voltage, compared to the 12v input voltage, and it is how much lower this voltage is (it can never be higher!).

The reason for this is, because the 12v sense input is not a Voltage input at all, it is an input to measure current! However as current cannot be measured, it is first converted to a (delta) voltage using a sense resistor, see table 2 "Sense Resistance Values" in the datasheet. So what we have here is a current input, and we have a standard sysfs interface for that:

"""
************
* Currents *
************

Note that no known chip provides current measurements as of writing, so this part is theoretical, so to say.

curr[1-*]_max Current max value
Unit: milliampere
RW

curr[1-*]_min Current min value.
Unit: milliampere
RW

curr[1-*]_input Current input value
Unit: milliampere
RO
"""

So we could change in1 "12v sense voltage (mV)" to curr1 "12v current (mA)", then the overcurrent fault for 12v, would become curr1_max_alarm. Mapping the undervolt alarm is easy too, as the datasheet specifies that this is an alarm when then input voltage becomes to low, so that would be in0_min_alarm.

That only leaves one issue, it would be nice to be able to map the currents and voltages together by something other then labels, but allas we have no API in place for that. We could however try to give them to same numbers.

So what I would like to suggest is to have the following sysfs attributes for inputs:

in1_input	12v input  voltage (mV)
in2_input	5v  input  voltage (mV)
in3_input	3v  input  voltage (mV)

curr1_input 12v amperage (mA)
curr2_input 12v amperage (mA)
curr3_input 12v amperage (mA)
in4_input 12v output voltage (mV)
in5_input 5v output voltage (mV)
in6_input 3v output voltage (mV)
in7_input VEEout input voltage (mV)
in8_input VEEout sense voltage (mV)
in9_input VEEout output voltage (mV)
in10_input GPIO #0 voltage (mV)
in11_input GPIO #1 voltage (mV)
in12_input GPIO #2 voltage (mV)
in13_input GPIO #3 voltage (mV)

Note how inX begins at 1 here whereas the docs say it starts at 0, but skipping numbers (including 0) is allowed. Also note that we have no userspace code for current measuring yet, but that can be added to the current libsensors and sensors program easily.

This would then ofcourse be completed with the following alarm sysfs attributes:
in1_min_alarm
in2_min_alarm
in3_min_alarm
curr1_max_alarm
curr2_max_alarm
curr3_max_alarm

Given that we measure both output voltage and current, I think it would be cool to also add power#_input's to the driver, as thats just "output voltage * current". I know people will start screaming that we should do things like this in userspace, but given the fact that we have no API to match voltages and currents, let alone one to do the interesting mapping here, where one current corresponds to 2 voltages, and given how easy it is to add these 2 this driver, I'm in favor of adding them, so then we would also get:

power1_input 12v power consumption (micro watt)
power2_input 5v power consumption (micro watt)
power3_input 3v power consumption (micro watt)

Jean, whats your 2 cents on this ?

Don't worry, for a first driver it is pretty good :) If you agree with my proposed sysfs interface and change the driver to match, I think we can get it in to 2.6.28.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

I guess you mean 5v...

... and 3v.

I don't have enough free time these days to afford having an objection. I am not too happy to see non-independent inputs in sysfs, as there's no way for the user to know which values are independent and which are computer, but indeed we lack a good way to express the relations between different inputs. That's the same problem we had for fan# and pwm#, or pwm# and temp# for automatic fan speed control. At some point it might be convenient to introduce virtual sub-devices grouping together things related items. For now, all we have is pwm[1-*]_auto_channels_temp to map temperature channels to pwm outputs. I guess we could do something similar to link voltage and current channels.

But then again I do not have enough time to properly think about this and propose something. So I'd say, do whatever you want, and whoever really cares will have to do the thinking and the proposal and update the drivers and libsensors if/as needed.

That's a pretty optimistic statement from someone who isn't in charge ;)

Jean Delvare

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Erm, yes.

I hear you, but as everyone involved in hwmon seems to be short on time, and as
this is the first IC to expose this kind of problems, I think for now its
best to just stick with what we have. And add the power#_input attributes to this driver as a service to userspace, as userspace cannot easily find this out itself due to lack of API.

Erm (I get the hint), yes it is :)

Regards,

Hans

_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors