diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/hwmon/ad7314 | 25 | ||||
| -rw-r--r-- | Documentation/hwmon/adm1275 | 40 | ||||
| -rw-r--r-- | Documentation/hwmon/exynos4_tmu | 81 | ||||
| -rw-r--r-- | Documentation/hwmon/lm75 | 61 | ||||
| -rw-r--r-- | Documentation/hwmon/ltc2978 | 103 | ||||
| -rw-r--r-- | Documentation/hwmon/pmbus | 13 | ||||
| -rw-r--r-- | Documentation/hwmon/pmbus-core | 283 | ||||
| -rw-r--r-- | Documentation/hwmon/zl6100 | 125 |
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. |