summaryrefslogtreecommitdiffstats
path: root/Documentation/hwmon
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2014-06-03 11:09:43 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2014-06-03 11:09:43 -0700
commitf456205265a61f1d649f8378eceaa163850cba4e (patch)
treec974aafac8fad9bf1322f2ec66aaf01d01adfaf8 /Documentation/hwmon
parent8f5759aeb88a47448cd92ab55a016d013b154a98 (diff)
parent9d311eddf3565ed0e05b3cb5a22db41fa74d9d86 (diff)
downloadblackbird-op-linux-f456205265a61f1d649f8378eceaa163850cba4e.tar.gz
blackbird-op-linux-f456205265a61f1d649f8378eceaa163850cba4e.zip
Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging into next
Pull hwmon updates from Guenter Roeck: "New driver for NCT6683D New chip support to existing drivers: - add support for STTS2004 and AT30TSE004 to jc42 driver - add support for EMC1402/EMC1412/EMC1422 to emc1403 driver Other notable changes: - document hwmon kernel API - convert jc42, lm70, lm75, lm77, lm83, lm92, max1619, tmp421, and tmp102 drivers to use new hwmon API functions - replace function macros in lm80, lm92, and jc42 drivers with real code - convert emc1403 driver to use regmap, add support for additional attributes, and add device IDs for EMC1412, EMC1413, and EMC1414 - various additional cleanup and minor bug fixes in several drivers" * tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (60 commits) hwmon: (nct6775) Fix probe unwind paths to properly unregister platform devices hwmon: (nct6683) Fix probe unwind paths to properly unregister platform devices hwmon: (ultra45_env) Introduce managed version of kzalloc hwmon: Driver for NCT6683D hwmon: (lm80) Rearrange code to avoid forward declarations hwmon: (lm80) Convert fan display function macros into functions hwmon: (lm80) Convert voltage display function macros into functions hwmon: (lm80) Convert temperature display function macros into functions hwmon: (lm80) Normalize all temperature values to 16 bit hwmon: (lm80) Simplify TEMP_FROM_REG hwmon: (lm83) Convert to use devm_hwmon_device_register_with_groups hwmon: (lm83) Rearange code to avoid forward declarations hwmon: (lm83) Drop FSF address hwmon: (max1619) Convert to use devm_hwmon_device_register_with_groups hwmon: (max1619) Drop function macros hwmon: (max1619) Rearrange code to avoid forward declarations hwmon: (max1619) Drop FSF address hwmon: (max1619) Fix critical alarm display hwmon: (jc42) Add support for STTS2004 and AT30TSE004 hwmon: (jc42) Convert function macros into functions ...
Diffstat (limited to 'Documentation/hwmon')
-rw-r--r--Documentation/hwmon/emc140359
-rw-r--r--Documentation/hwmon/hwmon-kernel-api.txt107
-rw-r--r--Documentation/hwmon/jc4216
-rw-r--r--Documentation/hwmon/lm7720
-rw-r--r--Documentation/hwmon/nct668357
5 files changed, 251 insertions, 8 deletions
diff --git a/Documentation/hwmon/emc1403 b/Documentation/hwmon/emc1403
new file mode 100644
index 000000000000..a869b0ef6a9d
--- /dev/null
+++ b/Documentation/hwmon/emc1403
@@ -0,0 +1,59 @@
+Kernel driver emc1403
+=====================
+
+Supported chips:
+ * SMSC / Microchip EMC1402, EMC1412
+ Addresses scanned: I2C 0x18, 0x1c, 0x29, 0x4c, 0x4d, 0x5c
+ Prefix: 'emc1402'
+ Datasheets:
+ http://ww1.microchip.com/downloads/en/DeviceDoc/1412.pdf
+ http://ww1.microchip.com/downloads/en/DeviceDoc/1402.pdf
+ * SMSC / Microchip EMC1403, EMC1404, EMC1413, EMC1414
+ Addresses scanned: I2C 0x18, 0x29, 0x4c, 0x4d
+ Prefix: 'emc1403', 'emc1404'
+ Datasheets:
+ http://ww1.microchip.com/downloads/en/DeviceDoc/1403_1404.pdf
+ http://ww1.microchip.com/downloads/en/DeviceDoc/1413_1414.pdf
+ * SMSC / Microchip EMC1422
+ Addresses scanned: I2C 0x4c
+ Prefix: 'emc1422'
+ Datasheet:
+ http://ww1.microchip.com/downloads/en/DeviceDoc/1422.pdf
+ * SMSC / Microchip EMC1423, EMC1424
+ Addresses scanned: I2C 0x4c
+ Prefix: 'emc1423', 'emc1424'
+ Datasheet:
+ http://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf
+
+Author:
+ Kalhan Trisal <kalhan.trisal@intel.com
+
+
+Description
+-----------
+
+The Standard Microsystems Corporation (SMSC) / Microchip EMC14xx chips
+contain up to four temperature sensors. EMC14x2 support two sensors
+(one internal, one external). EMC14x3 support three sensors (one internal,
+two external), and EMC14x4 support four sensors (one internal, three
+external).
+
+The chips implement three limits for each sensor: low (tempX_min), high
+(tempX_max) and critical (tempX_crit.) The chips also implement an
+hysteresis mechanism which applies to all limits. The relative difference
+is stored in a single register on the chip, which means that the relative
+difference between the limit and its hysteresis is always the same for
+all three limits.
+
+This implementation detail implies the following:
+* When setting a limit, its hysteresis will automatically follow, the
+ difference staying unchanged. For example, if the old critical limit
+ was 80 degrees C, and the hysteresis was 75 degrees C, and you change
+ the critical limit to 90 degrees C, then the hysteresis will
+ automatically change to 85 degrees C.
+* The hysteresis values can't be set independently. We decided to make
+ only temp1_crit_hyst writable, while all other hysteresis attributes
+ are read-only. Setting temp1_crit_hyst writes the difference between
+ temp1_crit_hyst and temp1_crit into the chip, and the same relative
+ hysteresis applies automatically to all other limits.
+* The limits should be set before the hysteresis.
diff --git a/Documentation/hwmon/hwmon-kernel-api.txt b/Documentation/hwmon/hwmon-kernel-api.txt
new file mode 100644
index 000000000000..2ecdbfc85ecf
--- /dev/null
+++ b/Documentation/hwmon/hwmon-kernel-api.txt
@@ -0,0 +1,107 @@
+The Linux Hardware Monitoring kernel API.
+=========================================
+
+Guenter Roeck
+
+Introduction
+------------
+
+This document describes the API that can be used by hardware monitoring
+drivers that want to use the hardware monitoring framework.
+
+This document does not describe what a hardware monitoring (hwmon) Driver or
+Device is. It also does not describe the API which can be used by user space
+to communicate with a hardware monitoring device. If you want to know this
+then please read the following file: Documentation/hwmon/sysfs-interface.
+
+For additional guidelines on how to write and improve hwmon drivers, please
+also read Documentation/hwmon/submitting-patches.
+
+The API
+-------
+Each hardware monitoring driver must #include <linux/hwmon.h> and, in most
+cases, <linux/hwmon-sysfs.h>. linux/hwmon.h declares the following
+register/unregister functions:
+
+struct device *hwmon_device_register(struct device *dev);
+struct device *
+hwmon_device_register_with_groups(struct device *dev, const char *name,
+ void *drvdata,
+ const struct attribute_group **groups);
+
+struct device *
+devm_hwmon_device_register_with_groups(struct device *dev,
+ const char *name, void *drvdata,
+ const struct attribute_group **groups);
+
+void hwmon_device_unregister(struct device *dev);
+void devm_hwmon_device_unregister(struct device *dev);
+
+hwmon_device_register registers a hardware monitoring device. The parameter
+of this function is a pointer to the parent device.
+This function returns a pointer to the newly created hardware monitoring device
+or PTR_ERR for failure. If this registration function is used, hardware
+monitoring sysfs attributes are expected to have been created and attached to
+the parent device prior to calling hwmon_device_register. A name attribute must
+have been created by the caller.
+
+hwmon_device_register_with_groups is similar to hwmon_device_register. However,
+it has additional parameters. The name parameter is a pointer to the hwmon
+device name. The registration function wil create a name sysfs attribute
+pointing to this name. The drvdata parameter is the pointer to the local
+driver data. hwmon_device_register_with_groups will attach this pointer
+to the newly allocated hwmon device. The pointer can be retrieved by the driver
+using dev_get_drvdata() on the hwmon device pointer. The groups parameter is
+a pointer to a list of sysfs attribute groups. The list must be NULL terminated.
+hwmon_device_register_with_groups creates the hwmon device with name attribute
+as well as all sysfs attributes attached to the hwmon device.
+
+devm_hwmon_device_register_with_groups is similar to
+hwmon_device_register_with_groups. However, it is device managed, meaning the
+hwmon device does not have to be removed explicitly by the removal function.
+
+hwmon_device_unregister deregisters a registered hardware monitoring device.
+The parameter of this function is the pointer to the registered hardware
+monitoring device structure. This function must be called from the driver
+remove function if the hardware monitoring device was registered with
+hwmon_device_register or with hwmon_device_register_with_groups.
+
+devm_hwmon_device_unregister does not normally have to be called. It is only
+needed for error handling, and only needed if the driver probe fails after
+the call to devm_hwmon_device_register_with_groups.
+
+The header file linux/hwmon-sysfs.h provides a number of useful macros to
+declare and use hardware monitoring sysfs attributes.
+
+In many cases, you can use the exsting define DEVICE_ATTR to declare such
+attributes. This is feasible if an attribute has no additional context. However,
+in many cases there will be additional information such as a sensor index which
+will need to be passed to the sysfs attribute handling function.
+
+SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributes
+which need such additional context information. SENSOR_DEVICE_ATTR requires
+one additional argument, SENSOR_DEVICE_ATTR_2 requires two.
+
+SENSOR_DEVICE_ATTR defines a struct sensor_device_attribute variable.
+This structure has the following fields.
+
+struct sensor_device_attribute {
+ struct device_attribute dev_attr;
+ int index;
+};
+
+You can use to_sensor_dev_attr to get the pointer to this structure from the
+attribute read or write function. Its parameter is the device to which the
+attribute is attached.
+
+SENSOR_DEVICE_ATTR_2 defines a struct sensor_device_attribute_2 variable,
+which is defined as follows.
+
+struct sensor_device_attribute_2 {
+ struct device_attribute dev_attr;
+ u8 index;
+ u8 nr;
+};
+
+Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameter
+is the device to which the attribute is attached.
diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42
index 868d74d6b773..f3893f7440de 100644
--- a/Documentation/hwmon/jc42
+++ b/Documentation/hwmon/jc42
@@ -5,9 +5,12 @@ Supported chips:
* Analog Devices ADT7408
Datasheets:
http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf
- * Atmel AT30TS00
+ * Atmel AT30TS00, AT30TS002A/B, AT30TSE004A
Datasheets:
http://www.atmel.com/Images/doc8585.pdf
+ http://www.atmel.com/Images/doc8711.pdf
+ http://www.atmel.com/Images/Atmel-8852-SEEPROM-AT30TSE002A-Datasheet.pdf
+ http://www.atmel.com/Images/Atmel-8868-DTS-AT30TSE004A-Datasheet.pdf
* IDT TSE2002B3, TSE2002GB2, TS3000B3, TS3000GB2
Datasheets:
http://www.idt.com/sites/default/files/documents/IDT_TSE2002B3C_DST_20100512_120303152056.pdf
@@ -34,12 +37,13 @@ Supported chips:
Datasheet:
http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF
http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF
- * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS3000
+ * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS2004, STTS3000
Datasheets:
- http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157556.pdf
- http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157558.pdf
- http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00225278.pdf
- http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00270920.pdf
+ http://www.st.com/web/en/resource/technical/document/datasheet/CD00157556.pdf
+ http://www.st.com/web/en/resource/technical/document/datasheet/CD00157558.pdf
+ http://www.st.com/web/en/resource/technical/document/datasheet/CD00266638.pdf
+ http://www.st.com/web/en/resource/technical/document/datasheet/CD00225278.pdf
+ http://www.st.com/web/en/resource/technical/document/datasheet/DM00076709.pdf
* JEDEC JC 42.4 compliant temperature sensor chips
Datasheet:
http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf
diff --git a/Documentation/hwmon/lm77 b/Documentation/hwmon/lm77
index 57c3a46d6370..bfc915fe3639 100644
--- a/Documentation/hwmon/lm77
+++ b/Documentation/hwmon/lm77
@@ -18,5 +18,21 @@ sensor incorporates a band-gap type temperature sensor,
10-bit ADC, and a digital comparator with user-programmable upper
and lower limit values.
-Limits can be set through the Overtemperature Shutdown register and
-Hysteresis register.
+The LM77 implements 3 limits: low (temp1_min), high (temp1_max) and
+critical (temp1_crit.) It also implements an hysteresis mechanism which
+applies to all 3 limits. The relative difference is stored in a single
+register on the chip, which means that the relative difference between
+the limit and its hysteresis is always the same for all 3 limits.
+
+This implementation detail implies the following:
+* When setting a limit, its hysteresis will automatically follow, the
+ difference staying unchanged. For example, if the old critical limit
+ was 80 degrees C, and the hysteresis was 75 degrees C, and you change
+ the critical limit to 90 degrees C, then the hysteresis will
+ automatically change to 85 degrees C.
+* All 3 hysteresis can't be set independently. We decided to make
+ temp1_crit_hyst writable, while temp1_min_hyst and temp1_max_hyst are
+ read-only. Setting temp1_crit_hyst writes the difference between
+ temp1_crit_hyst and temp1_crit into the chip, and the same relative
+ hysteresis applies automatically to the low and high limits.
+* The limits should be set before the hysteresis.
diff --git a/Documentation/hwmon/nct6683 b/Documentation/hwmon/nct6683
new file mode 100644
index 000000000000..c1301d4300cd
--- /dev/null
+++ b/Documentation/hwmon/nct6683
@@ -0,0 +1,57 @@
+Kernel driver nct6683
+=====================
+
+Supported chips:
+ * Nuvoton NCT6683D
+ Prefix: 'nct6683'
+ Addresses scanned: ISA address retrieved from Super I/O registers
+ Datasheet: Available from Nuvoton upon request
+
+Authors:
+ Guenter Roeck <linux@roeck-us.net>
+
+Description
+-----------
+
+This driver implements support for the Nuvoton NCT6683D eSIO chip.
+
+The chips implement up to shared 32 temperature and voltage sensors.
+It supports up to 16 fan rotation sensors and up to 8 fan control engines.
+
+Temperatures are measured in degrees Celsius. Measurement resolution is
+0.5 degrees C.
+
+Voltage sensors (also known as IN sensors) report their values in millivolts.
+
+Fan rotation speeds are reported in RPM (rotations per minute).
+
+Usage Note
+----------
+
+Limit register locations on Intel boards with EC firmware version 1.0
+build date 04/03/13 do not match the register locations in the Nuvoton
+datasheet. Nuvoton confirms that Intel uses a special firmware version
+with different register addresses. The specification describing the Intel
+firmware is held under NDA by Nuvoton and Intel and not available
+to the public.
+
+Some of the register locations can be reverse engineered; others are too
+well hidden. Given this, writing any values from the operating system is
+considered too risky with this firmware and has been disabled. All limits
+must all be written from the BIOS.
+
+The driver has only been tested with the Intel firmware, and by default
+only instantiates on Intel boards. To enable it on non-Intel boards,
+set the 'force' module parameter to 1.
+
+Tested Boards and Firmware Versions
+-----------------------------------
+
+The driver has been reported to work with the following boards and
+firmware versions.
+
+Board Firmware version
+---------------------------------------------------------------
+Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13
+Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13
+Intel DB85FL NCT6683D EC firmware version 1.0 build 04/03/13
OpenPOWER on IntegriCloud