summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2011-10-26 16:52:52 +0400
committerLinus Torvalds <torvalds@linux-foundation.org>2011-10-26 16:52:52 +0400
commit3cb603284b3d256ae9ae9e65887cee8416bfef15 (patch)
treea7012e9ca585c4ada1ff8896de326f540b460f80 /Documentation
parent2355e4290336fcda4b4a799448f745155a000226 (diff)
parentc5794cfac09a585945e1632451900594db19393b (diff)
downloadlinux-3cb603284b3d256ae9ae9e65887cee8416bfef15.tar.xz
Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (26 commits) hwmon: (w83627ehf) Better fix for negative temperature values hwmon: (w83627ehf) Uninline is_word_sized hwmon: (lm75) Document why clones are not detected hwmon: (w83627ehf) Move fan pins check to a separate function hwmon: (w83627ehf) Skip reading unused voltage registers hwmon: (lm75) Add support for Analog Devices ADT75 hwmon: (pmbus_core) Simplify sign extensions hwmon: (pmbus) Add support for Lineage Power DC-DC converters hwmon: (pmbus/ltc2978) Add support for LTC3880 to LTC2978 driver hwmon: (pmbus/ltc2978) Explicit driver for LTC2978 hwmon: (pmbus) Add support for TEMP2 peak attributes hwmon: AD7314 driver (ported from IIO) hwmon: (pmbus) Add support for Intersil power management chips hwmon: (pmbus) Always call _pmbus_read_byte in core driver hwmon: (pmbus) Replace EINVAL return codes with more appropriate errors hwmon: (pmbus) Provide more documentation hwmon/f71882fg: Make the decision wether to register fan attr. per fan hwmon/f71882fg: Add a f71882fg_create_fan_sysfs_files helper function hwmon/f71882fg: Make all fan/pwm attr tables 2 dimensional hwmon: (exynos4_tmu) Remove IRQF_DISABLED ...
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/hwmon/ad731425
-rw-r--r--Documentation/hwmon/adm127540
-rw-r--r--Documentation/hwmon/exynos4_tmu81
-rw-r--r--Documentation/hwmon/lm7561
-rw-r--r--Documentation/hwmon/ltc2978103
-rw-r--r--Documentation/hwmon/pmbus13
-rw-r--r--Documentation/hwmon/pmbus-core283
-rw-r--r--Documentation/hwmon/zl6100125
8 files changed, 689 insertions, 42 deletions
diff --git a/Documentation/hwmon/ad7314 b/Documentation/hwmon/ad7314
new file mode 100644
index 000000000000..1912549c7467
--- /dev/null
+++ b/Documentation/hwmon/ad7314
@@ -0,0 +1,25 @@
+Kernel driver ad7314
+====================
+
+Supported chips:
+ * Analog Devices AD7314
+ Prefix: 'ad7314'
+ Datasheet: Publicly available at Analog Devices website.
+ * Analog Devices ADT7301
+ Prefix: 'adt7301'
+ Datasheet: Publicly available at Analog Devices website.
+ * Analog Devices ADT7302
+ Prefix: 'adt7302'
+ Datasheet: Publicly available at Analog Devices website.
+
+Description
+-----------
+
+Driver supports the above parts. The ad7314 has a 10 bit
+sensor with 1lsb = 0.25 degrees centigrade. The adt7301 and
+adt7302 have 14 bit sensors with 1lsb = 0.03125 degrees centigrade.
+
+Notes
+-----
+
+Currently power down mode is not supported.
diff --git a/Documentation/hwmon/adm1275 b/Documentation/hwmon/adm1275
index 097b3ccc4be7..ab70d96d2dfd 100644
--- a/Documentation/hwmon/adm1275
+++ b/Documentation/hwmon/adm1275
@@ -6,6 +6,10 @@ Supported chips:
Prefix: 'adm1275'
Addresses scanned: -
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1275.pdf
+ * Analog Devices ADM1276
+ Prefix: 'adm1276'
+ Addresses scanned: -
+ Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1276.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
@@ -13,13 +17,13 @@ Author: Guenter Roeck <guenter.roeck@ericsson.com>
Description
-----------
-This driver supports hardware montoring for Analog Devices ADM1275 Hot-Swap
-Controller and Digital Power Monitor.
+This driver supports hardware montoring for Analog Devices ADM1275 and ADM1276
+Hot-Swap Controller and Digital Power Monitor.
-The ADM1275 is a hot-swap controller that allows a circuit board to be removed
-from or inserted into a live backplane. It also features current and voltage
-readback via an integrated 12-bit analog-to-digital converter (ADC), accessed
-using a PMBus. interface.
+ADM1275 and ADM1276 are hot-swap controllers that allow a circuit board to be
+removed from or inserted into a live backplane. They also feature current and
+voltage readback via an integrated 12-bit analog-to-digital converter (ADC),
+accessed using a PMBus interface.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus for details on PMBus client drivers.
@@ -48,17 +52,25 @@ attributes are write-only, all other attributes are read-only.
in1_label "vin1" or "vout1" depending on chip variant and
configuration.
-in1_input Measured voltage. From READ_VOUT register.
-in1_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
-in1_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
-in1_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
-in1_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
+in1_input Measured voltage.
+in1_min Minumum Voltage.
+in1_max Maximum voltage.
+in1_min_alarm Voltage low alarm.
+in1_max_alarm Voltage high alarm.
in1_highest Historical maximum voltage.
in1_reset_history Write any value to reset history.
curr1_label "iout1"
-curr1_input Measured current. From READ_IOUT register.
-curr1_max Maximum current. From IOUT_OC_WARN_LIMIT register.
-curr1_max_alarm Current high alarm. From IOUT_OC_WARN_LIMIT register.
+curr1_input Measured current.
+curr1_max Maximum current.
+curr1_max_alarm Current high alarm.
+curr1_lcrit Critical minimum current. Depending on the chip
+ configuration, either curr1_lcrit or curr1_crit is
+ supported, but not both.
+curr1_lcrit_alarm Critical current low alarm.
+curr1_crit Critical maximum current. Depending on the chip
+ configuration, either curr1_lcrit or curr1_crit is
+ supported, but not both.
+curr1_crit_alarm Critical current high alarm.
curr1_highest Historical maximum current.
curr1_reset_history Write any value to reset history.
diff --git a/Documentation/hwmon/exynos4_tmu b/Documentation/hwmon/exynos4_tmu
new file mode 100644
index 000000000000..c3c6b41db607
--- /dev/null
+++ b/Documentation/hwmon/exynos4_tmu
@@ -0,0 +1,81 @@
+Kernel driver exynos4_tmu
+=================
+
+Supported chips:
+* ARM SAMSUNG EXYNOS4 series of SoC
+ Prefix: 'exynos4-tmu'
+ Datasheet: Not publicly available
+
+Authors: Donggeun Kim <dg77.kim@samsung.com>
+
+Description
+-----------
+
+This driver allows to read temperature inside SAMSUNG EXYNOS4 series of SoC.
+
+The chip only exposes the measured 8-bit temperature code value
+through a register.
+Temperature can be taken from the temperature code.
+There are three equations converting from temperature to temperature code.
+
+The three equations are:
+ 1. Two point trimming
+ Tc = (T - 25) * (TI2 - TI1) / (85 - 25) + TI1
+
+ 2. One point trimming
+ Tc = T + TI1 - 25
+
+ 3. No trimming
+ Tc = T + 50
+
+ Tc: Temperature code, T: Temperature,
+ TI1: Trimming info for 25 degree Celsius (stored at TRIMINFO register)
+ Temperature code measured at 25 degree Celsius which is unchanged
+ TI2: Trimming info for 85 degree Celsius (stored at TRIMINFO register)
+ Temperature code measured at 85 degree Celsius which is unchanged
+
+TMU(Thermal Management Unit) in EXYNOS4 generates interrupt
+when temperature exceeds pre-defined levels.
+The maximum number of configurable threshold is four.
+The threshold levels are defined as follows:
+ Level_0: current temperature > trigger_level_0 + threshold
+ Level_1: current temperature > trigger_level_1 + threshold
+ Level_2: current temperature > trigger_level_2 + threshold
+ Level_3: current temperature > trigger_level_3 + threshold
+
+ The threshold and each trigger_level are set
+ through the corresponding registers.
+
+When an interrupt occurs, this driver notify user space of
+one of four threshold levels for the interrupt
+through kobject_uevent_env and sysfs_notify functions.
+Although an interrupt condition for level_0 can be set,
+it is not notified to user space through sysfs_notify function.
+
+Sysfs Interface
+---------------
+name name of the temperature sensor
+ RO
+
+temp1_input temperature
+ RO
+
+temp1_max temperature for level_1 interrupt
+ RO
+
+temp1_crit temperature for level_2 interrupt
+ RO
+
+temp1_emergency temperature for level_3 interrupt
+ RO
+
+temp1_max_alarm alarm for level_1 interrupt
+ RO
+
+temp1_crit_alarm
+ alarm for level_2 interrupt
+ RO
+
+temp1_emergency_alarm
+ alarm for level_3 interrupt
+ RO
diff --git a/Documentation/hwmon/lm75 b/Documentation/hwmon/lm75
index a1790401fdde..c91a1d15fa28 100644
--- a/Documentation/hwmon/lm75
+++ b/Documentation/hwmon/lm75
@@ -12,26 +12,46 @@ Supported chips:
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/
- * Dallas Semiconductor DS75
- Prefix: 'lm75'
- Addresses scanned: I2C 0x48 - 0x4f
- Datasheet: Publicly available at the Dallas Semiconductor website
- http://www.maxim-ic.com/
- * Dallas Semiconductor DS1775
- Prefix: 'lm75'
- Addresses scanned: I2C 0x48 - 0x4f
+ * Dallas Semiconductor DS75, DS1775
+ Prefixes: 'ds75', 'ds1775'
+ Addresses scanned: none
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.maxim-ic.com/
* Maxim MAX6625, MAX6626
- Prefix: 'lm75'
- Addresses scanned: I2C 0x48 - 0x4b
+ Prefixes: 'max6625', 'max6626'
+ Addresses scanned: none
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/
* Microchip (TelCom) TCN75
Prefix: 'lm75'
- Addresses scanned: I2C 0x48 - 0x4f
+ Addresses scanned: none
+ Datasheet: Publicly available at the Microchip website
+ http://www.microchip.com/
+ * Microchip MCP9800, MCP9801, MCP9802, MCP9803
+ Prefix: 'mcp980x'
+ Addresses scanned: none
Datasheet: Publicly available at the Microchip website
http://www.microchip.com/
+ * Analog Devices ADT75
+ Prefix: 'adt75'
+ Addresses scanned: none
+ Datasheet: Publicly available at the Analog Devices website
+ http://www.analog.com/adt75
+ * ST Microelectronics STDS75
+ Prefix: 'stds75'
+ Addresses scanned: none
+ Datasheet: Publicly available at the ST website
+ http://www.st.com/internet/analog/product/121769.jsp
+ * Texas Instruments TMP100, TMP101, TMP105, TMP75, TMP175, TMP275
+ Prefixes: 'tmp100', 'tmp101', 'tmp105', 'tmp175', 'tmp75', 'tmp275'
+ Addresses scanned: none
+ Datasheet: Publicly available at the Texas Instruments website
+ http://www.ti.com/product/tmp100
+ http://www.ti.com/product/tmp101
+ http://www.ti.com/product/tmp105
+ http://www.ti.com/product/tmp75
+ http://www.ti.com/product/tmp175
+ http://www.ti.com/product/tmp275
Author: Frodo Looijaard <frodol@dds.nl>
@@ -50,21 +70,16 @@ range of -55 to +125 degrees.
The LM75 only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
-The LM75 is usually used in combination with LM78-like chips, to measure
-the temperature of the processor(s).
-
-The DS75, DS1775, MAX6625, and MAX6626 are supported as well.
-They are not distinguished from an LM75. While most of these chips
-have three additional bits of accuracy (12 vs. 9 for the LM75),
-the additional bits are not supported. Not only that, but these chips will
-not be detected if not in 9-bit precision mode (use the force parameter if
-needed).
-
-The TCN75 is supported as well, and is not distinguished from an LM75.
+The original LM75 was typically used in combination with LM78-like chips
+on PC motherboards, to measure the temperature of the processor(s). Clones
+are now used in various embedded designs.
The LM75 is essentially an industry standard; there may be other
LM75 clones not listed here, with or without various enhancements,
-that are supported.
+that are supported. The clones are not detected by the driver, unless
+they reproduce the exact register tricks of the original LM75, and must
+therefore be instantiated explicitly. The specific enhancements (such as
+higher resolution) are not currently supported by the driver.
The LM77 is not supported, contrary to what we pretended for a long time.
Both chips are simply not compatible, value encoding differs.
diff --git a/Documentation/hwmon/ltc2978 b/Documentation/hwmon/ltc2978
new file mode 100644
index 000000000000..c365f9beb5dd
--- /dev/null
+++ b/Documentation/hwmon/ltc2978
@@ -0,0 +1,103 @@
+Kernel driver ltc2978
+=====================
+
+Supported chips:
+ * Linear Technology LTC2978
+ Prefix: 'ltc2978'
+ Addresses scanned: -
+ Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
+ * Linear Technology LTC3880
+ Prefix: 'ltc3880'
+ Addresses scanned: -
+ Datasheet: http://cds.linear.com/docs/Datasheet/3880f.pdf
+
+Author: Guenter Roeck <guenter.roeck@ericsson.com>
+
+
+Description
+-----------
+
+The LTC2978 is an octal power supply monitor, supervisor, sequencer and
+margin controller. The LTC3880 is a dual, PolyPhase DC/DC synchronous
+step-down switching regulator controller.
+
+
+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 LTC2978 at address
+0x60 on I2C bus #1:
+
+# modprobe ltc2978
+# echo ltc2978 0x60 > /sys/bus/i2c/devices/i2c-1/new_device
+
+
+Sysfs attributes
+----------------
+
+in1_label "vin"
+in1_input Measured input voltage.
+in1_min Minimum input voltage.
+in1_max Maximum input voltage.
+in1_lcrit Critical minimum input voltage.
+in1_crit Critical maximum input voltage.
+in1_min_alarm Input voltage low alarm.
+in1_max_alarm Input voltage high alarm.
+in1_lcrit_alarm Input voltage critical low alarm.
+in1_crit_alarm Input voltage critical high alarm.
+in1_lowest Lowest input voltage. LTC2978 only.
+in1_highest Highest input voltage.
+in1_reset_history Reset history. Writing into this attribute will reset
+ history for all attributes.
+
+in[2-9]_label "vout[1-8]". Channels 3 to 9 on LTC2978 only.
+in[2-9]_input Measured output voltage.
+in[2-9]_min Minimum output voltage.
+in[2-9]_max Maximum output voltage.
+in[2-9]_lcrit Critical minimum output voltage.
+in[2-9]_crit Critical maximum output voltage.
+in[2-9]_min_alarm Output voltage low alarm.
+in[2-9]_max_alarm Output voltage high alarm.
+in[2-9]_lcrit_alarm Output voltage critical low alarm.
+in[2-9]_crit_alarm Output voltage critical high alarm.
+in[2-9]_lowest Lowest output voltage. LTC2978 only.
+in[2-9]_highest Lowest output voltage.
+in[2-9]_reset_history Reset history. Writing into this attribute will reset
+ history for all attributes.
+
+temp[1-3]_input Measured temperature.
+ On LTC2978, only one temperature measurement is
+ supported and reflects the internal temperature.
+ On LTC3880, temp1 and temp2 report external
+ temperatures, and temp3 reports the internal
+ temperature.
+temp[1-3]_min Mimimum temperature.
+temp[1-3]_max Maximum temperature.
+temp[1-3]_lcrit Critical low temperature.
+temp[1-3]_crit Critical high temperature.
+temp[1-3]_min_alarm Chip temperature low alarm.
+temp[1-3]_max_alarm Chip temperature high alarm.
+temp[1-3]_lcrit_alarm Chip temperature critical low alarm.
+temp[1-3]_crit_alarm Chip temperature critical high alarm.
+temp[1-3]_lowest Lowest measured temperature. LTC2978 only.
+temp[1-3]_highest Highest measured temperature.
+temp[1-3]_reset_history Reset history. Writing into this attribute will reset
+ history for all attributes.
+
+power[1-2]_label "pout[1-2]". LTC3880 only.
+power[1-2]_input Measured power.
+
+curr1_label "iin". LTC3880 only.
+curr1_input Measured input current.
+curr1_max Maximum input current.
+curr1_max_alarm Input current high alarm.
+
+curr[2-3]_label "iout[1-2]". LTC3880 only.
+curr[2-3]_input Measured input current.
+curr[2-3]_max Maximum input current.
+curr[2-3]_crit Critical input current.
+curr[2-3]_max_alarm Input current high alarm.
+curr[2-3]_crit_alarm Input current critical high alarm.
diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus
index c36c1c1a62bb..15ac911ce51b 100644
--- a/Documentation/hwmon/pmbus
+++ b/Documentation/hwmon/pmbus
@@ -8,11 +8,6 @@ Supported chips:
Addresses scanned: -
Datasheet:
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146395
- * Linear Technology LTC2978
- Octal PMBus Power Supply Monitor and Controller
- Prefix: 'ltc2978'
- Addresses scanned: -
- Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
* ON Semiconductor ADP4000, NCP4200, NCP4208
Prefixes: 'adp4000', 'ncp4200', 'ncp4208'
Addresses scanned: -
@@ -20,6 +15,14 @@ Supported chips:
http://www.onsemi.com/pub_link/Collateral/ADP4000-D.PDF
http://www.onsemi.com/pub_link/Collateral/NCP4200-D.PDF
http://www.onsemi.com/pub_link/Collateral/JUNE%202009-%20REV.%200.PDF
+ * Lineage Power
+ Prefixes: 'pdt003', 'pdt006', 'pdt012', 'udt020'
+ Addresses scanned: -
+ Datasheets:
+ http://www.lineagepower.com/oem/pdf/PDT003A0X.pdf
+ http://www.lineagepower.com/oem/pdf/PDT006A0X.pdf
+ http://www.lineagepower.com/oem/pdf/PDT012A0X.pdf
+ http://www.lineagepower.com/oem/pdf/UDT020A0X.pdf
* Generic PMBus devices
Prefix: 'pmbus'
Addresses scanned: -
diff --git a/Documentation/hwmon/pmbus-core b/Documentation/hwmon/pmbus-core
new file mode 100644
index 000000000000..31e4720fed18
--- /dev/null
+++ b/Documentation/hwmon/pmbus-core
@@ -0,0 +1,283 @@
+PMBus core driver and internal API
+==================================
+
+Introduction
+============
+
+[from pmbus.org] The Power Management Bus (PMBus) is an open standard
+power-management protocol with a fully defined command language that facilitates
+communication with power converters and other devices in a power system. The
+protocol is implemented over the industry-standard SMBus serial interface and
+enables programming, control, and real-time monitoring of compliant power
+conversion products. This flexible and highly versatile standard allows for
+communication between devices based on both analog and digital technologies, and
+provides true interoperability which will reduce design complexity and shorten
+time to market for power system designers. Pioneered by leading power supply and
+semiconductor companies, this open power system standard is maintained and
+promoted by the PMBus Implementers Forum (PMBus-IF), comprising 30+ adopters
+with the objective to provide support to, and facilitate adoption among, users.
+
+Unfortunately, while PMBus commands are standardized, there are no mandatory
+commands, and manufacturers can add as many non-standard commands as they like.
+Also, different PMBUs devices act differently if non-supported commands are
+executed. Some devices return an error, some devices return 0xff or 0xffff and
+set a status error flag, and some devices may simply hang up.
+
+Despite all those difficulties, a generic PMBus device driver is still useful
+and supported since kernel version 2.6.39. However, it was necessary to support
+device specific extensions in addition to the core PMBus driver, since it is
+simply unknown what new device specific functionality PMBus device developers
+come up with next.
+
+To make device specific extensions as scalable as possible, and to avoid having
+to modify the core PMBus driver repeatedly for new devices, the PMBus driver was
+split into core, generic, and device specific code. The core code (in
+pmbus_core.c) provides generic functionality. The generic code (in pmbus.c)
+provides support for generic PMBus devices. Device specific code is responsible
+for device specific initialization and, if needed, maps device specific
+functionality into generic functionality. This is to some degree comparable
+to PCI code, where generic code is augmented as needed with quirks for all kinds
+of devices.
+
+PMBus device capabilities auto-detection
+========================================
+
+For generic PMBus devices, code in pmbus.c attempts to auto-detect all supported
+PMBus commands. Auto-detection is somewhat limited, since there are simply too
+many variables to consider. For example, it is almost impossible to autodetect
+which PMBus commands are paged and which commands are replicated across all
+pages (see the PMBus specification for details on multi-page PMBus devices).
+
+For this reason, it often makes sense to provide a device specific driver if not
+all commands can be auto-detected. The data structures in this driver can be
+used to inform the core driver about functionality supported by individual
+chips.
+
+Some commands are always auto-detected. This applies to all limit commands
+(lcrit, min, max, and crit attributes) as well as associated alarm attributes.
+Limits and alarm attributes are auto-detected because there are simply too many
+possible combinations to provide a manual configuration interface.
+
+PMBus internal API
+==================
+
+The API between core and device specific PMBus code is defined in
+drivers/hwmon/pmbus/pmbus.h. In addition to the internal API, pmbus.h defines
+standard PMBus commands and virtual PMBus commands.
+
+Standard PMBus commands
+-----------------------
+
+Standard PMBus commands (commands values 0x00 to 0xff) are defined in the PMBUs
+specification.
+
+Virtual PMBus commands
+----------------------
+
+Virtual PMBus commands are provided to enable support for non-standard
+functionality which has been implemented by several chip vendors and is thus
+desirable to support.
+
+Virtual PMBus commands start with command value 0x100 and can thus easily be
+distinguished from standard PMBus commands (which can not have values larger
+than 0xff). Support for virtual PMBus commands is device specific and thus has
+to be implemented in device specific code.
+
+Virtual commands are named PMBUS_VIRT_xxx and start with PMBUS_VIRT_BASE. All
+virtual commands are word sized.
+
+There are currently two types of virtual commands.
+
+- READ commands are read-only; writes are either ignored or return an error.
+- RESET commands are read/write. Reading reset registers returns zero
+ (used for detection), writing any value causes the associated history to be
+ reset.
+
+Virtual commands have to be handled in device specific driver code. Chip driver
+code returns non-negative values if a virtual command is supported, or a
+negative error code if not. The chip driver may return -ENODATA or any other
+Linux error code in this case, though an error code other than -ENODATA is
+handled more efficiently and thus preferred. Either case, the calling PMBus
+core code will abort if the chip driver returns an error code when reading
+or writing virtual registers (in other words, the PMBus core code will never
+send a virtual command to a chip).
+
+PMBus driver information
+------------------------
+
+PMBus driver information, defined in struct pmbus_driver_info, is the main means
+for device specific drivers to pass information to the core PMBus driver.
+Specifically, it provides the following information.
+
+- For devices supporting its data in Direct Data Format, it provides coefficients
+ for converting register values into normalized data. This data is usually
+ provided by chip manufacturers in device datasheets.
+- Supported chip functionality can be provided to the core driver. This may be
+ necessary for chips which react badly if non-supported commands are executed,
+ and/or to speed up device detection and initialization.
+- Several function entry points are provided to support overriding and/or
+ augmenting generic command execution. This functionality can be used to map
+ non-standard PMBus commands to standard commands, or to augment standard
+ command return values with device specific information.
+
+ API functions
+ -------------
+
+ Functions provided by chip driver
+ ---------------------------------
+
+ All functions return the command return value (read) or zero (write) if
+ successful. A return value of -ENODATA indicates that there is no manufacturer
+ specific command, but that a standard PMBus command may exist. Any other
+ negative return value indicates that the commands does not exist for this
+ chip, and that no attempt should be made to read or write the standard
+ command.
+
+ As mentioned above, an exception to this rule applies to virtual commands,
+ which _must_ be handled in driver specific code. See "Virtual PMBus Commands"
+ above for more details.
+
+ Command execution in the core PMBus driver code is as follows.
+
+ if (chip_access_function) {
+ status = chip_access_function();
+ if (status != -ENODATA)
+ return status;
+ }
+ if (command >= PMBUS_VIRT_BASE) /* For word commands/registers only */
+ return -EINVAL;
+ return generic_access();
+
+ Chip drivers may provide pointers to the following functions in struct
+ pmbus_driver_info. All functions are optional.
+
+ int (*read_byte_data)(struct i2c_client *client, int page, int reg);
+
+ Read byte from page <page>, register <reg>.
+ <page> may be -1, which means "current page".
+
+ int (*read_word_data)(struct i2c_client *client, int page, int reg);
+
+ Read word from page <page>, register <reg>.
+
+ int (*write_word_data)(struct i2c_client *client, int page, int reg,
+ u16 word);
+
+ Write word to page <page>, register <reg>.
+
+ int (*write_byte)(struct i2c_client *client, int page, u8 value);
+
+ Write byte to page <page>, register <reg>.
+ <page> may be -1, which means "current page".
+
+ int (*identify)(struct i2c_client *client, struct pmbus_driver_info *info);
+
+ Determine supported PMBus functionality. This function is only necessary
+ if a chip driver supports multiple chips, and the chip functionality is not
+ pre-determined. It is currently only used by the generic pmbus driver
+ (pmbus.c).
+
+ Functions exported by core driver
+ ---------------------------------
+
+ Chip drivers are expected to use the following functions to read or write
+ PMBus registers. Chip drivers may also use direct I2C commands. If direct I2C
+ commands are used, the chip driver code must not directly modify the current
+ page, since the selected page is cached in the core driver and the core driver
+ will assume that it is selected. Using pmbus_set_page() to select a new page
+ is mandatory.
+
+ int pmbus_set_page(struct i2c_client *client, u8 page);
+
+ Set PMBus page register to <page> for subsequent commands.
+
+ int pmbus_read_word_data(struct i2c_client *client, u8 page, u8 reg);
+
+ Read word data from <page>, <reg>. Similar to i2c_smbus_read_word_data(), but
+ selects page first.
+
+ int pmbus_write_word_data(struct i2c_client *client, u8 page, u8 reg,
+ u16 word);
+
+ Write word data to <page>, <reg>. Similar to i2c_smbus_write_word_data(), but
+ selects page first.
+
+ int pmbus_read_byte_data(struct i2c_client *client, int page, u8 reg);
+
+ Read byte data from <page>, <reg>. Similar to i2c_smbus_read_byte_data(), but
+ selects page first. <page> may be -1, which means "current page".
+
+ int pmbus_write_byte(struct i2c_client *client, int page, u8 value);
+
+ Write byte data to <page>, <reg>. Similar to i2c_smbus_write_byte(), but
+ selects page first. <page> may be -1, which means "current page".
+
+ void pmbus_clear_faults(struct i2c_client *client);
+
+ Execute PMBus "Clear Fault" command on all chip pages.
+ This function calls the device specific write_byte function if defined.
+ Therefore, it must _not_ be called from that function.
+
+ bool pmbus_check_byte_register(struct i2c_client *client, int page, int reg);
+
+ Check if byte register exists. Return true if the register exists, false
+ otherwise.
+ This function calls the device specific write_byte function if defined to
+ obtain the chip status. Therefore, it must _not_ be called from that function.
+
+ bool pmbus_check_word_register(struct i2c_client *client, int page, int reg);
+
+ Check if word register exists. Return true if the register exists, false
+ otherwise.
+ This function calls the device specific write_byte function if defined to
+ obtain the chip status. Therefore, it must _not_ be called from that function.
+
+ int pmbus_do_probe(struct i2c_client *client, const struct i2c_device_id *id,
+ struct pmbus_driver_info *info);
+
+ Execute probe function. Similar to standard probe function for other drivers,
+ with the pointer to struct pmbus_driver_info as additional argument. Calls
+ identify function if supported. Must only be called from device probe
+ function.
+
+ void pmbus_do_remove(struct i2c_client *client);
+
+ Execute driver remove function. Similar to standard driver remove function.
+
+ const struct pmbus_driver_info
+ *pmbus_get_driver_info(struct i2c_client *client);
+
+ Return pointer to struct pmbus_driver_info as passed to pmbus_do_probe().
+
+
+PMBus driver platform data
+==========================
+
+PMBus platform data is defined in include/linux/i2c/pmbus.h. Platform data
+currently only provides a flag field with a single bit used.
+
+#define PMBUS_SKIP_STATUS_CHECK (1 << 0)
+
+struct pmbus_platform_data {
+ u32 flags; /* Device specific flags */
+};
+
+
+Flags
+-----
+
+PMBUS_SKIP_STATUS_CHECK
+
+During register detection, skip checking the status register for
+communication or command errors.
+
+Some PMBus chips respond with valid data when trying to read an unsupported
+register. For such chips, checking the status register is mandatory when
+trying to determine if a chip register exists or not.
+Other PMBus chips don't support the STATUS_CML register, or report
+communication errors for no explicable reason. For such chips, checking the
+status register must be disabled.
+
+Some i2c controllers do not support single-byte commands (write commands with
+no data, i2c_smbus_write_byte()). With such controllers, clearing the status
+register is impossible, and the PMBUS_SKIP_STATUS_CHECK flag must be set.
diff --git a/Documentation/hwmon/zl6100 b/Documentation/hwmon/zl6100
new file mode 100644
index 000000000000..7617798b5c97
--- /dev/null
+++ b/Documentation/hwmon/zl6100
@@ -0,0 +1,125 @@
+Kernel driver zl6100
+====================
+
+Supported chips:
+ * Intersil / Zilker Labs ZL2004
+ Prefix: 'zl2004'
+ Addresses scanned: -
+ Datasheet: http://www.intersil.com/data/fn/fn6847.pdf
+ * Intersil / Zilker Labs ZL2006
+ Prefix: 'zl2006'
+ Addresses scanned: -
+ Datasheet: http://www.intersil.com/data/fn/fn6850.pdf
+ * Intersil / Zilker Labs ZL2008
+ Prefix: 'zl2008'
+ Addresses scanned: -
+ Datasheet: http://www.intersil.com/data/fn/fn6859.pdf
+ * Intersil / Zilker Labs ZL2105
+ Prefix: 'zl2105'
+ Addresses scanned: -
+ Datasheet: http://www.intersil.com/data/fn/fn6851.pdf
+ * Intersil / Zilker Labs ZL2106
+ Prefix: 'zl2106'
+ Addresses scanned: -
+ Datasheet: http://www.intersil.com/data/fn/fn6852.pdf
+ * Intersil / Zilker Labs ZL6100
+ Prefix: 'zl6100'
+ Addresses scanned: -
+ Datasheet: http://www.intersil.com/data/fn/fn6876.pdf
+ * Intersil / Zilker Labs ZL6105
+ Prefix: 'zl6105'
+ Addresses scanned: -
+ Datasheet: http://www.intersil.com/data/fn/fn6906.pdf
+
+Author: Guenter Roeck <guenter.roeck@ericsson.com>
+
+
+Description
+-----------
+
+This driver supports hardware montoring for Intersil / Zilker Labs ZL6100 and
+compatible digital DC-DC controllers.
+
+The driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus and Documentation.hwmon/pmbus-core for details
+on PMBus client drivers.
+
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
+
+WARNING: Do not access chip registers using the i2cdump command, and do not use
+any of the i2ctools commands on a command register used to save and restore
+configuration data (0x11, 0x12, 0x15, 0x16, and 0xf4). The chips supported by
+this driver interpret any access to those command registers (including read
+commands) as request to execute the command in question. Unless write accesses
+to those registers are protected, this may result in power loss, board resets,
+and/or Flash corruption. Worst case, your board may turn into a brick.
+
+
+Platform data support
+---------------------
+
+The driver supports standard PMBus driver platform data.
+
+
+Module parameters
+-----------------
+
+delay
+-----
+
+Some Intersil/Zilker Labs DC-DC controllers require a minimum interval between
+I2C bus accesses. According to Intersil, the minimum interval is 2 ms, though
+1 ms appears to be sufficient and has not caused any problems in testing.
+The problem is known to affect ZL6100, ZL2105, and ZL2008. It is known not to
+affect ZL2004 and ZL6105. The driver automatically sets the interval to 1 ms
+except for ZL2004 and ZL6105. To enable manual override, the driver provides a
+writeable module parameter, 'delay', which can be used to set the interval to
+a value between 0 and 65,535 microseconds.
+
+
+Sysfs entries
+-------------
+
+The following attributes are supported. Limits are read-write; all other
+attributes are read-only.
+
+in1_label "vin"
+in1_input Measured input voltage.
+in1_min Minimum input voltage.
+in1_max Maximum input voltage.
+in1_lcrit Critical minumum input voltage.
+in1_crit Critical maximum input voltage.
+in1_min_alarm Input voltage low alarm.
+in1_max_alarm Input voltage high alarm.
+in1_lcrit_alarm Input voltage critical low alarm.
+in1_crit_alarm Input voltage critical high alarm.
+
+in2_label "vout1"
+in2_input Measured output voltage.
+in2_lcrit Critical minumum output Voltage.
+in2_crit Critical maximum output voltage.
+in2_lcrit_alarm Critical output voltage critical low alarm.
+in2_crit_alarm Critical output voltage critical high alarm.
+
+curr1_label "iout1"
+curr1_input Measured output current.
+curr1_lcrit Critical minimum output current.
+curr1_crit Critical maximum output current.
+curr1_lcrit_alarm Output current critical low alarm.
+curr1_crit_alarm Output current critical high alarm.
+
+temp[12]_input Measured temperature.
+temp[12]_min Minimum temperature.
+temp[12]_max Maximum temperature.
+temp[12]_lcrit Critical low temperature.
+temp[12]_crit Critical high temperature.
+temp[12]_min_alarm Chip temperature low alarm.
+temp[12]_max_alarm Chip temperature high alarm.
+temp[12]_lcrit_alarm Chip temperature critical low alarm.
+temp[12]_crit_alarm Chip temperature critical high alarm.