Commit 7f15b664 authored by R.Marek@sh.cvut.cz's avatar R.Marek@sh.cvut.cz Committed by Greg Kroah-Hartman

[PATCH] I2C: documentation update 2/3

This patch adds missing documentation for system health monitoring chips.
I would like to thank all people, who helped me with this project.
Signed-off-by: default avatarRudolf Marek <r.marek@sh.cvut.cz>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
parent 2bf34a1c
Kernel driver adm1021
=====================
Supported chips:
* Analog Devices ADM1021
Prefix: 'adm1021'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Analog Devices website
* Analog Devices ADM1021A/ADM1023
Prefix: 'adm1023'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Analog Devices website
* Genesys Logic GL523SM
Prefix: 'gl523sm'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet:
* Intel Xeon Processor
Prefix: - any other - may require 'force_adm1021' parameter
Addresses scanned: none
Datasheet: Publicly available at Intel website
* Maxim MAX1617
Prefix: 'max1617'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Maxim website
* Maxim MAX1617A
Prefix: 'max1617a'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Maxim website
* National Semiconductor LM84
Prefix: 'lm84'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the National Semiconductor website
* Philips NE1617
Prefix: 'max1617' (probably detected as a max1617)
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Philips website
* Philips NE1617A
Prefix: 'max1617' (probably detected as a max1617)
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Philips website
* TI THMC10
Prefix: 'thmc10'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the TI website
* Onsemi MC1066
Prefix: 'mc1066'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the Onsemi website
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>
Module Parameters
-----------------
* read_only: int
Don't set any values, read only mode
Description
-----------
The chips supported by this driver are very similar. The Maxim MAX1617 is
the oldest; it has the problem that it is not very well detectable. The
MAX1617A solves that. The ADM1021 is a straight clone of the MAX1617A.
Ditto for the THMC10. From here on, we will refer to all these chips as
ADM1021-clones.
The ADM1021 and MAX1617A reports a die code, which is a sort of revision
code. This can help us pinpoint problems; it is not very useful
otherwise.
ADM1021-clones implement two temperature sensors. One of them is internal,
and measures the temperature of the chip itself; the other is external and
is realised in the form of a transistor-like device. A special alarm
indicates whether the remote sensor is connected.
Each sensor has its own low and high limits. When they are crossed, the
corresponding alarm is set and remains on as long as the temperature stays
out of range. Temperatures are measured in degrees Celsius. Measurements
are possible between -65 and +127 degrees, with a resolution of one degree.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may already
have disappeared!
This driver only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values. It is possible to make
ADM1021-clones do faster measurements, but there is really no good reason
for that.
Xeon support
------------
Some Xeon processors have real max1617, adm1021, or compatible chips
within them, with two temperature sensors.
Other Xeons have chips with only one sensor.
If you have a Xeon, and the adm1021 module loads, and both temperatures
appear valid, then things are good.
If the adm1021 module doesn't load, you should try this:
modprobe adm1021 force_adm1021=BUS,ADDRESS
ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
If you have dual Xeons you may have appear to have two separate
adm1021-compatible chips, or two single-temperature sensors, at distinct
addresses.
Kernel driver adm1025
=====================
Supported chips:
* Analog Devices ADM1025, ADM1025A
Prefix: 'adm1025'
Addresses scanned: I2C 0x2c - 0x2e
Datasheet: Publicly available at the Analog Devices website
* Philips NE1619
Prefix: 'ne1619'
Addresses scanned: I2C 0x2c - 0x2d
Datasheet: Publicly available at the Philips website
The NE1619 presents some differences with the original ADM1025:
* Only two possible addresses (0x2c - 0x2d).
* No temperature offset register, but we don't use it anyway.
* No INT mode for pin 16. We don't play with it anyway.
Authors:
Chen-Yuan Wu <gwu@esoft.com>,
Jean Delvare <khali@linux-fr.org>
Description
-----------
(This is from Analog Devices.) The ADM1025 is a complete system hardware
monitor for microprocessor-based systems, providing measurement and limit
comparison of various system parameters. Five voltage measurement inputs
are provided, for monitoring +2.5V, +3.3V, +5V and +12V power supplies and
the processor core voltage. The ADM1025 can monitor a sixth power-supply
voltage by measuring its own VCC. One input (two pins) is dedicated to a
remote temperature-sensing diode and an on-chip temperature sensor allows
ambient temperature to be monitored.
One specificity of this chip is that the pin 11 can be hardwired in two
different manners. It can act as the +12V power-supply voltage analog
input, or as the a fifth digital entry for the VID reading (bit 4). It's
kind of strange since both are useful, and the reason for designing the
chip that way is obscure at least to me. The bit 5 of the configuration
register can be used to define how the chip is hardwired. Please note that
it is not a choice you have to make as the user. The choice was already
made by your motherboard's maker. If the configuration bit isn't set
properly, you'll have a wrong +12V reading or a wrong VID reading. The way
the driver handles that is to preserve this bit through the initialization
process, assuming that the BIOS set it up properly beforehand. If it turns
out not to be true in some cases, we'll provide a module parameter to force
modes.
This driver also supports the ADM1025A, which differs from the ADM1025
only in that it has "open-drain VID inputs while the ADM1025 has on-chip
100k pull-ups on the VID inputs". It doesn't make any difference for us.
Kernel driver adm1026
=====================
Supported chips:
* Analog Devices ADM1026
Prefix: 'adm1026'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/en/prod/0,,766_825_ADM1026,00.html
Authors:
Philip Pokorny <ppokorny@penguincomputing.com> for Penguin Computing
Justin Thiessen <jthiessen@penguincomputing.com>
Module Parameters
-----------------
* gpio_input: int array (min = 1, max = 17)
List of GPIO pins (0-16) to program as inputs
* gpio_output: int array (min = 1, max = 17)
List of GPIO pins (0-16) to program as outputs
* gpio_inverted: int array (min = 1, max = 17)
List of GPIO pins (0-16) to program as inverted
* gpio_normal: int array (min = 1, max = 17)
List of GPIO pins (0-16) to program as normal/non-inverted
* gpio_fan: int array (min = 1, max = 8)
List of GPIO pins (0-7) to program as fan tachs
Description
-----------
This driver implements support for the Analog Devices ADM1026. Analog
Devices calls it a "complete thermal system management controller."
The ADM1026 implements three (3) temperature sensors, 17 voltage sensors,
16 general purpose digital I/O lines, eight (8) fan speed sensors (8-bit),
an analog output and a PWM output along with limit, alarm and mask bits for
all of the above. There is even 8k bytes of EEPROM memory on chip.
Temperatures are measured in degrees Celsius. There are two external
sensor inputs and one internal sensor. Each sensor has a high and low
limit. If the limit is exceeded, an interrupt (#SMBALERT) can be
generated. The interrupts can be masked. In addition, there are over-temp
limits for each sensor. If this limit is exceeded, the #THERM output will
be asserted. The current temperature and limits have a resolution of 1
degree.
Fan rotation speeds are reported in RPM (rotations per minute) but measured
in counts of a 22.5kHz internal clock. Each fan has a high limit which
corresponds to a minimum fan speed. If the limit is exceeded, an interrupt
can be generated. Each fan can be programmed to divide the reference clock
by 1, 2, 4 or 8. Not all RPM values can accurately be represented, so some
rounding is done. With a divider of 8, the slowest measurable speed of a
two pulse per revolution fan is 661 RPM.
There are 17 voltage sensors. An alarm is triggered if the voltage has
crossed a programmable minimum or maximum limit. Note that minimum in this
case always means 'closest to zero'; this is important for negative voltage
measurements. Several inputs have integrated attenuators so they can measure
higher voltages directly. 3.3V, 5V, 12V, -12V and battery voltage all have
dedicated inputs. There are several inputs scaled to 0-3V full-scale range
for SCSI terminator power. The remaining inputs are not scaled and have
a 0-2.5V full-scale range. A 2.5V or 1.82V reference voltage is provided
for negative voltage measurements.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may already
have disappeared! Note that in the current implementation, all hardware
registers are read whenever any data is read (unless it is less than 2.0
seconds since the last update). This means that you can easily miss
once-only alarms.
The ADM1026 measures continuously. Analog inputs are measured about 4
times a second. Fan speed measurement time depends on fan speed and
divisor. It can take as long as 1.5 seconds to measure all fan speeds.
The ADM1026 has the ability to automatically control fan speed based on the
temperature sensor inputs. Both the PWM output and the DAC output can be
used to control fan speed. Usually only one of these two outputs will be
used. Write the minimum PWM or DAC value to the appropriate control
register. Then set the low temperature limit in the tmin values for each
temperature sensor. The range of control is fixed at 20 °C, and the
largest difference between current and tmin of the temperature sensors sets
the control output. See the datasheet for several example circuits for
controlling fan speed with the PWM and DAC outputs. The fan speed sensors
do not have PWM compensation, so it is probably best to control the fan
voltage from the power lead rather than on the ground lead.
The datasheet shows an example application with VID signals attached to
GPIO lines. Unfortunately, the chip may not be connected to the VID lines
in this way. The driver assumes that the chips *is* connected this way to
get a VID voltage.
Kernel driver adm1031
=====================
Supported chips:
* Analog Devices ADM1030
Prefix: 'adm1030'
Addresses scanned: I2C 0x2c to 0x2e
Datasheet: Publicly available at the Analog Devices website
http://products.analog.com/products/info.asp?product=ADM1030
* Analog Devices ADM1031
Prefix: 'adm1031'
Addresses scanned: I2C 0x2c to 0x2e
Datasheet: Publicly available at the Analog Devices website
http://products.analog.com/products/info.asp?product=ADM1031
Authors:
Alexandre d'Alton <alex@alexdalton.org>
Jean Delvare <khali@linux-fr.org>
Description
-----------
The ADM1030 and ADM1031 are digital temperature sensors and fan controllers.
They sense their own temperature as well as the temperature of up to one
(ADM1030) or two (ADM1031) external diodes.
All temperature values are given in degrees Celsius. Resolution is 0.5
degree for the local temperature, 0.125 degree for the remote temperatures.
Each temperature channel has its own high and low limits, plus a critical
limit.
The ADM1030 monitors a single fan speed, while the ADM1031 monitors up to
two. Each fan channel has its own low speed limit.
Kernel driver asb100
====================
Supported Chips:
* Asus ASB100 and ASB100-A "Bach"
Prefix: 'asb100'
Addresses scanned: I2C 0x2d
Datasheet: none released
Author: Mark M. Hoffman <mhoffman@lightlink.com>
Description
-----------
This driver implements support for the Asus ASB100 and ASB100-A "Bach".
These are custom ASICs available only on Asus mainboards. Asus refuses to
supply a datasheet for these chips. Thanks go to many people who helped
investigate their hardware, including:
Vitaly V. Bursov
Alexander van Kaam (author of MBM for Windows)
Bertrik Sikken
The ASB100 implements seven voltage sensors, three fan rotation speed
sensors, four temperature sensors, VID lines and alarms. In addition to
these, the ASB100-A also implements a single PWM controller for fans 2 and
3 (i.e. one setting controls both.) If you have a plain ASB100, the PWM
controller will simply not work (or maybe it will for you... it doesn't for
me).
Temperatures are measured and reported in degrees Celsius.
Fan speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit.
Voltage sensors (also known as IN sensors) report values in volts.
The VID lines encode the core voltage value: the voltage level your
processor should work with. This is hardcoded by the mainboard and/or
processor itself. It is a value in volts.
Alarms: (TODO question marks indicate may or may not work)
0x0001 => in0 (?)
0x0002 => in1 (?)
0x0004 => in2
0x0008 => in3
0x0010 => temp1 (1)
0x0020 => temp2
0x0040 => fan1
0x0080 => fan2
0x0100 => in4
0x0200 => in5 (?) (2)
0x0400 => in6 (?) (2)
0x0800 => fan3
0x1000 => chassis switch
0x2000 => temp3
Alarm Notes:
(1) This alarm will only trigger if the hysteresis value is 127C.
I.e. it behaves the same as w83781d.
(2) The min and max registers for these values appear to
be read-only or otherwise stuck at 0x00.
TODO:
* Experiment with fan divisors > 8.
* Experiment with temp. sensor types.
* Are there really 13 voltage inputs? Probably not...
* Cleanups, no doubt...
Kernel driver ds1621
====================
Supported chips:
* Dallas Semiconductor DS1621
Prefix: 'ds1621'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.dalsemi.com/
* Dallas Semiconductor DS1625
Prefix: 'ds1621'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.dalsemi.com/
Authors:
Christian W. Zuckschwerdt <zany@triq.net>
valuable contributions by Jan M. Sendler <sendler@sendler.de>
ported to 2.6 by Aurelien Jarno <aurelien@aurel32.net>
with the help of Jean Delvare <khali@linux-fr.org>
Module Parameters
------------------
* polarity int
Output's polarity: 0 = active high, 1 = active low
Description
-----------
The DS1621 is a (one instance) digital thermometer and thermostat. It has
both high and low temperature limits which can be user defined (i.e.
programmed into non-volatile on-chip registers). Temperature range is -55
degree Celsius to +125 in 0.5 increments. You may convert this into a
Fahrenheit range of -67 to +257 degrees with 0.9 steps. If polarity
parameter is not provided, original value is used.
As for the thermostat, behavior can also be programmed using the polarity
toggle. On the one hand ("heater"), the thermostat output of the chip,
Tout, will trigger when the low limit temperature is met or underrun and
stays high until the high limit is met or exceeded. On the other hand
("cooler"), vice versa. That way "heater" equals "active low", whereas
"conditioner" equals "active high". Please note that the DS1621 data sheet
is somewhat misleading in this point since setting the polarity bit does
not simply invert Tout.
A second thing is that, during extensive testing, Tout showed a tolerance
of up to +/- 0.5 degrees even when compared against precise temperature
readings. Be sure to have a high vs. low temperature limit gap of al least
1.0 degree Celsius to avoid Tout "bouncing", though!
As for alarms, you can read the alarm status of the DS1621 via the 'alarms'
/sys file interface. The result consists mainly of bit 6 and 5 of the
configuration register of the chip; bit 6 (0x40 or 64) is the high alarm
bit and bit 5 (0x20 or 32) the low one. These bits are set when the high or
low limits are met or exceeded and are reset by the module as soon as the
respective temperature ranges are left.
The alarm registers are in no way suitable to find out about the actual
status of Tout. They will only tell you about its history, whether or not
any of the limits have ever been met or exceeded since last power-up or
reset. Be aware: When testing, it showed that the status of Tout can change
with neither of the alarms set.
Temperature conversion of the DS1621 takes up to 1000ms; internal access to
non-volatile registers may last for 10ms or below.
High Accuracy Temperature Reading
---------------------------------
As said before, the temperature issued via the 9-bit i2c-bus data is
somewhat arbitrary. Internally, the temperature conversion is of a
different kind that is explained (not so...) well in the DS1621 data sheet.
To cut the long story short: Inside the DS1621 there are two oscillators,
both of them biassed by a temperature coefficient.
Higher resolution of the temperature reading can be achieved using the
internal projection, which means taking account of REG_COUNT and REG_SLOPE
(the driver manages them):
Taken from Dallas Semiconductors App Note 068: 'Increasing Temperature
Resolution on the DS1620' and App Note 105: 'High Resolution Temperature
Measurement with Dallas Direct-to-Digital Temperature Sensors'
- Read the 9-bit temperature and strip the LSB (Truncate the .5 degs)
- The resulting value is TEMP_READ.
- Then, read REG_COUNT.
- And then, REG_SLOPE.
TEMP = TEMP_READ - 0.25 + ((REG_SLOPE - REG_COUNT) / REG_SLOPE)
Note that this is what the DONE bit in the DS1621 configuration register is
good for: Internally, one temperature conversion takes up to 1000ms. Before
that conversion is complete you will not be able to read valid things out
of REG_COUNT and REG_SLOPE. The DONE bit, as you may have guessed by now,
tells you whether the conversion is complete ("done", in plain English) and
thus, whether the values you read are good or not.
The DS1621 has two modes of operation: "Continuous" conversion, which can
be understood as the default stand-alone mode where the chip gets the
temperature and controls external devices via its Tout pin or tells other
i2c's about it if they care. The other mode is called "1SHOT", that means
that it only figures out about the temperature when it is explicitly told
to do so; this can be seen as power saving mode.
Now if you want to read REG_COUNT and REG_SLOPE, you have to either stop
the continuous conversions until the contents of these registers are valid,
or, in 1SHOT mode, you have to have one conversion made.
Kernel driver eeprom
====================
Supported chips:
* Any EEPROM chip in the designated address range
Prefix: 'eeprom'
Addresses scanned: I2C 0x50 - 0x57
Datasheets: Publicly available from:
Atmel (www.atmel.com),
Catalyst (www.catsemi.com),
Fairchild (www.fairchildsemi.com),
Microchip (www.microchip.com),
Philips (www.semiconductor.philips.com),
Rohm (www.rohm.com),
ST (www.st.com),
Xicor (www.xicor.com),
and others.
Chip Size (bits) Address
24C01 1K 0x50 (shadows at 0x51 - 0x57)
24C01A 1K 0x50 - 0x57 (Typical device on DIMMs)
24C02 2K 0x50 - 0x57
24C04 4K 0x50, 0x52, 0x54, 0x56
(additional data at 0x51, 0x53, 0x55, 0x57)
24C08 8K 0x50, 0x54 (additional data at 0x51, 0x52,
0x53, 0x55, 0x56, 0x57)
24C16 16K 0x50 (additional data at 0x51 - 0x57)
Sony 2K 0x57
Atmel 34C02B 2K 0x50 - 0x57, SW write protect at 0x30-37
Catalyst 34FC02 2K 0x50 - 0x57, SW write protect at 0x30-37
Catalyst 34RC02 2K 0x50 - 0x57, SW write protect at 0x30-37
Fairchild 34W02 2K 0x50 - 0x57, SW write protect at 0x30-37
Microchip 24AA52 2K 0x50 - 0x57, SW write protect at 0x30-37
ST M34C02 2K 0x50 - 0x57, SW write protect at 0x30-37
Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Jean Delvare <khali@linux-fr.org>,
Greg Kroah-Hartman <greg@kroah.com>,
IBM Corp.
Description
-----------
This is a simple EEPROM module meant to enable reading the first 256 bytes
of an EEPROM (on a SDRAM DIMM for example). However, it will access serial
EEPROMs on any I2C adapter. The supported devices are generically called
24Cxx, and are listed above; however the numbering for these
industry-standard devices may vary by manufacturer.
This module was a programming exercise to get used to the new project
organization laid out by Frodo, but it should be at least completely
effective for decoding the contents of EEPROMs on DIMMs.
DIMMS will typically contain a 24C01A or 24C02, or the 34C02 variants.
The other devices will not be found on a DIMM because they respond to more
than one address.
DDC Monitors may contain any device. Often a 24C01, which responds to all 8
addresses, is found.
Recent Sony Vaio laptops have an EEPROM at 0x57. We couldn't get the
specification, so it is guess work and far from being complete.
The Microchip 24AA52/24LCS52, ST M34C02, and others support an additional
software write protect register at 0x30 - 0x37 (0x20 less than the memory
location). The chip responds to "write quick" detection at this address but
does not respond to byte reads. If this register is present, the lower 128
bytes of the memory array are not write protected. Any byte data write to
this address will write protect the memory array permanently, and the
device will no longer respond at the 0x30-37 address. The eeprom driver
does not support this register.
Lacking functionality:
* Full support for larger devices (24C04, 24C08, 24C16). These are not
typically found on a PC. These devices will appear as separate devices at
multiple addresses.
* Support for really large devices (24C32, 24C64, 24C128, 24C256, 24C512).
These devices require two-byte address fields and are not supported.
* Enable Writing. Again, no technical reason why not, but making it easy
to change the contents of the EEPROMs (on DIMMs anyway) also makes it easy
to disable the DIMMs (potentially preventing the computer from booting)
until the values are restored somehow.
Use:
After inserting the module (and any other required SMBus/i2c modules), you
should have some EEPROM directories in /sys/bus/i2c/devices/* of names such
as "0-0050". Inside each of these is a series of files, the eeprom file
contains the binary data from EEPROM.
Kernel driver fscher
====================
Supported chips:
* Fujitsu-Siemens Hermes chip
Prefix: 'fscher'
Addresses scanned: I2C 0x73
Authors:
Reinhard Nissl <rnissl@gmx.de> based on work
from Hermann Jung <hej@odn.de>,
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>
Description
-----------
This driver implements support for the Fujitsu-Siemens Hermes chip. It is
described in the 'Register Set Specification BMC Hermes based Systemboard'
from Fujitsu-Siemens.
The Hermes chip implements a hardware-based system management, e.g. for
controlling fan speed and core voltage. There is also a watchdog counter on
the chip which can trigger an alarm and even shut the system down.
The chip provides three temperature values (CPU, motherboard and
auxiliary), three voltage values (+12V, +5V and battery) and three fans
(power supply, CPU and auxiliary).
Temperatures are measured in degrees Celsius. The resolution is 1 degree.
Fan rotation speeds are reported in RPM (rotations per minute). The value
can be divided by a programmable divider (1, 2 or 4) which is stored on
the chip.
Voltage sensors (also known as "in" sensors) report their values in volts.
All values are reported as final values from the driver. There is no need
for further calculations.
Detailed description
--------------------
Below you'll find a single line description of all the bit values. With
this information, you're able to decode e. g. alarms, wdog, etc. To make
use of the watchdog, you'll need to set the watchdog time and enable the
watchdog. After that it is necessary to restart the watchdog time within
the specified period of time, or a system reset will occur.
* revision
READING & 0xff = 0x??: HERMES revision identification
* alarms
READING & 0x80 = 0x80: CPU throttling active
READING & 0x80 = 0x00: CPU running at full speed
READING & 0x10 = 0x10: software event (see control:1)
READING & 0x10 = 0x00: no software event
READING & 0x08 = 0x08: watchdog event (see wdog:2)
READING & 0x08 = 0x00: no watchdog event
READING & 0x02 = 0x02: thermal event (see temp*:1)
READING & 0x02 = 0x00: no thermal event
READING & 0x01 = 0x01: fan event (see fan*:1)
READING & 0x01 = 0x00: no fan event
READING & 0x13 ! 0x00: ALERT LED is flashing
* control
READING & 0x01 = 0x01: software event
READING & 0x01 = 0x00: no software event
WRITING & 0x01 = 0x01: set software event
WRITING & 0x01 = 0x00: clear software event
* watchdog_control
READING & 0x80 = 0x80: power off on watchdog event while thermal event
READING & 0x80 = 0x00: watchdog power off disabled (just system reset enabled)
READING & 0x40 = 0x40: watchdog timebase 60 seconds (see also wdog:1)
READING & 0x40 = 0x00: watchdog timebase 2 seconds
READING & 0x10 = 0x10: watchdog enabled
READING & 0x10 = 0x00: watchdog disabled
WRITING & 0x80 = 0x80: enable "power off on watchdog event while thermal event"
WRITING & 0x80 = 0x00: disable "power off on watchdog event while thermal event"
WRITING & 0x40 = 0x40: set watchdog timebase to 60 seconds
WRITING & 0x40 = 0x00: set watchdog timebase to 2 seconds
WRITING & 0x20 = 0x20: disable watchdog
WRITING & 0x10 = 0x10: enable watchdog / restart watchdog time
* watchdog_state
READING & 0x02 = 0x02: watchdog system reset occurred
READING & 0x02 = 0x00: no watchdog system reset occurred
WRITING & 0x02 = 0x02: clear watchdog event
* watchdog_preset
READING & 0xff = 0x??: configured watch dog time in units (see wdog:3 0x40)
WRITING & 0xff = 0x??: configure watch dog time in units
* in* (0: +5V, 1: +12V, 2: onboard 3V battery)
READING: actual voltage value
* temp*_status (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor)
READING & 0x02 = 0x02: thermal event (overtemperature)
READING & 0x02 = 0x00: no thermal event
READING & 0x01 = 0x01: sensor is working
READING & 0x01 = 0x00: sensor is faulty
WRITING & 0x02 = 0x02: clear thermal event
* temp*_input (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor)
READING: actual temperature value
* fan*_status (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
READING & 0x04 = 0x04: fan event (fan fault)
READING & 0x04 = 0x00: no fan event
WRITING & 0x04 = 0x04: clear fan event
* fan*_div (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
Divisors 2,4 and 8 are supported, both for reading and writing
* fan*_pwm (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
READING & 0xff = 0x00: fan may be switched off
READING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V)
READING & 0xff = 0xff: fan must run at maximum speed (supply: 12V)
READING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V)
WRITING & 0xff = 0x00: fan may be switched off
WRITING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V)
WRITING & 0xff = 0xff: fan must run at maximum speed (supply: 12V)
WRITING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V)
* fan*_input (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
READING: actual RPM value
Limitations
-----------
* Measuring fan speed
It seems that the chip counts "ripples" (typical fans produce 2 ripples per
rotation while VERAX fans produce 18) in a 9-bit register. This register is
read out every second, then the ripple prescaler (2, 4 or 8) is applied and
the result is stored in the 8 bit output register. Due to the limitation of
the counting register to 9 bits, it is impossible to measure a VERAX fan
properly (even with a prescaler of 8). At its maximum speed of 3500 RPM the
fan produces 1080 ripples per second which causes the counting register to
overflow twice, leading to only 186 RPM.
* Measuring input voltages
in2 ("battery") reports the voltage of the onboard lithium battery and not
+3.3V from the power supply.
* Undocumented features
Fujitsu-Siemens Computers has not documented all features of the chip so
far. Their software, System Guard, shows that there are a still some
features which cannot be controlled by this implementation.
Kernel driver gl518sm
=====================
Supported chips:
* Genesys Logic GL518SM release 0x00
Prefix: 'gl518sm'
Addresses scanned: I2C 0x2c and 0x2d
Datasheet: http://www.genesyslogic.com/pdf
* Genesys Logic GL518SM release 0x80
Prefix: 'gl518sm'
Addresses scanned: I2C 0x2c and 0x2d
Datasheet: http://www.genesyslogic.com/pdf
Authors:
Frodo Looijaard <frodol@dds.nl>,
Kyösti Mälkki <kmalkki@cc.hut.fi>