wt/lm-sensors
1
0 Fork 0
mirror of https://github.com/lm-sensors/lm-sensors.git synced 2026-11-08 16:11:26 +00:00
Code Issues Packages Projects Releases Wiki Activity

lm-sensors 3.0 is now the main development branch.

Browse Source 
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@5624 7894878c-1315-0410-8ee3-d5d059ff63e0
This commit is contained in:
Jean Delvare committed 2009-01-26 15:41:25 +00:00
2 parents 6b4e26ad95 98b23f8627
commit ba87a1f673
330 files changed
+10318 -115401
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

BACKGROUND
-70
View File
@@ -1,70 +0,0 @@
This package consists of many parts. This document offers a small tour
around the most important pieces. Not all aspects are discussed
exhaustively, but it should be enough to give you the feeling you
understand what you are seeing happen.
When you want to communicate with a piece of hardware, you need a kernel
driver (well, that is not quite true, but it is in most cases the only
way to do it safely). In the past, this meant you had to patch the kernel
and recompile it. These days, you can use kernel modules. We support both
approaches.
We have chooses for a very modular (no pun intended) setup. There are a
few general-purpose base kernel modules, which you always need. In
addition, there is one kernel module for each piece of hardware - whether
this is an I2C bus adapter, an SMBus adapter or a sensors chip.
The kernel modules communicate their information through both the /proc
and sysctl interfaces (Linux 2.4) or the /sys interface (Linux 2.6). To
keep things uncomplicated, the sensor chips always advert their
measurements 'as is'. This means that the values they report are not
immediately relevant to you - they must first be scaled and translated
to correspond to the real world.
It is also possible to communicate directly with chips on an I2C bus
or SMBus. This is done through /dev files. This is useful if you
quickly want to test how a certain chip behaves, without having to
write a kernel driver.
Note that all other parts of this package function in so-called user-space.
This is important, because bugs in kernel-space might crash your
computer or do other bad things. And kernel memory can not be swapped out!
Applications could (and can) directly read the sensor values through the
/proc, sysctl or /sys interfaces. This is harder than it sounds; because
no two chips are the same, the information they communicate may also
be very unlike. This would mean that every application would have to know
about every type of chip. But there is a better solution.
libsensors is a (shared or static) library of access functions. It
knows about every type of chip supported by the kernel modules (or it
should, if it is up-to-date). It offers a simple-to-use interface for
applications to access the sensor chip readings, to set new limits,
and all other commonly needed things. From the application's point of
view, there is no need to know very much about a specific sensors chip.
Having some inside information can still be useful, but it is possible to
write a generic fall-back function that takes care of newer, unknown
chips, and to display all really important information.
libsensors takes care of one other thing. The kernel modules report
so-called 'as is' values. They have to be scaled or translated to be
relevant in the real world. libsensors reads a configuration file
(usually /etc/sensors.conf) which specifies how this translation should
be done (with some other things). Again, the application does not have
to know about it. And because the configuration file is reread each time
a new application is started, you can change configuration values without
having to recompile anything.
This package does not contain a nice graphical monitor. See
http://www.lm-sensors.org/wiki/UsefulLinks for pointers to such programs.
It does contain an example console program that reports all current sensors
values. This program is called 'sensors'. You can use it as a reference
implementation for more intricate programs.
There are many, many kernel modules in this package, and there are lots
of different sensor chips supported. Sometimes, it can be hard to
determine what chips and adapters you have, and which modules correspond
to them. Fortunately, there is a user-space application 'sensors-detect'
that should tell you exactly what is available, and what you need to
do. This perl script uses the /dev interface, and you may use it as an
example how you can do this.
BUGS
-87
View File
@@ -1,87 +0,0 @@
Except for many unimplemented things (listed in the TODO file), there may be
true bugs too. If you experience any problems not listed here, do not hesitate
to mail us (see http://www.lm-sensors.org/wiki/FeedbackAndSupport).
But read this file and doc/FAQ first, please!
============================================================================
These are current problems with specific programs and drivers.
In general, please don't send us mail telling us you have the
same problem!! Do send us mail if you have a fix!!
================================
Asus boards - as99127f support (w83781d driver)
Several problems. Asus will not release a datasheet.
Support was developed - and tweaked - with experimentation and user feedback.
These will not be fixed unless we get a datasheet.
If you have problems, please lobby Asus to release a datasheet.
Unfortunately, several others have done so, without success.
Please do not send mail to us asking for better as99127f support.
We have done the best we can without a datasheet.
The changes we do make to please some people generally makes
things worse for people with other types of motherboard.
Please do not send mail to the author or the sensors group asking for
a datasheet or ideas on how to convince Asus.
See doc/chips/w83781d for more information.
================================
i2c/smbus lockup (i2c-piix4 and i2c-ali15x3 drivers)
Sometimes the i2c bus will get hung and the driver can't un-hang it.
If this is caused by a hung sensor chip (mtp008 and w83781d chips may
be culprits), only a reboot or even power cycle will clear it
(if the SDRAM eeproms are on the hung i2c bus, the machine probably won't
boot until the power is cycled).
If there are bugs in the i2c bus drivers, or improvements we can make to
error recovery, we don't know what they are.
On the ASUS P5A motherboard, there are several reports that
the SMBus will hang and this can only be resolved by
powering off the computer. It appears to be worse when the board
gets hot, for example under heavy CPU load, or in the summer.
There may be electrical problems on this board.
On the P5A, the W83781D sensor chip is on both the ISA and
SMBus. Therefore the SMBus hangs can generally be avoided
by accessing the W83781D on the ISA bus only.
================================
IBM Thinkpad laptops and sensors-detect
See the file README.thinkpad
================================
mtp008 support
This chip does not always respond, as evidenced by 'XX' fields
in i2cdump. Results in non-detection by sensors-detect and/or
the mtp008 driver, or periodic bad readings.
Cause unknown - perhaps a bug in the chip, or the chip
not meeting the i2c specifications.
================================
sis5595 (sis5595 and i2c-sis5595 drivers)
These drivers latch on to many non-sis5595 chips which
do not support sensors, i2c bus, or both.
This is because SiS uses the same PCI ID for several different chips.
This will have to be fixed by us to recognize these other chips.
Right now, the driver tries
writing the base addresses (using the force_addr=0x.... parameter to modprobe),
it does not work for some machines (dmesg message is "force address failed").
Either some chips do not support sensors, or there is some undocumented
lock bit for the base address registers.
Also, the temperature reading in sis5595 is usually wrong.
Different formulas are required for different versions of
the chip and different motherboards.
================================
bus drivers (all)
Rmmod'ing a bus driver when the /proc directory for a chip
driver on that bus is in use may cause a kernel oops, because
the chip driver gets removed too. See ticket #331 for details.
Not likely to happen. No obvious way to fix.
CHANGES
+203 -1845
View File
File diff suppressed because it is too large. Load diff
CONTRIBUTORS
+14 -102
View File
@@ -1,103 +1,15 @@
This package could not have been created without the help of many, many people.
The most notable contributors are listed below. You are probably best off
to use the mailing list (see
http://www.lm-sensors.org/wiki/AuthorsAndContributors) if you have questions,
suggestions or problems.
Here is a list of the main contributors to lm-sensors version 3.
* Alexander Larsson <alla@lysator.liu.se>
Wrote the original lm78 module; lm_sensors version 1 was no more than an
extension of this module. He still likes to keep an eye on current
developments, but is usually too busy with other things to do much work
on them
* Philip Edelbrock <phil@netroedge.com>
Took up the development of the Alex' lm78 module. Responsible for most
SMBus code, and many, many other things. He is still one of the main
developers of the current package.
* Frodo Looijaard <frodol@dds.nl>
Took up the development of Alex' lm78 module. Large pieces of code were
written by him. Designed lm_sensors version 2, and wrote most of its
core code, including many drivers.
* William Morgan <wmorgan@cmu.edu>
Helped with some patches in lm_sensors version 1. He provided us with
the original CVS archive, and even managed to explain to us how to use
it.
* Kyösti Mälkki <kmalkki@cc.hut.fi>
Author of the i2c-via and i2c-viapro host drivers. Sis5595 hack.
Extended support for GL518SM and GL520SM sensors.
* Mark D. Studebaker <mdsxyz123@yahoo.com>
Author of the i2c-ali15x3, i2c-i801, and i2c-i810 bus drivers.
Author (with Bob Dougherty) of the via686a driver.
Added w83782d, w83783s, w83627hf, and as99127f support to the w83781d driver.
Added max1617, thmc10, gl523sm, and lm84 support to the adm1021 driver.
Added lm81 support to the adm9240 driver.
Added DDC support and i2c-algo-bit layer to the i2c-voodoo3 bus driver.
Author of the decode-xeon.pl xeon EEPROM decoder.
Added the RRD interface.
Author of the ddcmon, icspll, smbus-arp, smsc47m1,
vt1211, and vt8231 chip drivers.
* Bob Dougherty <bobd@stanford.edu>
Author (with MDS) of the via686a driver.
* Jonathan Teh Soon Yew <j.teh@iname.com> and Alex van Kaam <darkside@chello.nl>
Contributed conversion factor data for the via686a driver.
* Geert Uytterhoeven <geert@linux-m68k.org>
Author of the i2c-hydra driver.
* Adrian Baugh (http://www.adrianbaugh.org.uk/)
Original author of wmsensors;
he also tested lots of things, and helped us out on several occasions.
* Fons Rademakers <Fons.Rademakers@cern.ch>
Author of the maxilife module (which could only be written under NDA)
* Merlin Hughes <merlin@merlin.org>
Author of the AMD756 module and sensord.
* Constantine Gavrilov <const-g@xpert.com>
Created and maintains the RPM files
* Simon Vogl <simon@tk.uni-linz.ac.at>
Wrote the new i2c kernel driver. This driver is indispensable for the
workings of lm_sensors version 2.
* Gerd Knorr <kraxel@cs.tu-berlin.de> (?)
Designed the i2c structs, which made it possible to use the smbus-is-
just-an-i2c-extension approach.
* Chen-Yuan Wu <gwu@esoft.com>
Author of the adm1025 driver.
* Kris Van Hees <aedil@alchar.org>
Author of the mtp008 chip driver.
* Ken Bowley <ken@opnix.com>
Author of the adm1024 driver
* Oleg I. Vdovikin <vdovikin@jscc.ru>
Author of the DEC Tsunami bus driver.
* Christophe Gauthron
Author of the IT87 driver.
* Hermann Jung <hej@odn.de>
Author of the fscpos driver.
* Aurelien Jarno <aurelien@aurel32.net>
Author of the pcf8591 driver.
* Abraham vd Merwe <abraham@2d3d.co.za>
Author of the LM92 and DS1307 drivers.
* Mark M. Hoffman <mhoffman@lightlink.com>
Author of the i2c-sis645 bus driver.
Added Asus ASB100 Bach support to the w83781d driver.
* Alexander Malysh <amalysh@web.de>
Author of the i2c-sis630 bus driver.
Added Onsemi MC1066 support to the adm1021 driver.
* Jean Delvare <khali@linux-fr.org>
Author of the lm63, lm83, lm90 and w83l785ts SMBus chip drivers.
Author of the f71805f and pc87360 Super-I/O chip drivers.
Author of the i2c-amd756-s4882 and pca9540 SMBus multiplexing drivers.
Author of the decode-vaio.pl Vaio EEPROM decoder.
Author of the decode-edid.pl EDID data decoder.
Perl scripts maintainer, tester, bug fixer, general support.
* Vojtech Pavlik <vojtech@suse.cz>
Author of the i2c-amd8111 bus driver.
Added support for amd8111 SMBus 1.0 controller to i2c-amd756.
* Philip Pokorny <ppokorny@penguincomputing.com>
Author of the LM85 chip driver.
Author of the ADM1026 chip driver.
* Sascha Volkenandt <sascha@akv-soft.de>
Author of the SAA1064 chip driver.
* John Morris <john.morris@spirentcom.com>
Author of the MAX6650 chip driver.
* Reinhard Nissl <rnissl@gmx.de>
Author of the fscher driver.
* Alexey Fisher <fishor@mail.ru>
Author of the max1619 chip driver.
* Rudolf Marek <r.marek@assembler.cz>
Various fixes and support handling
* Frodo Looijaard
Original author of libsensors, sensors and isadump.
* Merlin Hughes
Original author of sensord.
* Bob Schlaermann
Dynamic chip feature detection (a.k.a. generic chip support) in
libsensors and sensors.
* Mark M. Hoffman
Many improvements to the libsensors configuration file scanner.
* Jean Delvare
New libsensors API, and migration of sensors and sensord thereto.
Many optimizations in libsensors and sensors.
Configuration file converter.
INSTALL
+59 -281
View File
@@ -1,305 +1,83 @@
=============================================================================
INSTALLATION INSTRUCTIONS
=========================
DETAILED INSTALLATION INSTRUCTIONS
See QUICKSTART for the simple version.
The driver modules in this package are ONLY for 2.4 kernels 2.4.10 or later!
This package REQUIRES i2c-2.9.0 or later! The i2c subsystem found in the
Linux 2.4 kernel trees, even the latest ones, is outdated and won't work.
FOR 2.5/2.6 KERNELS, do not attempt to compile the modules in this package.
Use the drivers already in the 2.5/2.6 kernel tree.
If you are running a 2.5/2.6 kernel, the ONLY thing you need to
do is 'make user' and 'make user_install'. Do NOT follow the rest
of these instructions. Please check the QUICKSTART instead.
The lm-sensors package, version 3, provides user-space support for the
hardware monitoring drivers in Linux 2.6.5 and later. For older kernel
versions, you have to use lm-sensors version 2.
=============================================================================
These are the installation instruction for the lm_sensors package.
Dependencies
============
There are two ways in which you can compile and install this package.
Option 1 is much easier and is recommended.
Build-time dependencies:
* GNU make
* gcc
* bison
* flex
* rrd header files (optional, for sensord)
1. Complete separate from kernel compilation
(only for 2.4 kernels 2.4.10 or later)
This will generate a set of modules which can be inserted and removed
as needed; nothing will be written into the kernel tree;
2. Patching of the kernel
(only for 2.4 kernels 2.4.13 or later)
This will patch your kernel source tree. You must recompile your kernel
to take advantage of this. But it makes it possible to compile drivers
into the kernel itself, instead of having to add them as modules.
** AFTER YOU COMPILED AND INSTALLED YOUR KERNEL, YOU WILL STILL HAVE TO
** COMPILE THIS PACKAGE TO GET THE USERLAND UTILITIES!
** NOT ALL MODULES ARE PATCHED INTO THE KERNEL. SEE BELOW.
Run-time dependencies:
* perl (for sensors-detect)
* rrdtool >= 1.2.1 (optional, for sensord)
* proper kernel configuration (see below)
Each of these ways will be described below in detail.
NOTE: MAKE SURE YOU HAVE THE I2C-ALGO-BIT DRIVER (PART OF THE I2C PACKAGE)
COMPILED INTO YOUR KERNEL OR AVAILABLE AS A MODULE; SOME I2C/SMBUS
MASTER DRIVERS DEPEND ON IT!
NOTE: IN EACH CASE, YOU WILL HAVE TO GET AND INSTALL THE I2C PACKAGE FIRST!
SET COMPILE_KERNEL TO 0 IN THE MAIN MAKEFILE FOR OPTION 2, UNLESS
YOU NEED ALPHA OR BETA DRIVERS (SEE BELOW)
NOTE: PLEASE READ THE DOCUMENTATION IN THE DOC SUBDIRECTORY IF YOU GET STUCK!
Installing the i2c package
==========================
This lm_sensors release REQUIRES i2c-2.9.0 or later, which is not in
any 2.4 kernel (and will never be).
Therefore, you must download and install the i2c package with
the same version number or higher as this lm_sensors package.
All i2c components are distributed in
a separate package. There are install instructions in that package. If
you want to use compilation option 2 (patching the kernel) for lm_sensors,
you will have to use compilation option 3 (patching the kernel) for i2c
too. If you want to use compilation option 1 (compiling as modules) for
lm_sensors, you may use either compilation option 1 or 2 (compiling as
modules) or compilation option 3 (patching the kernel for i2c). See the
table below.
LM_SENSORS
I2C | option 1 (modules) option 2 (patch kernel)
-------------------------+------------------------------------------------
option 1 (modules) | YES NO
option 2 (modules) | YES YES
option 3 (patch kernel) | YES YES
If you use compilation option 1 (compiling as modules) for lm_sensors, you
will have to make very sure the correct i2c header files are found. If you
get weird compilation errors, this is almost certainly going wrong. The
i2c header files are in a i2c subdirectory of either /usr/local/include
(i2c compilation option 1) or /usr/src/linux*/include (i2c compilation
options 2 and 3). Especially if you have in the past placed the header
files in /usr/local/include, this will probably go wrong. See below on
how to fix this.
NOTE: option 3 only works with 2.4 kernels 2.4.13 or later;
options 1 and 2 only work with 2.4 kernels 2.4.10 or later.
Mixing old and new, and using beta drivers (compilation option 1)
=================================================================
It is possible that you are running a previously patched kernel, or
a very new kernel which already has limited or full i2c or lm_sensors
support, but you want to use newer versions of the drivers. This is
possible, but there are some pitfalls.
If you had compiled all i2c and lm_sensors drivers as modules, you are
in luck. You can simply compile the newest versions of i2c and
lm_sensors and install them. Just make sure the right modules are
loaded (best bet: remove the old ones first).
If you have a certain driver compiled into your kernel, you may
encounter bad problems. We do not guarantee to keep internal kernel
interfaces unchanged. In plain language, this means that an older driver
may not work together with a newer driver, and your kernel may crash.
On the other hand, if you know what you are doing, compilation will
be smart. Drivers that are compiled right into your kernel will not
be compiled as a module again. You could do nothing with them anyway.
Sometimes, you want to patch your kernel, but find that certain alpha
or beta drivers are not included in the patch. This is on purpose: we
do not want to polute the kernel tree with things of which we are not
confident they work. In this case, patch the kernel, compile it, and
then compile lm_sensors with COMPILE_KERNEL set to 1.
Having a proper kernel tree (compilation option 1)
==================================================
Usually, if you compile a user-space application, you can get away with
having a different version of the kernel running than the version of the
kernel header files against which you compiled it. But a perfect match
is needed for the first two compilation options above.
Let's say you want to use the lm_sensors modules with the kernel 2.4.32 you
are running now. What you need, is the original tree in which you
compiled that 2.4.32 kernel. A freshly unpacked 2.4.32 kernel will not
cut it, because `make *config dep' creates some files that are needed.
And even then, you will run into trouble, because you may not have
selected the exact same configuration variables. Plain advise: if you
do not have your original kernel tree anymore, recompile your kernel
first.
Note that there is no need for a perfect match at compilation time, just
at run-time. This means you can cross-compile against a different kernel
version, and the Makefile does not check for this.
Usually problems if the match is imperfect, is that either this package
won't compile at all (because it was a freshly unpacked tree without
some files generated by `make *config dep'), or that you can't insert
modules because of either a `kernel-module version mismatch' or because
of `unresolved kernel symbols'. If you get either of these messages,
check your kernel tree!
To keep problems to a minimum, please use a 'vanilla' kernel tree,
as distributed on ftp://ftp.kernel/org/pub/linux/kernel, and not one
patched by your distribution.
Separate from kernel compilation (compilation option 1)
=======================================================
This will compile and install the complete lm_sensors package. Though
nothing is written to your kernel tree, a proper tree is still needed
for this. See earlier for what a proper kernel tree is.
Compilation
===========
At the top of the Makefile are a couple of configuration variables that
you may want to change. As far as possible, the Makefile tries to figure
out by itself their settings, but it is possible to overrule them. A list
is found below. Most important are the variables that determine where
your kernel is located (LINUX=/lib/modules/KERNELVERSION/build, usually
links to /usr/src/linux or something similar), where the i2c header files
are (I2C_HEADERS=/usr/local/include) and where you want to install
your modules (MODDIR=/lib/modules/KERNELVERSION) and header files
(LINUX_INCLUDE_DIR=/usr/local/include/linux). You can see that the
installation locations are choosen in such a way that they are separate
from the true kernel.
you may want to change. There's a description of what each variable does
in the Makefile itself.
Compilation is done by `make all'; `make install' installs the package.
You will get a lot of warnings about files which are not found, all
ending on `.*d'. You can safely ignore this; they contain dependency
information, which is regenerated on the spot.
Compilation is done by `make all'. You will get a lot of warnings about
files which are not found, all ending in `.*d'. You can safely ignore
this; they contain dependency information, which is regenerated on the
spot.
Please continue reading this file before you start compiling.
`make install' installs the package (to /usr/local by default).
Makefile configuration variables (compilation option 1)
==============================================================
Kernel configuration
====================
SHELL (default: /bin/sh)
You may have to specify the full path to Bash here, if /bin/sh is some
other shell. There have been conflicting reports on whether this is
needed.
KERNELVERSION
The version of the currently running kernel.
LINUX (default: /lib/modules/$(KERNELVERSION)/build)
The location of your kernel tree.
COMPILE_KERNEL
Determine whether you want to consider the kernel modules for compilation
at all. By default, compilation option 1 will only compile and install
those modules which are not built into the kernel.
If some modules are built into your kernel, and this package is much
newer, you may find you can not insert the newly compiled modules.
Sorry.
You may want to set this to 0 if you have just patched and compiled
your kernel using the same version of this package, and just want to
compile the user-space tools.
I2C_HEADERS (default: /usr/local/include)
This lists where the i2c headers are found. If you used compilation
option 1 for the i2c package, the default will be right. If you used
compilation options 2 or 3, it will not, and may actually cause
problems if you have the left-overs of a previous installation.
If you have weird compilation problems, try to change this to
$(LINUX_HEADERS).
SMP
This must be set to 1 for a SMP kernel. The magic invocation should
determine this automatically, so you should not have to bother with
this.
MODVER
This must be set to 1 if CONFIG_MODVERSIONS is defined. The magic
invocation should determine this automatically, so you should not
have to bother with this.
WARN (default: 0)
Generate additional compilation warnings; mainly interesting for
developers.
DEBUG (default: 0)
Some drivers will issue more debug information if you set this to
1. Don't do it, unless you are a developer or are instructed to do
so by the lm_sensors team.
PREFIX (default: /usr/local)
Prefix for almost all installation directories.
MODPREF (default: /lib/modules/$(KERNELVERSION))
The location where the kernel modules will be installed.
ETCDIR (default: /etc)
Installation location of the sensors.conf configuration file.
LIBDIR (default: $(PREFIX)/lib)
Installation location of all static and shared libraries.
BINDIR (default: $(PREFIX)/bin)
Installation directory of programs useful for users.
SBINDIR (default: $(PREFIX)/sbin)
Installation directory of system administrator-only programs.
INCLUDEDIR (default: $(PREFIX)/include)
Base installation directory for include files (see next two vars).
SYSINCLUDEDIR (default: $(INCLUDEDIR)/linux)
Installation directory for system include files.
LIBINCLUDEDIR (default: $(INCLUDEDIR)/sensors)
Installation directory for libsensors include files.
MANDIR (default: $(PREFIX)/man)
Base installation directory for manual pages.
Patching the kernel (compilation option 2)
==========================================
There is a special script which should be able to generate diffs against
any 2.4 kernel (2.4.10 or later). Please report any problems to our
mailing list. It *is* safe to run it if your kernel already has the
lm_sensors drivers. It will only work if you applied the i2c patches first.
** Only a subset of the modules in lm_sensors are patched into the **
** kernel by the script. See the file mkpatch/FILES to see if the **
** modules you need are included. If a module you need is NOT listed **
** in mkpatch/FILES, it will not be patched, and you MUST use option 1. **
** If you are not sure what modules you need, run `sensors-detect' first. **
The kernel diffs are generated by the program `mkpatch.pl' in the mkpatch
subdirectory. It needs two arguments: the first one is the root of the
lm_sensors package, the second one is the root of the kernel tree against
which the diffs will be generated. For example:
cd /tmp/lm_sensors-2.10.0
mkpatch/mkpatch.pl . /usr/src/linux > /tmp/sensors-2.10.0.patch
You can apply the diffs as usual:
cd /usr/src/linux
patch -p1 -E < /tmp/sensors-2.10.0.patch
Generation and application can easily be done in one step:
mkpatch/mkpatch.pl . /usr/src/linux | patch -p1 -E -d /usr/src/linux
The generated diffs are of course only valid for the kernel version
against which mkpatch.pl was run.
Once you have applied the patches, you can configure and compile your
kernel as usual. You will see the sensors configuration screen under the
`Character Devices' menu in menuconfig, but it will only be available
if you selected base I2C support.
This package assumes that you have a properly configured kernel. If
you run a distribution kernel, that should be the case. If you're
building your own kernel, here are some recommendations:
* Enable "I2C support" (CONFIG_I2C=y or m). On many motherboards, the
sensor chip is connected to the SMBus, which is supported by I2C
in the Linux kernel.
* Enable "I2C device interface" (CONFIG_I2C_CHARDEV=m). sensors-detect
needs this to probe for SMBus hardware monitoring chips.
* In I2C Hardware Bus support, enable all drivers you might need,
preferably as modules. If you're not sure, select them all.
* Enable "Hardware Monitoring support" (CONFIG_HWMON=y or m).
* Enable all hardware monitoring drivers you might need, preferably
as modules. If you're not sure, select them all.
Using the sensors package
=========================
You can now load the modules by using `modprobe'. For example,
`modprobe i2c-piix4' will load the i2c-piix4 module, and all i2c modules
on which it depends.
You can not use demand-loading; you will have to issue explicit modprobe
instructions.
If you have an older installation, you will probably have to create the
i2c device files in the /dev directory. They are called /dev/i2c-%d,
and are character devices with major device number 89 and minor device
number %d. The script prog/mkdev/mkdev.sh will create the files for you.
There is a scanning program installed called sensors-detect. It
will scan all available I2C and SMBus adapters for all known devices,
and will also look for ISA, PCI and Super-I/O chips with sensors,
and give you a list of what modules you need to insert.
will scan all available I2C and SMBus adapters for all known sensor
devices, and will also look for ISA, PCI and Super-I/O chips with
sensors, and give you a list of what kernel drivers you need to load
(using modprobe).
You can use the installed sensors program to get a report of all detected
sensor devices. There is also a manual page for this program. Calling
`sensors -s' will set the limits and other configuration settings
specified in /etc/sensors.conf. Again, read the manual pages for more
information.
After loading the suggested drivers, you can use the installed sensors
program to get a report of all detected sensor devices. Check the manual
page for available options.
The initial output of `sensors' will not be perfect. You have to adjust
the configuration file (/etc/sensors3.conf) to match your motherboard.
This includes (re)labelling inputs, ignoring unused inputs, changing
voltage compute lines and setting limits. Write down all the sensor
information your BIOS displays as a hint to what you are supposed to
obtain in the end. Make sure you modify the right chip section.
Once you are done with editing the configuration file, calling
`sensors -s' will set the new limits. Then the output of `sensors'
should look much better.
There are many auxiliary programs not installed. You can find them under
the prog subdirectory. A list can be found in doc/progs.
Makefile
+35 -251
View File
@@ -13,56 +13,20 @@
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
# MA 02110-1301 USA.
# Everything you may want to change is in the top of this file. Usually, you
# can just use the defaults, fortunately.
# You need a full complement of GNU utilities to run this Makefile
# successfully; most notably, you need bash, GNU make, flex (>= 2.5.1)
# successfully; most notably, you need GNU make, flex (>= 2.5.1)
# and bison.
# If your /bin/sh is not bash, change the below definition so that make can
# find bash. Or you can hope your sh-like shell understands all scripts.
# I think so, but I have not tested it.
#SHELL := /usr/bin/bash
# The currently running kernel version. This is used right below to
# determine where the kernel sources can be found.
KERNELVERSION := $(shell uname -r)
# The location of linux itself. This is used to find the kernel headers
# and other things.
#LINUX := /usr/src/linux
LINUX := $(shell if [ -L "/lib/modules/$(KERNELVERSION)/build" ] ; \
then echo "/lib/modules/$(KERNELVERSION)/build" ; \
else echo "/usr/src/linux" ; fi)
LINUX_HEADERS := $(LINUX)/include
# If you have installed the i2c header at some other place (like
# /usr/local/include/linux), set that directory here. Please check this out
# if you get strange compilation errors; the default Linux i2c headers
# may be used mistakenly. Note: This should point to the directory
# *above* the linux/ subdirectory, so to /usr/local/include in the
# above example.
I2C_HEADERS := /usr/local/include
#I2C_HEADERS := $(LINUX_HEADERS)
ifneq ($(MAKECMDGOALS),user)
ifneq ($(MAKECMDGOALS),user_install)
ifneq ($(MAKECMDGOALS),user_uninstall)
SMP := $(shell if grep -q '^[[:space:]]*\#define[[:space:]]*CONFIG_SMP[[:space:]]*1' $(LINUX_HEADERS)/linux/autoconf.h ; \
then echo 1; else echo 0; fi)
MODVER := $(shell if grep -q '^[[:space:]]*\#define[[:space:]]*CONFIG_MODVERSIONS[[:space:]]*1' $(LINUX_HEADERS)/linux/autoconf.h ; \
then echo 1; else echo 0; fi)
endif
endif
endif
# Uncomment the second line if you are a developer. This will enable many
# additional warnings at compile-time
WARN := 0
#WARN := 1
#WARN := 0
WARN := 1
# Uncomment the second line if you want to get (loads of) debug information
# at run-time.
@@ -70,6 +34,9 @@ WARN := 0
DEBUG := 0
#DEBUG := 1
# Note that all the installation paths below can also be set on the make
# command line (e.g. "make PREFIX=/usr").
# If you want to install at some other place then at from which you will run
# everything, set DESTDIR to the extra prefix.
DESTDIR :=
@@ -80,36 +47,7 @@ PREFIX := /usr/local
# Your C compiler
CC := gcc
# This is the main modules directory into which the modules will be installed.
# The magic invocation will return something like this:
# /lib/modules/2.4.29
KERNELVERSION := $(shell $(CC) -I$(LINUX_HEADERS) -E etc/config.c | grep uts_release | cut -f 2 -d'"')
MODPREF := /lib/modules/$(KERNELVERSION)
# When building userspace for use with 2.4.x series kernels, we turn off
# sysfs support by default. You can override this (e.g. if you want
# to build binaries that work for both 2.4.x, and 2.6.x and above)
# by uncommenting the line after the next endif. Keep in mind, if and only
# if you do this: you will need to install the libsysfs libraries on your
# kernel 2.4.x systems also.
ifeq (,$(findstring /2.4., $(MODPREF)))
SYSFS_SUPPORT := 1
else
SYSFS_SUPPORT :=
endif
#SYSFS_SUPPORT := 1
# Prevent 2.6+ users from using improper targets, as this won't work.
ifeq (,$(findstring /2.4., $(MODPREF)))
ifeq (, $(MAKECMDGOALS))
$(error For 2.6 kernels and later, use "make user")
endif
ifeq (install, $(MAKECMDGOALS))
$(error For 2.6 kernels and later, use "make user_install")
endif
endif
# This is the directory where sensors.conf will be installed, if no other
# This is the directory where sensors3.conf will be installed, if no other
# configuration file is found
ETCDIR := /etc
@@ -131,12 +69,8 @@ SBINDIR := $(PREFIX)/sbin
# You should not need to change this. It is the basic directory into which
# include files will be installed. The actual directory will be
# $(INCLUDEDIR)/linux for system include files, and $(INCLUDEDIR)/sensors
# for library include files. If PREFIX equals the default /usr/local,
# you will be able to use '#include <linux/sensors.h>' regardless of the
# current kernel selected.
# $(INCLUDEDIR)/sensors for library include files.
INCLUDEDIR := $(PREFIX)/include
SYSINCLUDEDIR := $(INCLUDEDIR)/linux
LIBINCLUDEDIR := $(INCLUDEDIR)/sensors
# You should not need to change this. It is the base directory under which the
@@ -169,24 +103,12 @@ MACHINE := $(shell uname -m)
# to do this.
# The subdirectories we need to build things in
SRCDIRS :=
ifneq ($(MAKECMDGOALS),user)
ifneq ($(MAKECMDGOALS),user_install)
ifneq ($(MAKECMDGOALS),user_uninstall)
ifneq ($(MAKECMDGOALS),package)
ifneq ($(MAKECMDGOALS),userpackage)
ifneq ($(MAKECMDGOALS),manhtml)
SRCDIRS += mkpatch
SRCDIRS += kernel/busses kernel/chips
SRCDIRS := lib prog/detect prog/pwm \
prog/sensors ${PROG_EXTRA:%=prog/%} etc
# Only build isadump and isaset on x86 machines.
ifneq (,$(findstring $(MACHINE), i386 i486 i586 i686 x86_64))
SRCDIRS += prog/dump
endif
endif
endif
endif
endif
endif
SRCDIRS += kernel/include
SRCDIRS += lib prog/detect prog/dump prog/eeprom prog/pwm \
prog/sensors prog/xeon ${PROG_EXTRA:%=prog/%} etc
SRCDIRS += lib/test
# Some often-used commands with default options
@@ -205,11 +127,10 @@ SED := sed
# Determine the default compiler flags
# Set CFLAGS or CPPFLAGS above to add your own flags to all.
# ALLCPPFLAGS/ALLCFLAGS are common flags, plus any user-specified overrides from the environment or make command line.
# MODCPPFLAGS/MODCFLAGS is to create in-kernel object files (modules).
# PROGCPPFLAGS/PROGCFLAGS is to create non-kernel object files (which are linked into executables).
# PROGCPPFLAGS/PROGCFLAGS is to create regular object files (which are linked into executables).
# ARCPPFLAGS/ARCFLAGS are used to create archive object files (static libraries).
# LIBCPPFLAGS/LIBCFLAGS are for shared library objects.
ALL_CPPFLAGS := -I. -Ikernel/include -I$(I2C_HEADERS)
ALL_CPPFLAGS := -I.
ALL_CFLAGS := -Wall
ifeq ($(DEBUG),1)
@@ -221,67 +142,21 @@ endif
ifeq ($(WARN),1)
ALL_CFLAGS += -Wstrict-prototypes -Wshadow -Wpointer-arith -Wcast-qual \
-Wcast-align -Wwrite-strings -Wnested-externs -Winline
-Wcast-align -Wwrite-strings -Wnested-externs -Winline -W \
-Wmissing-prototypes -Wundef
endif
ALL_CPPFLAGS += $(CPPFLAGS)
ALL_CFLAGS += $(CFLAGS)
MODCPPFLAGS :=
MODCFLAGS := -fno-strict-aliasing
ifeq ($(MACHINE),alpha)
MODCFLAGS += -ffixed-8 -mno-fp-regs -mcpu=ev56
endif
ifeq ($(MACHINE),x86_64)
MODCFLAGS += -fno-common -fomit-frame-pointer -mno-red-zone \
-mcmodel=kernel -fno-reorder-blocks -finline-limit=2000 -fno-strength-reduce
endif
ifeq ($(MACHINE),mips)
MODCFLAGS += -mabi=32 -mips3 -Wa,-32 -Wa,-mips3 -Wa,--trap
endif
ifeq ($(MACHINE),sparc32)
MODCFLAGS += -m32 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
endif
ifeq ($(MACHINE),sparc64)
MODCFLAGS += -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow \
-ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare \
-Wa,--undeclared-regs
endif
ifeq ($(SMP),1)
MODCPPFLAGS += -D__SMP__
endif
ifeq ($(MODVER),1)
MODCPPFLAGS += -DMODVERSIONS -include $(LINUX_HEADERS)/linux/modversions.h
endif
# This magic is from the kernel Makefile.
# Extra cflags for kbuild 2.4. The default is to forbid includes by kernel code
# from user space headers.
kbuild_2_4_nostdinc := -nostdinc $(shell LC_ALL=C $(CC) -print-search-dirs | sed -ne 's/install: \(.*\)/-I \1include/gp')
MODCPPFLAGS += -D__KERNEL__ -DMODULE -DEXPORT_SYMTAB -fomit-frame-pointer $(ALL_CPPFLAGS) -I$(LINUX_HEADERS) $(kbuild_2_4_nostdinc)
MODCFLAGS += $(ALL_CFLAGS)
PROGCPPFLAGS := -DETCDIR="\"$(ETCDIR)\"" $(ALL_CPPFLAGS) -Wundef
PROGCPPFLAGS := -DETCDIR="\"$(ETCDIR)\"" $(ALL_CPPFLAGS)
PROGCFLAGS := $(ALL_CFLAGS)
ARCPPFLAGS := $(ALL_CPPFLAGS)
ifdef SYSFS_SUPPORT
ARCPPFLAGS := $(ARCPPFLAGS) -DSYSFS_SUPPORT
endif
ARCPPFLAGS := -DETCDIR="\"$(ETCDIR)\"" $(ALL_CPPFLAGS)
ARCFLAGS := $(ALL_CFLAGS)
LIBCPPFLAGS := $(ALL_CPPFLAGS)
ifdef SYSFS_SUPPORT
LIBCPPFLAGS := $(LIBCPPFLAGS) -DSYSFS_SUPPORT
endif
LIBCPPFLAGS := -DETCDIR="\"$(ETCDIR)\"" $(ALL_CPPFLAGS)
LIBCFLAGS := -fpic -D_REENTRANT $(ALL_CFLAGS)
.PHONY: all user clean install user_install uninstall user_uninstall version package
.PHONY: all user clean install user_install uninstall user_uninstall
# Make all the default rule
all::
@@ -293,15 +168,11 @@ ifneq ($(MAKECMDGOALS),clean)
ifneq ($(MAKECMDGOALS),uninstall)
ifneq ($(MAKECMDGOALS),user_uninstall)
ifneq ($(MAKECMDGOALS),help)
ifneq ($(MAKECMDGOALS),package)
ifneq ($(MAKECMDGOALS),userpackage)
include $(INCLUDEFILES)
endif
endif
endif
endif
endif
endif
# Man pages
MANPAGES := $(LIBMAN3FILES) $(LIBMAN5FILES) $(PROGDETECTMAN8FILES) $(PROGDUMPMAN8FILES) \
@@ -309,35 +180,19 @@ MANPAGES := $(LIBMAN3FILES) $(LIBMAN5FILES) $(PROGDETECTMAN8FILES) $(PROGDUMPMAN
user ::
user_install::
@echo "*** Important note:"
@echo "*** * The libsensors configuration file ($(ETCDIR)/sensors.conf) is never"
@echo "*** Important notes:"
@echo "*** * The libsensors configuration file ($(ETCDIR)/sensors3.conf) is never"
@echo "*** overwritten by our installation process, so that you won't lose"
@echo "*** your personal settings in that file. You still can get our latest"
@echo "*** default config file in etc/sensors.conf.eg and manually copy it to"
@echo "*** $(ETCDIR)/sensors.conf if you want. You will then want to edit it"
@echo "*** to fit your needs again."
@echo "*** default config file in etc/sensors.conf.default and manually copy"
@echo "*** it to $(ETCDIR)/sensors3.conf if you want. You will then want to"
@echo "*** edit it to fit your needs again."
@echo "*** * The format of $(ETCDIR)/sensors3.conf changed with lm-sensors 3.0.0."
@echo "*** If you have a custom configuration file using the old format, you"
@echo "*** can convert it using the sensors-conf-convert script. Otherwise just"
@echo "*** overwrite your old configuration file with the new default one."
all :: user
install :: all user_install
ifeq ($(DESTDIR),)
-if [ -x /sbin/depmod ] ; then \
if [ -r $(MODPREF)/build/System.map ] ; then \
/sbin/depmod -a -F $(MODPREF)/build/System.map $(KERNELVERSION) ; \
elif [ "$(KERNELVERSION)" = "`uname -r`" ] ; then \
/sbin/depmod -a ; \
fi \
fi
else
@echo "*** This is a \`staged' install using \"$(DESTDIR)\" as prefix."
@echo "***"
@echo "*** Once the modules have been moved to their final destination"
@echo "*** you must run the command \"/sbin/depmod -a\"."
@echo "***"
@echo "*** Alternatively, if you build a package (e.g. rpm), include the"
@echo "*** command \"/sbin/depmod -a\" in the post-(un)install procedure."
@echo "***"
@echo "*** The depmod command mentioned above may generate errors. We are"
@echo "*** aware of the problem and are working on a solution."
endif
clean::
$(RM) lm_sensors-* lex.backup
@@ -345,74 +200,13 @@ clean::
user_uninstall::
uninstall :: user_uninstall
@echo "*** Note:"
@echo "*** * Kernel modules were not uninstalled."
# This is tricky, but it works like a charm. It needs lots of utilities
# though: cut, find, gzip, ln, tail and tar.
package: version clean
lmversion=`tail -1 version.h|cut -f 2 -d \"`; \
lmpackage=lm_sensors-$$lmversion; \
ln -s . $$lmpackage; \
find $$lmpackage/ -type f | grep -v ^$$lmpackage/$$lmpackage$$ | \
grep -v ^$$lmpackage/$$lmpackage.tar$$ | \
grep -v ^$$lmpackage/$$ | \
grep -v /\\.svn | \
grep -v /\\.# | \
tar rvf $$lmpackage.tar -T -; \
gzip -9 $$lmpackage.tar ;\
$(RM) $$lmpackage.tar $$lmpackage
cat doc/developers/checklist
# doesn't work well yet... needs Makefile changes too
userpackage: version clean $(KERNELINCLUDEDIR)/sensors.h
lmversion=`tail -1 version.h|cut -f 2 -d \"`; \
lmpackage=lm_sensors-user-$$lmversion; \
ln -s . $$lmpackage; \
find $$lmpackage/ -type f | grep -v ^$$lmpackage/$$lmpackage$$ | \
grep -v ^$$lmpackage/$$lmpackage.tar$$ | \
grep -v ^$$lmpackage/doc/chips | \
grep -v ^$$lmpackage/doc/busses | \
grep -v ^$$lmpackage/kernel/chips | \
grep -v ^$$lmpackage/kernel/busses | \
grep -v ^$$lmpackage/$$ | \
grep -v /\\.svn | \
grep -v /\\.# | \
tar rvf $$lmpackage.tar -T -; \
gzip -9 $$lmpackage.tar ;\
$(RM) $$lmpackage.tar $$lmpackage
cat doc/developers/checklist
version:
$(RM) version.h
echo '#define LM_DATE "'`date +'%Y%m%d'`\" > version.h
echo -n 'Version: '; \
echo '#define LM_VERSION "'`read VER; echo $$VER`\" >> version.h
help:
@echo 'Make targets are:'
@echo ' all (default): build modules and userspace programs'
@echo ' install: install modules and userspace programs'
@echo ' user: build userspace programs'
@echo ' user_install: install userspace programs'
@echo ' user_uninstall: remove userspace programs'
@echo ' all (default): build library and userspace programs'
@echo ' install: install library and userspace programs'
@echo ' uninstall: uninstall library and userspace programs'
@echo ' clean: cleanup'
@echo ' package: create a distribution package'
$(LINUX)/.config:
@echo
@echo "Error - missing file $(LINUX)/.config !! "
@echo " Verify kernel source is in $(LINUX) and then"
@echo " cd to $(LINUX) and run 'make config' !!"
@echo
@echo "Exception: if you're using a stock RedHat kernel..."
@echo " (1) Install the appropriate kernel-source RPM."
@echo " (2) Copy the appropriate config..."
@echo " from $(LINUX)/configs/<...>"
@echo " to $(LINUX)/.config"
@echo " (3) Do *NOT* 'make dep' or 'make config'."
@echo
@exit 1
# Generate html man pages to be copied to the lm_sensors website.
# This uses the man2html from here
@@ -434,16 +228,6 @@ manhtml:
# We need to create dependency files. Tricky. The sed rule puts dir/file.d and
# dir/file.c in front of the dependency file rule.
# .o files are used for modules
# depend on the kernel config file!
%.o: %.c $(LINUX)/.config
$(CC) $(MODCPPFLAGS) $(MODCFLAGS) -c $< -o $@
%.d: %.c $(LINUX)/.config
$(CC) -M -MG $(MODCPPFLAGS) $(MODCFLAGS) $< | \
$(SED) -e 's@^\(.*\)\.o:@$*.d $*.o: Makefile '`dirname $*.d`/Module.mk' @' > $@
# .ro files are used for programs (as opposed to modules)
%.ro: %.c
QUICKSTART
-77
View File
@@ -1,77 +0,0 @@
LM_SENSORS QUICK INSTALLATION INSTRUCTIONS
------------------------------------------
The instructions in this document will generally work if you have a standard
system, but not always!!
The first part of document is for 2.6 kernel series, second part is for
older 2.4 kernels.
Quickstart for Kernel 2.6
-------------------------
0) Just compile and install lm-sensors userspace tools. You can do that with:
'make user; make user_install'
1) Make sure your kernel has support for all I2C bus drivers and
'i2c device interface'. If you are using a distribution kernel, all is
already prepared, you don't need to recompile it.
2) Run 'sensors-detect' command, it will tell you what modules you need to load.
3) Load them and run 'sensors' command, you should see some results.
4) Find right section in /etc/sensors.conf, fix labels, limits, fan divisors
5) Run 'sensors -s' to apply the changes.
You may also try our installation wizard at:
http://www.lm-sensors.org/wiki/iwizard/1
We are aware that the documentation could be improved, please contact us if
you want to help us with that.
Quickstart for Kernel 2.4
-------------------------
NOTE: PLEASE SKIM THE INSTALL DOCUMENT, OR BETTER YET READ IT CAREFULLY!
Quickstart for i2c option 1 (modules) and lm_sensors option 1 (modules).
This is by far the EASIEST METHOD.
Other methods are described in INSTALL.
------------------------------------------
* Verify you are running a 2.4 kernel, 2.4.10 or later.
* Make sure you have the kernel tree corresponding to your current
kernel in /lib/modules/$(uname -r)/build.
Even if the source is there, it may not correspond to your running
kernel. If so, you will have to recompile your kernel.
* Verify that your i2c support in the kernel is configured as
modules or is disabled. If it is compiled-in, you obviously
cannot replace it with modules in the next step.
* Do `lsmod'. If there are any old i2c or sensors modules loaded,
you MUST remove them (as root) with `rmmod'.
* Download, build, and install the latest i2c package,
(i2c-2.9.0 or later). The i2c subsystem found in the Linux 2.4
kernel trees, even the latest ones, is outdated and won't work.
Quickstart for i2c: make; (as root) make install
* Go back to the lm_sensors directory. Do `make'.
The warnings about .d files at the start are harmless.
* Do (as root) `make install'.
* Verify that /usr/local/lib is listed in /etc/ld.so.conf;
if it isn't, add it, then run (as root) `ldconfig'.
* Run (as root) `prog/mkdev/mkdev.sh' to create the device files,
unless you already have them or are running devfs or udev.
* Run (as root) `prog/detect/sensors-detect' to detect your hardware,
put the lines it suggests into /etc/modules.conf, and run all
the commands it suggests (`modprobe X', `sensors -s').
* Run `sensors' to see your output.
* That's it! If you have problems, read our excellent FAQ
(doc/FAQ or doc/lm_sensors-FAQ.html).
README
+74 -141
View File
@@ -1,161 +1,99 @@
=============================================================================
OVERVIEW OF THE LM-SENSORS PACKAGE
==================================
FOR QUICK INSTALLATION INSTRUCTIONS SEE THE 'QUICKSTART' FILE.
FOR FULL INSTALLATION INSTRUCTIONS SEE THE 'INSTALL' FILE.
FOR THE FAQ SEE THE 'doc/FAQ' or 'doc/lm_sensors-FAQ.html' FILES.
The lm-sensors package, version 3, provides user-space support for the
hardware monitoring drivers in Linux 2.6.5 and later. For older kernel
versions, you have to use lm-sensors version 2.
=============================================================================
The directories within this package:
OVERVIEW OF THE LM_SENSORS PACKAGE AND SUMMARY OF SUPPORTED DEVICES
!!! This package is ONLY for 2.6 and 2.4 kernels (2.4.10 or later). !!!
!!! For 2.4 kernels, this package requires i2c-2.9.0 or later. !!!
FOR 2.6 KERNELS, use only the userspace tools in this package!
Build and install them with 'make user' and 'make user_install'.
The kernel modules in this package will NOT compile for 2.6;
use the drivers already in the 2.6 kernel. Check the QUICKSTART
file for brief installation instructions please.
=============================================================================
This is the completely rewritten version 2 of lm_sensors, a collection of
modules for general SMBus[1] access and hardware monitoring.
Version 1 is now officially unsupported.
WARNING! The drivers in this package will work on reasonably recent 2.4
kernels only (2.4.10 and later).
Use lm_sensors-2.4.5 for 2.0 kernels.
Use lm_sensors-2.7.0 for 2.2, and early 2.4 (up to 2.4.9) kernels.
Use the drivers already in the kernel for 2.6 kernels; if you need
additional drivers in 2.6 please port and submit them to us.
HOWEVER, the userspace tools in this package will work for
both 2.4 and 2.6 kernels.
The I2C[2] package in existing 2.4 kernels is NOT sufficient
for compilation of this package. You need i2c-2.9.0 or later.
See the lm_sensors download page for further guidance:
http://www.lm-sensors.org/wiki/Download
* doc
Documentation.
* etc
A sample configuration file for libsensors, and a script to convert
lm-sensors version 2 configuration files to work with version 3.
* lib
The user-space sensors support library code (libsensors).
* prog
Several supporting programs. The most important ones are:
- sensors-detect: A program for detecting installed hardware and
recommending specific modules to load.
- sensors: A console tool to report sensor readings and set new
sensor limits.
- sensord: A daemon to watch sensor values and log problems. It
includes RRD support.
=============================================================================
INSTALLING LM-SENSORS
---------------------
At least the following I2C/SMBus adapters are supported:
Acer Labs M1533, M1535, M1543C and M1563
AMD 756, 766, 768 and 8111
AMD 8111 SMBus 2.0
Apple Hydra (used on some PPC machines)
ATI IXP200, IXP300, IXP400, SB600, SB700, SB800
DEC 21272/21274 (Tsunami/Typhoon - on Alpha boards)
Intel ICH/ICH0/ICH2/ICH3/ICH4/ICH5/ICH6/ICH7/ICH8/ICH9 (82801xx)
Intel 6300ESB, 631xESB/632xESB (ESB2)
Intel Tolapai, ICH10, PCH
Intel PIIX4 (used in many Intel chipsets)
Intel I810/I810E/I815/I845G GMCH
Intel 82443MX (440MX)
NVidia nForce, nForce2, nForce3, nForce4
ServerWorks OSB4, CSB5, CSB6, HT-1000
SiS 5595, 630, 645, 655, 730
SMSC Victory66
3Dfx Voodoo 3 and Banshee
VIA Technologies VT82C586B, VT82C596A/B, VT82C686A/B, VT8231,
VT8233, VT8233A, VT8235, VT8237R/A, VT8251,
CX700, VX800/VX820
See the INSTALL file.
At least the following hardware sensor chips are supported:
Analog Devices ADM1021, ADM1021A, ADM1022, ADM1023, ADM1024,
ADM1025, ADM1026, ADM1027, ADM1030, ADM1031,
ADM1032, ADM9240, ADT7461 and ADT7463
Asus AS99127F, ASB100 Bach
Dallas Semiconductor DS75, DS1621, DS1625, DS1775, and DS1780
Hewlett Packard Maxilife (several revisions including '99 NBA)
Fintek F71805F/FG
Fujitsu Siemens Poseidon, Scylla, Hermes
Genesys Logic GL518SM, GL520SM, GL523SM
Intel Xeon processor embedded sensors
ITE IT8705F, IT8712F
Maxim MAX1617, MAX1617A, MAX1619, MAX6650, MAX6651,
MAX6633, MAX6634, MAX6635, MAX6657, MAX6658, MAX6659
Microchip TC1068, TCM1617, TCN75
Myson MTP008
National Semiconductor LM63, LM75, LM76, LM78, LM78-J, LM79,
LM80, LM81, LM82, LM83, LM84, LM85, LM86, LM87,
LM89, LM90, LM92, LM93, LM99, PC87360,
PC87363, PC87364, PC87365, PC87366
Philips NE1617, NE1617A, NE1619
SiS 5595, 950 embedded sensors
SMSC 47M1xx embedded sensors, EMC6D100, EMC6D101, EMC6D102
TI THMC10 and THMC50
VIA Technologies VT1211, VT8231 and VT82C686A/B embedded sensors
Winbond W83781D, W83782D, W83783S, W83791D, W83792D,
W83627HF, W83627THF, W83637HF, W83687THF, W83697HF,
W83627EHF/EHG
HARDWARE SUPPORT
----------------
We also support some miscellaneous chips:
Dallas DS1307 real time clock
Intel Xeon processor embedded EEPROMs
Linear Technologies LTC1710
Philips Semiconductors PCF8574, PCF8591
DDC Monitor embedded EEPROMs
SDRAM Dimms with Serial Presence Detect EEPROMs
Smart Battery sensors
IPMI-BMC sensors
Philips Semiconductors SAA1064
The list above may be out of date;
see our Devices page at http://www.lm-sensors.org/wiki/Devices
for the latest information on supported devices.
You may also refer to doc/chips/SUMMARY for details on what each chip
can monitor.
We always appreciate testers. If you own a specific monitoring chip we do
not yet (properly) support, and are willing to help us out, please contact
us. Even if you have no programming knowledge, you could help us by running
new modules and reporting on the results and output. If you want to offer
more substantial help, this is very welcome too, of course.
Don't ask us whether we support a particular mainboard; we do not know.
We *do* know what hardware we support, but usually, it is easier to
install everything and run sensors-detect. It will tell you what hardware
you have (and incidentally, what corresponding drivers are needed).
SMBus, also known as System Management Bus, is a protocol for communicating
through a I2C ('I squared C') bus. Many modern mainboards have a System
Management Bus. There are a lot of devices which can be connected to a
SMBus; the most notable are modern memory chips with EEPROM memories and
chips for hardware monitoring.
To find out what hardware you have, just run 'sensors-detect' as root.
Most modern mainboards incorporate some form of hardware monitoring chips.
These chips read things like chip temperatures, fan rotation speeds and
voltage levels. There are quite a few different chips which can be used by
mainboard builders for approximately the same results.
Hardware monitoring chips often have an SMBus or I2C interface. Some are
connected to ISA bus instead. Some of them can do both, in which case we
either support both access methods (old drivers) or only support ISA
access (new drivers) as it is faster.
Laptops, on the other hand, rarely expose any hardware monitoring
chip. They often have some BIOS and/or ACPI magic to get the CPU
temperature value, but that's about it. For such laptops, the lm-sensors
package is of no use (sensors-detect will not find anything), and you have
to use acpi instead.
Because the SMBus is just a special case of the generalized I2C bus, we can
simulate the SMBus protocol on plain I2C busses. These busses are sometimes
used in other parts of your computer. If a supported chip is attached to
one of these additional busses, they can be used too.
This package doesn't contain chip-specific knowledge. It will support all
the hardware monitoring chips your kernel has drivers for. In other words,
if you find out that you have unsupported hardware (e.g. sensors-detect
told you so) then it means that you need a more recent kernel, or you
even need to wait for a new kernel driver to be written. Updating the
lm-sensors package itself will not help.
Please read INSTALL before trying to compile and install these modules.
There is a lot of additional documentation in the doc/ subdirectory.
LIBSENSORS
----------
The kernel drivers communicate their information through the /sys
interface. Because every motherboard is different, the drivers always
advert the measurements at their pins. This means that the values they
report are not always immediately relevant to you. They have to be
labelled properly, and sometimes they must be scaled to correspond to
real-world values.
libsensors is a (shared or static) library of access functions. It
offers a simple-to-use interface for applications to access the sensor
chip readings and configure them as you like. It has a configuration
file where you can put all the motherboard-specific labels and
conversion rules. That way, all applications do not need to duplicate
the effort and can simply link with libsensors and work out of the box.
APPLICATIONS
------------
This package contains an example console program that reports all current
sensors values. This program is called 'sensors'. You can use it as a
reference implementation for more intricate programs. It also contains a
daemon watching for sensor values, logging alarms and feeding an RRD
database with the sensor measurements.
This package does not contain a nice graphical monitor. See
http://www.lm-sensors.org/wiki/UsefulLinks for pointers to such programs.
OTHER INFORMATION
-----------------
The developers of this package can be reached through a mailing-list
(see http://www.lm-sensors.org/wiki/AuthorsAndContributors). Do not hesitate
to mail us if you have questions, suggestions, problems, want to
contribute, or just want to report it works for you. But please try to
read the documentation and FAQ before you ask any questions!
read the documentation before you ask any questions! It's all under doc/.
Also make sure you read the FAQ at http://www.lm-sensors.org/wiki/FAQ.
The latest version of this package can always be found at:
http://www.lm-sensors.org/wiki/Download. Pre-release versions can be
@@ -168,8 +106,3 @@ Note that libsensors falls under the GPL, not the LGPL. In more human
language, that means it is FORBIDDEN to link any application to the
library, even to the shared version, if the application itself does not
fall under the GPL.
-----
[1] SMBus is a trademark of Intel Corporation
[2] I2C is a trademark of Philips Corporation
README.directories
-18
View File
@@ -1,18 +0,0 @@
The directories within this package:
* doc
Documentation about the modules within this package, and all other things.
* etc
A sample configuration file for the 'sensors' program.
* kernel
The kernel modules: I2C/SMBus master drivers, and sensor chip drivers.
* lib
The user-space sensors support library code.
* mkpatch
A script for creating a kernel patch.
* prog
Several supporting programs. Includes programs for detecting installed
hardware and recommending specific modules to install.
Also includes programs to report sensor readings, for use
after the package has been installed.
Some of these use the sensors support library, some do not.
README.patches
-30
View File
@@ -1,30 +0,0 @@
These patches were pre-made using the i2c and lm_sensors packages.
In this document, the example version used of this patch is
lm_sensors-2.4.0-i2c-kernel-2.2.12. Your actual version may be
newer than this.
To use:
* Download a virgin kernel distribution of the exact version as
this patch distribution.
* Unpackage and install the kernel source, but do not configure
or 'make' it yet.
* Apply the I2C patch, for example:
# patch -d /usr/src/linux -p1 < lm_sensors-2.4.0-i2c-kernel-2.2.12.patch
* Apply the Lm_sensors patch, for example:
# patch -d /usr/src/linux -p1 < lm_sensors-2.4.0-lm-kernel-2.2.12.patch
The patches must be applied in this order: i2c then lm_sensors
Enjoy!
-- The Lm_sensors Development Team
README.thinkpad
-108
View File
@@ -1,108 +0,0 @@
**** WARNING: IBM Thinkpad users should not install lm_sensors! ****
The eeprom of some IBM Thinkpads has been corrupted after installing
lm_sensors.
In our releases through 2.6.4, sensors-detect (our userspace detection script)
corrupts the Atmel 24RF08 eeprom. We have verified this in testing.
After the eeprom is corrupted, the checksum verification in the BIOS
will fail and the Thinkpad will not boot.
The 24RF08 is an 8K eeprom appearing at addresses 0x54 - 0x57 with
an additional "access protection page" at address 0x5c.
This is an unusual eeprom that contains a RFID (Radio Frequency ID)
port for wireless access, and elaborate access protection mechanisms.
The 24RF08 gets confused (presumably due to a state machine flaw) by
the 'quick write 0' (*) probes our package uses for detection.
This behavior is in violation of the I2C specification. This corruption
mechanism has never been reported to us on any other eeprom,
Atmel or otherwise.
We made several changes in release 2.6.5 (released September 15, 2002)
to minimize the chance of corruption.
Later evolutions were made and the current state is:
1) The probing command (quick write 0) has been replaced by a different
command (read byte) for addresses where eeproms are known to live.
This should prevent corruption of 24RF08 eeproms in any system,
IBM or not. A similar change was made to i2cdetect as well, although
no corruption was ever reported using this tool.
2) The i2c-piix4 module (the bus driver that is used for Intel PIIX4-based
systems, including IBM Thinkpads) now accesses DMI information
in the BIOS to identify the system manufacturer. If the system
manufacturer is IBM, i2c-piix4 will print a message and exit.
As the 24RF08 is on the PIIX4 SMBus, this prevents access to
the 24RF08.
3) The sequence of probes in the eeprom module (when loaded with
checksum=1) has been changed so that 24RF08 eeproms will
not be corrupted. This *should* prevent corruption of 24RF08
eeproms in non-IBM systems.
We do not have any reports of this corruption mechanism in releases
2.6.4 or earlier but have verified that it can happen.
The ddcmon driver was changed in the same way, just in case.
Even with these changes, we still DO NOT RECOMMEND INSTALLING
lm_sensors 2.6.5 or later on IBM Thinkpads, because:
1) While these changes will dramatically reduce the chance of 24RF08
corruption, these changes have not been heavily tested.
2) lm_sensors won't run on most IBM systems because of these changes.
3) Most IBM Thinkpads contain a proprietary Embedded Controller which
is used to access sensors. This controller is not on the SMBus,
and IBM will not release the programming interface to the
controller. So lm_sensors isn't useful on these Thinkpads anyway.
You may want to try ACPI instead, it should let you get some information
about temperatures and fan status.
As described above, our 2.6.5 release "blacklisted" all IBM systems.
For a moment, we have been planning to refine the system detection
so that only those models containing 24RF08's are blacklisted. After that,
we planned to use a different approach: a "white list" of known-to-be-safe
systems. In both cases, it would require continuous updates of a machines
list. This would have been slow and inefficient.
The latest idea is to stop using the dangerous command for EEPROM
addresses. That way, risks of corruption are reduced to zero. This was
already done for user-space tools, as mentioned above. Once this will
have been tested and we are sure that there are no drawbacks, we'll
do the same on the kernel side in Linux 2.6. The change won't occur in
Linux 2.4 however, because it implies changes to both i2c modules and
lm_sensors modules. It is possible to use mismatching versions of
these modules, and when doing so, the fix would become more dangerous
than helpful.
We do not have any reports of 24RF08 eeproms on non-IBM systems.
If there are any such systems with 24RF08 eeproms, these changes will
reduce the chances of corruption. However, there are
theoretical scenarios (involving multiple bus masters,
SMP systems, or simultaneous bus access) in which 24RF08's could
still be corrupted. If you know of any non-IBM systems which contain
these eeproms, please contact us.
Thanks to IBM, the Linux Thinkpad Mailing List, and Joe in Australia
for their assistance on this issue.
For more information, see:
The Linux Thinkpad Mailing List
http://www.bm-soft.com/~bm/tp_mailing.html
Joe in Australia's Thinkpad Password Recovery Site
http://www.ja.axxs.net/unlock/
Atmel 24RF08 Datasheet
http://www.atmel.com/dyn/products/product_card.asp?part_id=2370
Site in the US that sells replacement AT24RF08 chips for all models
http://www.pwcrack.com/
(*) 'Write Quick 0' is not an actual write and should never generate
a write operation to an eeprom location.
TODO
-104
View File
@@ -1,104 +0,0 @@
LM-Sensors TODO list
Contact us if you have comments or wish to help.
------------------------------------------------
KERNEL MODULES
==============
* Harmonize 'smart fan' support.
The following drivers support pwm. The ones that support
automatic or smart fan support are identified.
We have a /proc standard for manual PWM support that allows
for /proc based applications like pwmconfig and fancontrol
in our package.
Without a /proc standard for smart fan support such applications
are much more difficult.
Driver Manual PWM Smart fan
adm1026 standard not supported
asb100 standard ??
it87 non-std yes
lm85 standard yes
vt1211 doesn't work not supported
w83627hf standard not supported
w83781d standard not supported (791 only)
The following drivers are for chips that have manual PWM only.
Driver Manual PWM
mtp008 standard
smsc47m1 standard
vt8231 standard
w83781d (except 791d) standard
* Assistance on how to fix module refcounting is welcome.
To my understanding, it does not handle client->adapter->owner
correctly now, and it is possible to rmmod adapter while one of its
clients is in use.
* "uninstall" Makefile target.
* ACPI and SMBus host
- ACPI subsystem may access SMBus host too. Locks?
- On my ancient board using i2c-via, suspend and power switch status
seems to be in the same register with SCL and SDA.
* Suspend-to-disk, losing Vcc
- Reset i2c client to avoid alarms and SCI interrupts. Currently
sensors do not create interrupt with alarms.
* Return from suspend
- Reinitialize i2c client.
* Handle -1 returns from i2c layer rather than just delivering 0xFF to
/proc and libsensors; report errors through /proc 'alarms' or
new 'fail' entry? See adm1021 for a partial example.
* ALL: cleanup_module is void; check also that cleaning up is done
properly, now we know that the module will be unloaded whatever we
do.
* ALL chip drivers: add a readonly insmod option so we don't cause APM/ACPI
to go insane.
* gl518sm: using iterate==2 causes a tread to be started. this thread remains
even after setting iterate==1 and/or removing the gl518sm module
<koenig@uranus.tat.physik.uni-tuebingen.de>
* LM78 detection: Tom Webster has proven that the reset bit in the
id register can be one (strange!)
* maxilife.c: Introduce new insmod variables
* maxilife.c: Round REG_TO_VID correctly
* Support 10-bit addresses. At this moment, they are supported nowhere, except
in Simon Vogl's i2c modules.
* adm9240: check whether the current voltage computations are correct.
Probably not, as they are different from the datasheet specifications.
Also check for the supported dallas chip.
* lm80: Check how OS alarms work. At page 17 of the sheet, it tells
something completely different from the description at page 25.
LIBRARY
=======
* Easier use of /proc and libsensors without knowing the chip type
At the moment a programmer wishing to use the lm_sensors package needs to know
what chips are supported and needs to add all those chips into his package.
If you were to add a field or function to your structures to the effect of
sensor-function a programmer could use the package a lot more simply.
For values you could do something like -
enum sensor-type { volt, fan, temp, volt_min, volt_max, fan_div, fan_min,
temp_over, temp_hyst }
* Some library routines are pretty inefficient right now.
* Library should be split in more separate files, for better linking
behaviour.
* Some adm9240 labels start with a digit; change this, it leads to confusing
syntax in the conf file (they have to be quoted)
doc/FAQ
-1582
View File
File diff suppressed because it is too large. Load diff
doc/Makefile
-14
View File
@@ -1,14 +0,0 @@
#
# quick makefile for the FAQ.
# So that both the text and html FAQ are accessible on the web
# they are checked into SVN along with the .texi source.
# Don't forget to update version.texi.
# Run 'make' and then check in all 4 files after editing the .texi source.
#
all:: lm_sensors-FAQ.html FAQ
%.html: %.texi version.texi
LANG=C makeinfo --html --no-split --number-sections $<
FAQ: lm_sensors-FAQ.texi
LANG=C makeinfo --no-headers --number-sections -o FAQ $<
doc/busses/i2c-ali1535
-53
View File
@@ -1,53 +0,0 @@
Kernel driver `i2c-ali1535.o'
Status: Beta; block reads/writes untested (not used by any current chip
driver)
Supported adapters:
* Acer Labs, Inc. ALI 1535 (south bridge)
Datasheet: Available at the Acer Labs website (password may be required)
Author: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock
<phil@netroedge.com>, Mark D. Studebaker <mdsxyz123@yahoo.com> and
Dan Eaton <dan.eaton@rocketlogix.com>
License: GPL
Module Parameters
-----------------
(none)
Description
-----------
This is the driver for the SMB Host controller on
Acer Labs Inc. (ALI) M1535 South Bridge.
The M1535 is a South bridge for portable systems.
It is very similar to the M15x3 South bridges also produced
by Acer Labs Inc. Some of the registers within the part
have moved and some have been redefined slightly. Additionally,
the sequencing of the SMBus transactions has been modified
to be more consistent with the sequencing recommended by
the manufacturer and observed through testing. These
changes are reflected in this driver and can be identified
by comparing this driver to the i2c-ali15x3 driver.
For an overview of these chips see http://www.acerlabs.com
The SMB controller is part of the 7101 device, which is an
ACPI-compliant Power Management Unit (PMU).
The whole 7101 device has to be enabled for the SMB to work.
You can't just enable the SMB alone.
The SMB and the ACPI have separate I/O spaces.
We make sure that the SMB is enabled. We leave the ACPI alone.
Features
--------
This driver controls the SMB Host only.
This driver does not use interrupts.
doc/busses/i2c-ali15x3
-135
View File
@@ -1,135 +0,0 @@
Kernel driver `i2c-ali15x3.o'
Status: Complete and tested; block reads/writes untested (not used by any
current chip driver)
Supported adapters:
* Acer Labs, Inc. ALI 1533 and 1543C (south bridge)
Datasheet: Available at the Acer Labs website (password required)
Author: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock
<phil@netroedge.com>, and Mark D. Studebaker <mdsxyz123@yahoo.com>
License: GPL
Module Parameters
-----------------
* force_addr: int
Initialize the base address of the i2c controller
Notes
-----
The force_addr parameter is useful for boards that don't set the address
in the BIOS. Does not do a PCI force; the device must still be present
in lspci. Don't use this unless the driver complains that the
base address is not set.
Example: 'modprobe i2c-ali15x3 force_addr=0xe800'
SMBus periodically hangs on ASUS P5A motherboards and can only be
cleared by a power cycle. Cause unknown (see Issues below).
Description
-----------
This is the driver for the SMB Host controller on
Acer Labs Inc. (ALI) M1541 and M1543C South Bridges.
The M1543C is a South bridge for desktop systems.
The M1541 is a South bridge for portable systems.
They are part of the following ALI chipsets:
"Aladdin Pro 2": Includes the M1621 Slot 1 North bridge
with AGP and 100MHz CPU Front Side bus
"Aladdin V": Includes the M1541 Socket 7 North bridge
with AGP and 100MHz CPU Front Side bus
Some Aladdin V motherboards:
Asus P5A
Atrend ATC-5220
BCM/GVC VP1541
Biostar M5ALA
Gigabyte GA-5AX (** Generally doesn't work because the BIOS doesn't
enable the 7101 device! **)
Iwill XA100 Plus
Micronics C200
Microstar (MSI) MS-5169
"Aladdin IV": Includes the M1541 Socket 7 North bridge
with host bus up to 83.3 MHz.
For an overview of these chips see http://www.acerlabs.com
At this time the full data sheets on the web site are password protected,
however if you contact the ALI office in San Jose
they may give you the password.
The M1533/M1543C devices appear as FOUR separate devices
on the PCI bus. An output of lspci will show something similar
to the following:
00:02.0 USB Controller: Acer Laboratories Inc. M5237 (rev 03)
00:03.0 Bridge: Acer Laboratories Inc. M7101 <= THIS IS THE ONE WE NEED
00:07.0 ISA bridge: Acer Laboratories Inc. M1533 (rev c3)
00:0f.0 IDE interface: Acer Laboratories Inc. M5229 (rev c1)
** IMPORTANT **
** If you have a 1533 or 1543C on the board and you get
** "ali15x3.o: Error: Can't detect ali15x3!"
** then run lspci.
** If you see the 1533 and 5229 devices but NOT the 7101 device,
** then you must enable ACPI, the PMU, SMB, or something similar
** in the BIOS. If you can't figure out how to enable the
** 7101 device in the BIOS, you can try one of the "hotplug" modules -
** see below.
** The driver won't work if it can't find the 7101 device.
The SMB controller is part of the 7101 device, which is an
ACPI-compliant Power Management Unit (PMU).
The whole 7101 device has to be enabled for the SMB to work.
You can't just enable the SMB alone.
The SMB and the ACPI have separate I/O spaces.
We make sure that the SMB is enabled. We leave the ACPI alone.
Features
--------
This driver controls the SMB Host only.
The SMB Slave controller on the M15X3 is not enabled.
This driver does not use interrupts.
Issues
------
This driver requests the I/O space for only the SMB
registers. It doesn't use the ACPI region.
On the ASUS P5A motherboard, there are several reports that
the SMBus will hang and this can only be resolved by
powering off the computer. It appears to be worse when the board
gets hot, for example under heavy CPU load, or in the summer.
There may be electrical problems on this board.
On the P5A, the W83781D sensor chip is on both the ISA and
SMBus. Therefore the SMBus hangs can generally be avoided
by accessing the W83781D on the ISA bus only.
Hot Plug Modules
----------------
There are EXPERIMENTAL "hotplug" modules which will enable the
m7101 device if it is not enabled on your motherboard.
Use these at your own risk. Read the README file carefully.
m7101 Version 0.1 for 2.2 and early 2.3 kernels:
README: http://www.netroedge.com/~lm78/misc/README-m7101.txt
source and README: http://www.netroedge.com/~lm78/misc/m7101-0.1.tar.gz
m7101 Version 0.2 for 2.4 and later 2.3 kernels:
In the directory prog/hotplug in this package.
Must be built separately.
doc/busses/i2c-amd756
-30
View File
@@ -1,30 +0,0 @@
Kernel driver `i2c-amd756.o'
Status: Complete and somewhat tested
Supported adapters:
* AMD 756
* AMD 766
* AMD 768
* AMD 8111
Datasheets: Publicly available on AMD website
* nVidia nForce
Datasheet: Unavailable
Module Parameters
-----------------
(none)
Description
-----------
This driver supports the AMD 756, 766, 768 and 8111 Peripheral Bus Controllers, and
the nVidia nForce.
Note that for the 8111, there are two SMBus adapters. The SMBus 1.0 adapter is
supported by this driver, and the SMBus 2.0 adapter is supported
by the i2c-amd8111 driver.
doc/busses/i2c-amd8111
-48
View File
@@ -1,48 +0,0 @@
Kernel driver `i2c-adm8111.o'
Status: Slightly tested.
Supported adapters:
* AMD-8111 SMBus 2.0 PCI interface
Datasheets:
AMD datasheet not yet available, but almost everything can be found
in the publicly available ACPI 2.0 specification, which the adapter
follows.
Author: Vojtech Pavlik <vojtech@suse.cz>
Module Parameters
-----------------
None.
Description
-----------
If you see something like this:
00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
Subsystem: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
Flags: medium devsel, IRQ 19
I/O ports at d400 [size=32]
in your 'lspci -v', then this driver is for your chipset.
Process Call Support
--------------------
Supported.
SMBus 2.0 Support
-----------------
Supported. Both PEC and block process call support is implemented.
Slave mode or host notification are not yet implemented.
Notes
-----
Note that for the 8111, there are two SMBus adapters. The SMBus 2.0 adapter is
supported by this driver, and the SMBus 1.0 adapter is supported
by the i2c-amd756 driver.
doc/busses/i2c-hydra
-35
View File
@@ -1,35 +0,0 @@
Kernel driver `i2c-hydra.o'
Status: Complete and somewhat tested
Supported adapters:
* Apple `Hydra' Mac I/O
Datasheet: Was publicly available from the Apple website, now seems to
have disappeared?!?
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Module Parameters
-----------------
(none)
Description
-----------
i2c-hydra is an i2c bus driver for CHRP motherboards with the Apple Hydra Mac
I/O.
Your /proc/pci or lspci listing must show this :
Unknown class: Apple Hydra (rev 2)
To install this driver, simply do
# modprobe i2c-hydra
This driver uses the i2c-algo-bit module which must be
modprobed and/or enabled in your kernel
(Character Devices -> I2C Support -> I2C Bit-Banging Interfaces).
doc/busses/i2c-i801
-110
View File
@@ -1,110 +0,0 @@
Kernel driver `i2c-i801.o'
Status: Tested and stable.
Block reads/writes lightly tested.
HW PEC support Beta.
I2C Block Read support Beta.
Supported adapters:
* Intel 82801AA and 82801AB (ICH and ICH0 - part of the
'810' and '810E' chipsets)
* Intel 82801BA (ICH2 - part of the '815E' chipset)
* Intel 82801CA/CAM (ICH3)
* Intel 82801DB (ICH4)
* Intel 82801EB/ER (ICH5)
* Intel 6300ESB/ESB2
* Intel 82801FB/FR/FW/FRW (ICH6)
* Intel ICH7/ICH8/ICH9
* Intel EP80579 (Tolapai)
* Intel 82801JI (ICH10)
* Intel PCH
Datasheets: Publicly available at the Intel website
Authors: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock
<phil@netroedge.com>, and Mark Studebaker <mdsxyz123@yahoo.com>
Module Parameters
-----------------
* force_addr: int
Forcibly enable the ICH at the given address. EXTREMELY DANGEROUS!
Description
-----------
The ICH (properly known as the 82801AA), ICH0 (82801AB),
ICH2 (82801BA), ICH3 (82801CA/CAM) and later devices
are Intel chips that are a part of
Intel's '810' chipset for Celeron-based PCs,
'810E' chipset for Pentium-based PCs, '815E' chipset, and others.
The ICH chips contain at least SEVEN separate PCI functions
in TWO logical PCI devices.
An output of lspci will show something similar to the following:
00:1e.0 PCI bridge: Intel Corporation: Unknown device 2418 (rev 01)
00:1f.0 ISA bridge: Intel Corporation: Unknown device 2410 (rev 01)
00:1f.1 IDE interface: Intel Corporation: Unknown device 2411 (rev 01)
00:1f.2 USB Controller: Intel Corporation: Unknown device 2412 (rev 01)
00:1f.3 Unknown class [0c05]: Intel Corporation: Unknown device 2413 (rev 01)
The SMBus controller is function 3 in device 1f.
Class 0c05 is SMBus Serial Controller.
If you do NOT see the 24x3 device at function 3, and you can't
figure out any way in the BIOS to enable it,
(and especially if you have an Asus P4B board),
see prog/hotplug/README.p4b.
The ICH chips are quite similar to Intel's PIIX4 chip,
at least in the SMBus controller.
See the file i2c-piix4 for some additional information.
Process Call Support
--------------------
Not supported.
I2C Block Read Support
----------------------
The ICH4 supports a special 3-byte address (command code
plus 2 more bytes) I2C block read.
The driver and the kernel i2c protocol stack do not
support this.
The ICH5 and higher support a standard 1-byte address (command code)
I2C block read. The driver does support this.
SMBus 2.0 Support
-----------------
The 82801DB (ICH4) and later chips support several SMBus 2.0 features.
Kernel and driver support are as follows:
Feature Kernel Driver
Slave mode no no
Host notify no no
Block PEC yes yes
Hardware PEC yes yes
Other ICH4 and later Features
-----------------------------
The following additional features are also _not_ supported:
32 Byte buffer
**********************
The lm_sensors project gratefully acknowledges the support of
Texas Instruments in the initial development of this driver.
The lm_sensors project gratefully acknowledges the support of
Intel in the development of SMBus 2.0 / ICH4 features of this driver.
doc/busses/i2c-i810
-66
View File
@@ -1,66 +0,0 @@
Kernel driver `i2c-i810.o'
Status: Stable
Supported adapters:
* Intel 82810, 82810-DC100, 82810E, and 82815 (GMCH)
* Intel 82845G (GMCH)
Author: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock
<phil@netroedge.com>,
Kyösti Mälkki <kmalkki@cc.hut.fi>,
and Mark D. Studebaker <mdsxyz123@yahoo.com>
Main contact: Mark Studebaker <mdsxyz123@yahoo.com>
Module Parameters
-----------------
(none)
Description
-----------
This driver uses the i2c-algo-bit module which must be
modprobed and/or enabled in your kernel
(Character Devices -> I2C Support -> I2C Bit-Banging Interfaces).
WARNING: If you have an '810' or '815' motherboard, your standard I2C
temperature sensors are most likely on the 801's I2C bus.
You want the i2c-i801.o driver for those, not this driver.
Now for the i2c-i810...
The GMCH chip contains two I2C interfaces.
The first interface is used for DDC (Data Display Channel)
which is a serial channel through the VGA monitor connector
to a DDC-compliant monitor. This interface is defined by the
Video Electronics Standards Association (VESA). The standards
are available for purchase at http://www.vesa.org .
The second interface is a general-purpose I2C bus.
It may be connected to a TV-out chip such as the BT869 or possibly
to a digital flat-panel display.
Stability
---------
Apparently stable.
Supported Devices
-----------------
See above.
Features
--------
Both busses use the i2c-algo-bit driver for 'bit banging' and support
for specific transactions is provided by i2c-algo-bit.
Issues
------
If you enable bus testing in i2c-algo-bit (insmod i2c-algo-bit bit_test=1),
the test may fail; if so, the i2c-i810 driver won't be inserted.
However, we think this has been fixed.
doc/busses/i2c-ipmb
-55
View File
@@ -1,55 +0,0 @@
Kernel driver `i2c-ipmb.o'
Status: IN DEVELOPMENT - DOESN'T WORK AT ALL - DON'T BOTHER TRYING IT
Supported adapters:
* IPMI BMC
Author: Mark D. Studebaker <mdsxyz123@yahoo.com>
Module Parameters
-----------------
(none)
Description
-----------
This is an adapter which provides access to the IPMB
(Intelligent Platform Management Bus) and other I2C / SMBus busses
behind the BMC (Baseboard Management Controller) via
IPMI (Intelligent Platform Management Interface).
This provides low-level access to all devices on busses
behind the BMC. For high-level access to sensors known
to the BMC, use the i2c-ipmi and bmcsensors modules.
This module REQUIRES the IPMI kernel patch by Corey Minyard,
v13 or higher, available at http://openipmi.sourceforge.net .
Other IPMI drivers are not supported.
See http://www.intel.com/design/servers/ipmi/ for
IPMI standards information.
You must configure the following features in your kernel
(under Character Devices):
IPMI top-level message handler
IPMI KCS handler
The IPMI device interface and IPMI watchdog handler are not required.
If the KCS handler (ipmi_kcs_drv) is configured as a module,
you must modprobe it separately, it will not load automatically
when you modprobe i2c-ipmi or ipmi_msghandler (unless you set up
/etc/modules.conf to load ipmi_kcs_drv when ipmi_msghandler is loaded).
Issues
------
Only one BMC is supported - shouldn't be a problem.
Alpha!
**********************
The lm_sensors project gratefully acknowledges the support of
Hewlett Packard (Ft. Collins) in the development of this driver.
doc/busses/i2c-ipmi
-61
View File
@@ -1,61 +0,0 @@
Kernel driver `i2c-ipmi.o'
Status: Alpha
Supported adapters:
* IPMI BMC
Author: Mark D. Studebaker <mdsxyz123@yahoo.com>
Module Parameters
-----------------
(none)
Description
-----------
This is a "dummy" adapter which provides access to the
BMC (Baseboard Management Controller) via IPMI (Intelligent Platform
Management Interface). It is used by the bmcsensors module.
Together with the bmcsensors module, this provides high-level
access to sensors known by the BMC. For low-level access to
IPMB (I2C/SMBus) busses behind the BMC, use the i2c-ipmb module.
This module REQUIRES the IPMI kernel patch by Corey Minyard,
v13 or higher, available at http://openipmi.sourceforge.net .
Other IPMI drivers are not supported.
See http://www.intel.com/design/servers/ipmi/ for
IPMI standards information.
You must configure the following features in your kernel
(under Character Devices):
IPMI top-level message handler
IPMI KCS handler
The IPMI device interface and IPMI watchdog handler are not required.
If the KCS handler (ipmi_kcs_drv) is configured as a module,
you must modprobe it separately, it will not load automatically
when you modprobe i2c-ipmi or ipmi_msghandler (unless you set up
/etc/modules.conf to load ipmi_kcs_drv when ipmi_msghandler is loaded).
Issues
------
Only one BMC is supported - shouldn't be a problem.
Only one client is supported - to be fixed.
Libsensors was hacked to support this dummy driver; only
the ISA dummy driver was supported previously.
The library needs further enhancements for full
dummy driver support.
Alpha!
**********************
The lm_sensors project gratefully acknowledges the support of
Hewlett Packard (Ft. Collins) in the development of this driver.
doc/busses/i2c-nforce2
-55
View File
@@ -1,55 +0,0 @@
Kernel driver i2c-nforce2
-------------------------
Status: Well tested
Supported adapters:
* nVidia nForce2 SMBus PCI interface
(10de:0064, included in nForce2 MCP,
10de:0084, included in nForce2 Ultra 400 MCP)
Datasheet: not publicly available, but seems to be similar to the
AMD-8111 SMBus 2.0 adapter.
* nVidia nForce3 SMBus PCI interface
(10de:00d4, included in nForce3 Pro150 MCP,
10de:00e4, included in nForce3 250Gb MCP)
Datasheet: same as for nForce2 SMBus PCI interface
* nVidia nForce4 SMBus PCI interface
(10de:0052, included in nForce4 MCP)
(10de:0034, included in nForce4 MCP-04)
(10de:0264, included in nForce4 MCP51)
(10de:0368, included in nForce4 MCP55)
(10de:03eb, included in nForce MCP61)
(10de:0446, included in nForce MCP65)
Datasheet: same as for nForce2 SMBus PCI interface
Author: Hans-Frieder Vogt <hfvogt@arcor.de>
Description
-----------
i2c-nforce2 is a driver for the SMBuses included in the nVidia nForce2,
nForce3 and nForce4 MCP.
If your 'lspci -v' listing shows something like the following,
00:01.1 SMBus: nVidia Corporation: Unknown device 0064 (rev a2)
Subsystem: Asustek Computer, Inc.: Unknown device 0c11
Flags: 66Mhz, fast devsel, IRQ 5
I/O ports at c000 [size=32]
Capabilities: <available only to root>
then this driver should support the SMBuses of your motherboard.
Notes
-----
The SMBus adapter in the nForce2/3/4 chipset seems to be very similar to the
SMBus 2.0 adapter in the AMD-8111 southbridge. However, I could only get the
driver to work with direct I/O access, which is different to the EC interface
of the AMD-8111.
Tested on Asus A7N8X. The ACPI DSDT table of the Asus A7N8X lists two SMBuses,
both of which are supported by this driver.
doc/busses/i2c-piix4
-100
View File
@@ -1,100 +0,0 @@
Kernel driver `i2c-piix4.o'
Status: Complete and well-tested
except for Victory66 support which is Alpha.
Supported adapters:
* Intel 82371AB PIIX4 and PIIX4E
* Intel 82443MX (440MX)
Datasheet: Publicly available at the Intel website
* ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges
Datasheet: Only available via NDA from ServerWorks
* ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges
Datasheet: Not publicly available
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
Datasheet: Publicly available at the SMSC website http://www.smsc.com
Author: Frodo Looijaard <frodol@dds.nl> and Philip Edelbrock
<phil@netroedge.com>
Module Parameters
-----------------
* force: int
Forcibly enable the PIIX4. DANGEROUS!
* force_addr: int
Forcibly enable the PIIX4 at the given address. EXTREMELY DANGEROUS!
Description
-----------
The PIIX4 (properly known as the 82371AB) is an Intel chip with a lot of
functionality. Among other things, it implements the PCI bus. One of its
minor functions is implementing a System Management Bus. This is a true
SMBus - you can not access it on I2C levels. The good news is that it
natively understands SMBus commands and you do not have to worry about
timing problems. The bad news is that non-SMBus devices connected to it
can confuse it mightily. Yes, this is known to happen...
Cat /proc/pci, and see whether it contains an entry like this:
Bus 0, device 1, function 3:
Bridge: Intel 82371AB PIIX4 ACPI (rev 1).
Medium devsel. Fast back-to-back capable.
Bus and device numbers may differ, but the function number must be identical
(like many PCI devices, the PIIX4 incorporates a number of different
'functions', which can be considered as separate devices). If you find such
an entry, you have a PIIX4 SMBus controller.
On some computers (most notably, some Dells), the SMBus is disabled by
default. If you use the insmod parameter 'force=1', the kernel module
will try to enable it. THIS IS VERY DANGEROUS! If the BIOS did not
set up a correct address for this module, you could get in big trouble
(read: crashes, data corruption, etc.). Try this only as a last resort
(try BIOS updates first, for example), and backup first! An even more
dangerous option is 'force_addr=<IOPORT>'. This will not only enable the
PIIX4 like 'force' foes, but it will also set a new base I/O port address.
The SMBus parts of the PIIX4 needs a range of 8 of these addresses to
function correctly. If these addresses are already reserved by some other
device, you will get into big trouble! DON'T USE THIS IF YOU ARE NOT VERY
SURE ABOUT WHAT YOU ARE DOING!
The PIIX4E is just an new version of the PIIX4; it is supported as well. The
PIIX/PIIX3 does not implement an SMBus or I2C bus, so you can't use this
driver on those mainboards.
The ServerWorks Southbridges, the Intel 440MX,
and the Victory66 are identical to the PIIX4 in I2C/SMBus support.
If you own Force CPCI735 motherboard or other OSB4 based systems you may need
to change the SMBus Interrupt Select register so the SMBus controller uses
the SMI mode.
1) Use lspci command and locate the PCI device with the SMBus controller:
00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f)
The line may vary for different chipsets. Please consult the driver source
for all possible PCI ids (and lspci -n to match them). Lets assume the
device is located at 00:0f.0.
2) Now you just need to change the value in 0xD2 register. Get it first with
command: lspci -xxx -s 00:0f.0
If the value is 0x3 then you need to change it to 0x1
setpci -s 00:0f.0 d2.b=1
Please note that you don't need to do that in all cases, just when the SMBus is
not working properly.
Hardware-specific issues
------------------------
This driver will refuse to load on IBM systems with an Intel PIIX4 SMBus.
Some of these machines have an RFID EEPROM (24RF08) connected to the SMBus,
which can easily get corrupted due to a state machine bug. These are mostly
Thinkpad laptops, but desktop systems may also be affected. We have no list
of all affected systems, so the only safe solution was to prevent access to
the SMBus on all IBM systems (detected using DMI data.)
For additional information, read README.thinkpad.
doc/busses/i2c-savage4
-42
View File
@@ -1,42 +0,0 @@
Kernel driver `i2c-savage4.o'
Status: Alpha
Supported adapters:
* Savage4
* Savage2000
Author: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock
<phil@netroedge.com>, Ralph Metzler <rjkm@thp.uni-koeln.de>,
Alexander Wold, and Mark D. Studebaker <mdsxyz123@yahoo.com>
Main contact: Sensors mailing list
Module Parameters
-----------------
(none)
Description
-----------
The Savage4 chips contain two I2C interfaces (aka a I2C 'master'
or 'host').
The first interface is used for DDC (Data Display Channel)
which is a serial channel through the VGA monitor connector
to a DDC-compliant monitor. This interface is defined by the
Video Electronics Standards Association (VESA). The standards
are available for purchase at http://www.vesa.org .
The DDC bus is not yet supported because its register is not
directly memory-mapped.
The second interface is a general-purpose I2C bus.
This is the only interface supported by the driver at the moment.
This driver uses the i2c-algo-bit module which must be
modprobed and/or enabled in your kernel
(Character Devices -> I2C Support -> I2C Bit-Banging Interfaces).
doc/busses/i2c-sis5595
-56
View File
@@ -1,56 +0,0 @@
Kernel driver `i2c-sis5595.o'
Status: Beta
Supported adapters:
* Silicon Integrated Systems Corp. SiS5595 Southbridge
Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.
Author: Frodo Looijaard <frodol@dds.nl> and
Mark D. Studebaker <mdsxyz123@yahoo.com>
Note: all have mfr. ID 0x1039.
SUPPORTED PCI ID
5595 0008
Note: The chips below contain a 0008 device which is incompatible with the
5595. We recognize these by the presence of the listed
"blacklist" PCI ID and refuse to load.
NOT SUPPORTED PCI ID BLACKLIST PCI ID
540 0008 0540
550 0008 0550
5513 0008 5511
5581 0008 5597
5582 0008 5597
5597 0008 5597
5598 0008 5597/5598
630 0008 0630
645 0008 0645
730 0008 0730
735 0008 0735
Module Parameters
-----------------
force_addr=0xaddr Set the I/O base address. Useful for boards
that don't set the address in the BIOS. Does not do a
PCI force; the device must still be present in lspci.
Don't use this unless the driver complains that the
base address is not set.
Example: 'modprobe i2c-sis5595 force_addr=0x290'
Description
-----------
i2c-sis5595 is a true SMBus host driver for motherboards with the
SiS5595 southbridges.
WARNING: If you are trying to access the integrated sensors on the
SiS5595 chip, you want the sis5595.o driver for those, not this driver.
This driver is a BUS driver, not a CHIP driver.
A BUS driver is used by other CHIP drivers to access chips on the bus.
To install this driver, simply do
# modprobe i2c-sis5595
doc/busses/i2c-sis630
-63
View File
@@ -1,63 +0,0 @@
Kernel driver `i2c-sis630.o'
Status: beta
Supported adapters:
* Silicon Integrated Systems Corp (SiS)
630 chipset (Datasheet: available at http://amalysh.bei.t-online.de/docs/SIS/)
730 chipset
* Possible other SiS chipsets ?
Author: Alexander Malysh <amalysh@web.de>
License: GPL
Module Parameters
-----------------
force = [1|0] Forcibly enable the SIS630. DANGEROUS!
This can be interesting for chipsets not named
above to check if it works for you chipset, but DANGEROUS!
high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,what your BIOS use).
DANGEROUS! This should be a bit faster, but freeze some systems (i.e.
my Laptop).
Description
-----------
This SMBus only driver is known to work on motherboards with the above named
chipsets.
If you see something like this:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 31)
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
or like this:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
in your 'lspci' output , then this driver is for your chipset.
Note: kernel versions later than 2.4.18 not tested.
If anyone owns a board with those chips AND is willing to risk crashing &
burning an otherwise well-behaved kernel in the name of progress... please
contact me at <amalysh@web.de> or via the project's mailing list: see
http://www.lm-sensors.org/wiki/AuthorsAndContributors. Please send bug reports
and/or success stories as well.
Thank Yous
-----------
Philip Edelbrock <phil@netroedge.com>
- testing SiS730 support
Mark M. Hoffman <mhoffman@lightlink.com>
- bug fixes
To anyone else which I forgot here ;), thanks!
doc/busses/i2c-sis645
-85
View File
@@ -1,85 +0,0 @@
Kernel driver `i2c-sis645.o'
Status: Beta
Supported adapters:
* Silicon Integrated Systems Corp (SiS)
Any combination of these host bridges:
645, 645DX (aka 646), 648, 650, 651, 655, 735, 745, 746
and these south bridges:
961, 962, 963(L)
Author: Mark M. Hoffman <mhoffman@lightlink.com>
License: GPL
Module Parameters
-----------------
(none)
Description
-----------
This SMBus only driver is known to work on motherboards with the above named
chipset combinations. The driver was developed without benefit of a proper
datasheet from SiS. The SMBus registers are assumed compatible with those of
the SiS630, although they are located in a completely different place. Thanks
to Alexander Malysh <amalysh@web.de> for providing the SiS630 datasheet (and
driver).
The command "lspci" as root should produce something like these lines:
00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
or perhaps this...
00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645 (rev 02)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0961
00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
(kernel versions later than 2.4.18 may fill in the "Unknown"s)
If the SMBus line is missing, then the BIOS on the board has disabled the
device. This driver is capable of enabling it, as long as the kernel has
CONFIG_HOTPLUG enabled. In that case, the SMBus device will appear in "lspci"
after the driver is loaded. Note that you need to rebuild lm_sensors AFTER
running "make config" or equivalent on your kernel, otherwise the i2c-sis645
driver will not build in this support.
I suspect that this driver could be made to work for the following SiS chipsets
as well: 635, and 635T.
If anyone owns a board with those chips AND is willing to risk crashing &
burning an otherwise well-behaved kernel in the name of progress... please
contact me at <mhoffman@lightlink.com> or via the project's mailing list:
see http://www.lm-sensors.org/wiki/AuthorsAndContributors. Please send bug reports
and/or success stories as well.
TO DOs
-----------
* The driver does not support SMBus block reads/writes; I may add them if a
scenario is found where they're needed.
Thank Yous
-----------
Mark D. Studebaker <mdsxyz123@yahoo.com>
- design hints and bug fixes
Alexander Maylsh <amalysh@web.de>
- ditto, plus an important datasheet... almost the one I really wanted
Hans-Günter Lütke Uphues <hg_lu@t-online.de>
- patch for SiS735
Robert Zwerus <arzie@dds.nl>
- testing for SiS645DX
Kianusch Sayah Karadji <kianusch@sk-tech.net>
- patch for SiS645DX/962
Ken Healy
- patch for Sis655
To anyone else who has written w/ feedback, thanks!
doc/busses/i2c-tsunami
-46
View File
@@ -1,46 +0,0 @@
Kernel driver `i2c-tsunami.o'
Status: Stable
Supported adapters:
* DEC Tsunami 21272/Typhoon 21274 based boards
Author: Oleg I. Vdovikin <vdovikin@jscc.ru>
Main contact: Oleg I. Vdovikin <vdovikin@jscc.ru>
Module Parameters
-----------------
(none)
Description
-----------
The Tsunami/Typhoon chipsets' "Cchip" supports I2C busses via MPD registers
and appropriate open drain pins. This bus is usually used to read
SPD SDRAM DIMMs, however there may be other devices on
the bus also. These chips are used with wide range of 21264A boards.
This driver uses the i2c-algo-bit module which must be
modprobed and/or enabled in your kernel
(Character Devices -> I2C Support -> I2C Bit-Banging Interfaces).
Stability
---------
Apparently stable.
Supported Devices
-----------------
This driver was written and tested on the 'API UP2000(+)
boards'. As seems it should work with any Tsunami based system.
Features
--------
I2C busses use the i2c-algo-bit driver for 'bit banging' and support
for specific transactions is provided by i2c-algo-bit.
Issues
------
Not known.
doc/busses/i2c-via
-50
View File
@@ -1,50 +0,0 @@
Kernel driver `i2c-via.o'
Status: Complete and well-tested
Supported adapters:
* VIA Technologies, InC. VT82C586B
Datasheet: Publicly available at the VIA website
Author: Kyösti Mälkki <kmalkki@cc.hut.fi>
Module Parameters
-----------------
(none)
Description
-----------
i2c-via is an i2c bus driver for motherboards with VIA chipset.
The following VIA pci chipsets are supported:
- MVP3, VP3, VP2/97, VPX/97
- others with South bridge VT82C586B
Your /proc/pci or lspci listing must show this :
Bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10)
To install this driver, simply do
# modprobe i2c-via
This driver uses the i2c-algo-bit module which must be
modprobed and/or enabled in your kernel
(Character Devices -> I2C Support -> I2C Bit-Banging Interfaces).
Problems?
Q: You have VT82C586B on the motherboard, but not in the listing.
A: Go to your BIOS setup, section PCI devices or similar.
Turn USB support on, and try again.
Q: No error messages, but still i2c doesn't seem to work.
A: This can happen. This driver uses the pins VIA recommends in their
datasheets, but there are several ways the motherboard manufacturer
can actually wire the lines.
doc/busses/i2c-viapro
-65
View File
@@ -1,65 +0,0 @@
Kernel driver `i2c-viapro.o'
Status: Stable
Supported adapters:
* VIA Technologies, Inc. VT82C596A/B
Datasheet: Sometimes available at the VIA website
* VIA Technologies, Inc. VT82C686A/B
Datasheet: Sometimes available at the VIA website
* VIA Technologies, Inc. VT8231, VT8233, VT8233A, VT8235, VT8237R/A, VT8251
Datasheet: available on request and under NDA from VIA
* VIA Technologies, Inc. CX700
Datasheet: available on request and under NDA from VIA
* VIA Technologies, Inc. VX800/VX820
Datasheet: available on http://linux.via.com.tw
Authors:
Kyösti Mälkki <kmalkki@cc.hut.fi>
Mark D. Studebaker <mdsxyz123@yahoo.com>
Jean Delvare <khali@linux-fr.org>
Module Parameters
-----------------
* force: int
Forcibly enable the SMBus controller. DANGEROUS!
* force_addr: int
Forcibly enable the SMBus at the given address. EXTREMELY DANGEROUS!
Description
-----------
i2c-viapro is a true SMBus host driver for motherboards with one of the
supported VIA south bridges.
Your /proc/pci or lspci -n listing must show one of these :
device 1106:3050 (VT82C596A function 3)
device 1106:3051 (VT82C596B function 3)
device 1106:3057 (VT82C686 function 4)
device 1106:3074 (VT8233)
device 1106:3147 (VT8233A)
device 1106:8235 (VT8231 function 4)
device 1106:3177 (VT8235)
device 1106:3227 (VT8237R)
device 1106:3337 (VT8237A)
device 1106:3287 (VT8251)
device 1106:8324 (CX700)
device 1106:8353 (VX800/VX820)
If none of these show up, you should look in the BIOS for settings like
enable ACPI / SMBus or even USB.
Except for the oldest chips (VT82C596A/B, VT82C686A and most probably
VT8231), this driver supports I2C block transactions. Such transactions
are mainly useful to read from and write to EEPROMs.
The CX700/VX800/VX820 additionally appears to support SMBus PEC, although
this driver doesn't implement it.
doc/busses/i2c-virtual
-102
View File
@@ -1,102 +0,0 @@
Virtual i2c bus
Brian Kuschak <bkuschak@xxxxxxxxx>
I2C devices must have a unique 7 bit address on the bus to which they
are attached. Many I2C chips have one or more input lines which can be
used to configure one or more of their address bits. This allows the
hardware designer to include multiple chips on a single bus by selecting
different addresses for each one. However, some chips have fixed addresses
which present a problem if more than one of them are required on a board.
Also, sometimes there are more devices than there are selectable addresses.
A common solution is to break the i2c bus into disjoint segments, by using
a multiplexor or i2c bus switch. This electrically isolates the individual
bus segments. Then the devices with duplicate addresses are placed on
separate bus segments, to prevent address conflicts.
This seems to be a very common approach in certain types of applications,
such as bladed chassis, where many identical 'blades' or cards are inserted
into a common backplane. The I2C bus on each blade is then located behind
a mux or i2c bus switch. This solution works great from the hardware
perspective, but presents some complexities for software.
The 'virtual i2c adapter' driver is an attempt to provide a flexible software
abstraction to simiplify these issues, while minimizing the impact on
existing code and fitting nicely into the i2c driver framework.
What is a 'virtual i2c adapter'
===============================
Think of this adapter as a layer above the existing algorithm and adapter
drivers. The virtual i2c adapter is the handle by which you access a
specific multiplexed bus segment. Each disjoint bus segment becomes a new
virtual bus. The virtual adapter is associated with a 'real' adapter and a
set of multiplexor control variables.
For example: you have an i2c-0 bus with one multiplexor or i2c bus switch,
and the mux has four outputs which can be electrically connected to the
i2c-0 bus. You would register four virtual i2c busses, one for each position
of the mux. As part of the registration, you provide callback functions to
select and deselect the mux as well as the selector values to be passed to
these functions.
--------- <--------> i2c-1 virtual
| i2c mux | <--------> i2c-2 virtual
i2c-0 <-------> | | <--------> i2c-3 virtual
ibm_ocp | 0x74 | <--------> i2c-4 virtual
---------
^
|
+--- (or externally controlled)
The mux may be i2c-controlled, in which case the mux_addr is set to the
slave address (0x74) and the mux_val would be the port number to select (0-3).
Alternatively, the mux could be controlled by some fixed memory-mapped register
in which case only the mux_val would be needed. The callback functions
are hardware specific and written by the user.
Once the virtual busses are registered, you may talk to any devices behind
the mux simply the using the i2c-1, i2c-2, i2c-3, etc. adapters instead of
the i2c-0 adapter. This makes the mux essentially transparent to the
i2c_client.
The great advantage of course is that all the existing sensor drivers and
other i2c client drivers automatically work, and the mux becomes transparent
to them.
Additional capabilities
=======================
This driver also supports multiple levels of muxing, by allowing the
user to register a virtual bus which has a different virtual bus as its
'real' adapter. In addition, each virtual bus may have different kinds of
multiplexors, with each bus having its own set of callback functions.
This allows you to easily support some very complex topologies.
In addition to multiplexing, some systems require that you obtain hardware
access to the bus behind the mux before talking on it. (Again, bladed chassis
typically 'fence' other blades off the bus to prevent a crashed blade from
bringing down the whole backplane.) Before talking on this bus, you have to
arbitrate with the other blades to acquire exclusive access to the bus. This
requirement is met by the addition of two new function pointers to the
algorithm drivers, acquire_exclusive() and release_exclusive(). Traditional
adapters will not use these and they can safely be left NULL. If they are
non-null, the virtual bus driver will call the acquire_exclusive() function
before attempting any operations on that virtual bus. This function may block,
and this is done before acquiring the lock on the underlying 'real' bus to
allow transactions on the real bus to continue unimpeded while waiting for
arbitrartion. In addition the ownership is only held for as long as it takes
to complete the transfer.
Files
=====
drivers/i2c/i2c-virtual.c: The 'algorithm' and 'adapter' driver
include/linux/i2c-virtual.h: Header file with the mux control structure
and callback prototypes.
doc/busses/i2c-voodoo3
-83
View File
@@ -1,83 +0,0 @@
Kernel driver `i2c-voodoo3.o'
Status: 'Beta' and still under development and testing
Supported adapters:
* 3dfx Voodoo3 based cards
* Voodoo Banshee based cards
Author: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock
<phil@netroedge.com>, Ralph Metzler <rjkm@thp.uni-koeln.de>,
and Mark D. Studebaker <mdsxyz123@yahoo.com>
Main contact: Philip Edelbrock <phil@netroedge.com>
The code is based upon Ralph's test code (he did the hard stuff ;')
Module Parameters
-----------------
(none)
Description
-----------
The 3dfx Voodoo3 chip contains two I2C interfaces (aka a I2C 'master'
or 'host').
The first interface is used for DDC (Data Display Channel)
which is a serial channel through the VGA monitor connector
to a DDC-compliant monitor. This interface is defined by the
Video Electronics Standards Association (VESA). The standards
are available for purchase at http://www.vesa.org .
The second interface is a general-purpose I2C bus.
The intent by 3dfx was to allow manufacturers to add extra
chips to the video card such as a TV-out chip such as the BT869 or possibly
even I2C based temperature sensors like the ADM1021 or LM75.
The 'feature' set of this driver is based on the i2c-piix4 (SMBus)
features. I.e., SMBus byte reads and writes, as well as detected faults in
transmission. Quick reads/writes, block transactions, word transactions,
are yet unwritten but are probably not too hard to add.
This driver uses the i2c-algo-bit module which must be
modprobed and/or enabled in your kernel
(Character Devices -> I2C Support -> I2C Bit-Banging Interfaces).
Stability
---------
Seems to be stable on the test machine, but needs more testing on other
machines.
Simultaneous accesses of the DDC and I2C busses may cause errors.
Supported Devices
-----------------
Specifically, this driver was written and tested on the '3dfx Voodoo3 AGP
3000' which has a tv-out feature (s-video or composite). According to the
docs and discussions, this code should work for any Voodoo3 based cards as
well as Voodoo Banshee based cards. The DDC interface has been tested
on a Voodoo Banshee card.
Features
--------
This driver controls the I2C controller of the Voodoo3 chip. 'byte read'
transactions and 'data_byte write' transactions are supported, but all else
is not (but is probably easy to add if the need arises).
Issues
------
Probably many, but it seems to work OK on my system. :')
External Device Connection
--------------------------
The digital video input jumpers give availability to the I2C bus.
Specifically, pins 13 and 25 (bottom row middle, and bottom right-end) are
the I2C clock and I2C data lines, respectively. +5V and GND are probably
also easily available making the addition of extra I2C/SMBus devices easy
to implement.
doc/chips/SUMMARY
+6 -54
View File
@@ -204,6 +204,9 @@ pc87360
pc87365 2 11 3 3 pwm no yes (LPC)
pc87366 3-4 11 3 3 pwm no yes (LPC)
pcf8591
pcf8591 - 2-4 - 1 dac yes no
sis5595
sis5595 0-1 4-5 2 - no yes
@@ -244,9 +247,6 @@ w83627hf
w83687thf 3 7 3 3 pw/da no yes (LPC)
w83697hf 2 8 2 2 pwm no yes (LPC)
w83627ehf
w83627ehf 3 10 3-5 4 pwm no yes (LPC)
w83781d
as99127f 3 7 3 - yes no
w83781d 3 7 3 - yes yes
@@ -265,51 +265,6 @@ xeontemp
xeontemp 1 - - - yes no
SUPPORTED NON-SENSOR CHIPS
--------------------------
Driver Chips
------ -----
bmcsensors
An interface to an IPMI BMC (Baseboard management controller)
bt869
bt869 video modulator chip
ddcmon
DDC-compliant monitor integrated eeproms - reads locations only
ds1307
real-time clock
eeprom
Memory SPD (serial presence detect) eeproms - reads locations only
Xeon scratch eeproms - reads locations only
ltc1710
ltc1710 two switches only
matorb
Matrix Orbital LCD displays
pca9540
2-channel I2C multiplexer
pcf8574 & pcf8574a
Simple eight-bit parallel I/O
pcf8591
Quad A/D + one D/A
saa1064
4-digit LED-driver
smbus-arp
An SMBus 2.0 ARP client
-----------------------------------------------------------------------------
COMPANY ID LIST
@@ -320,25 +275,22 @@ Many SMBus chips have a company ID at location 0x3E or 0xFE.
Here is a partial list.
This may help identify a chip after doing a 'i2cdump [bus] [address]'.
0x00 National (on LM84)
0x01 National
0x12C3 Asus (at 0x4F)
0x1934 Fintek (at 0x5D-0x5E)
0x23 Analog Devices
0x41 Analog Devices (also at 0x16)
0x23 Analog Devices (old products) or Fintek
0x41 Analog Devices (new products)
0x49 TI
0x4D Maxim
0x54 On Semi
0x54 Microchip (at 0x7)
0x5C SMSC
0x5D SMSC
0x55 SMSC
0x5CA3 Winbond (at 0x4F)
0x61 Andigilog
0x90 ITE (at 0x58)
0xA1 Philips (at 0x05 too)
0xA1 Philips
0xA3 Winbond (at 0x4F)
0xAC Myson (at 0x58)
0xC3 Asus (at 0x4F)
0xDA Dallas
doc/chips/adm1021
-415
View File
@@ -1,415 +0,0 @@
Kernel driver `adm1021.o'
=========================
Status: Complete; tested for most devices except Xeon.
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 -
see MODPARMS and xeontemp files for more information
Addresses scanned: none
Datasheet: Publicly available at Intel website
Status: Alpha, untested.
* 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
Author: Frodo Looijaard <frodol@dds.nl> and Philip Edelbrock
<phil@netroedge.com>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_adm1021: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `adm1021' chip
* force_adm1023: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `adm1023' chip
* force_max1617: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `max1617' chip
* force_max1617a: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `max1617a' chip
* force_thmc10: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `thmc10' chip
* force_lm84: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm84' chip
* force_gl523sm: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `gl523sm' chip
* force_mc1066: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `mc1066' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* 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.
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.
The ADM1021 reports a die code, which is a sort of revision code. This
can help us pinpoint problems; it is not very useful otherwise.
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
with in 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 two things:
1) modprobe adm1021 force_adm1021=BUS,ADDRESS
ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
See if you have one or two valid temperatures
2) modprobe xeontemp
See if you have one valid temperature.
If you have dual Xeons you may have appear to have two separate
adm1021-compatible chips, or two single-temperature sensors,
at distinct addresses.
Pick the best module for your processor based on the results.
See the xeontemp documentation for further information.
Chip Features
-------------
Chip 'adm1021'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp - - R- 0
temp_low temp temp RW 0
temp_over temp temp RW 0
remote_temp - - R- 0
remote_temp_low remote_temp remote_temp RW 0
remote_temp_over remote_temp remote_temp RW 0
alarms - - R- 0
die_code - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp SENSORS_ADM1021_TEMP temp1:3
temp_low SENSORS_ADM1021_TEMP_HYST temp1:2
temp_over SENSORS_ADM1021_TEMP_OVER temp1:1
remote_temp SENSORS_ADM1021_REMOTE_TEMP temp2:3
remote_temp_low SENSORS_ADM1021_REMOTE_TEMP_HYST temp2:2
remote_temp_over SENSORS_ADM1021_REMOTE_TEMP_OVER temp2:1
alarms SENSORS_ADM1021_ALARMS alarms:1
die_code SENSORS_ADM1021_DIE_CODE die_code:1
Chip 'adm1023'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp - - R- 0
temp_low temp temp RW 0
temp_over temp temp RW 0
remote_temp - - R- 3
remote_temp_low remote_temp remote_temp RW 3
remote_temp_over remote_temp remote_temp RW 3
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp SENSORS_ADM1021_TEMP temp1:3
temp_low SENSORS_ADM1021_TEMP_HYST temp1:2
temp_over SENSORS_ADM1021_TEMP_OVER temp1:1
remote_temp SENSORS_ADM1021_REMOTE_TEMP temp2:4
remote_temp_low SENSORS_ADM1021_REMOTE_TEMP_HYST temp2:2
remote_temp_over SENSORS_ADM1021_REMOTE_TEMP_OVER temp2:1
alarms SENSORS_ADM1021_ALARMS alarms:1
Chip 'max1617'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp - - R- 0
temp_low temp temp RW 0
temp_over temp temp RW 0
remote_temp - - R- 0
remote_temp_low remote_temp remote_temp RW 0
remote_temp_over remote_temp remote_temp RW 0
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp SENSORS_MAX1617_TEMP temp1:3
temp_low SENSORS_MAX1617_TEMP_HYST temp1:2
temp_over SENSORS_MAX1617_TEMP_OVER temp1:1
remote_temp SENSORS_MAX1617_REMOTE_TEMP temp2:3
remote_temp_low SENSORS_MAX1617_REMOTE_TEMP_HYST temp2:2
remote_temp_over SENSORS_MAX1617_REMOTE_TEMP_OVER temp2:1
alarms SENSORS_MAX1617_ALARMS alarms:1
Chip 'max1617a'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp - - R- 0
temp_low temp temp RW 0
temp_over temp temp RW 0
remote_temp - - R- 0
remote_temp_low remote_temp remote_temp RW 0
remote_temp_over remote_temp remote_temp RW 0
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp SENSORS_MAX1617A_TEMP temp1:3
temp_low SENSORS_MAX1617A_TEMP_HYST temp1:2
temp_over SENSORS_MAX1617A_TEMP_OVER temp1:1
remote_temp SENSORS_MAX1617A_REMOTE_TEMP temp2:3
remote_temp_low SENSORS_MAX1617A_REMOTE_TEMP_HYST temp2:2
remote_temp_over SENSORS_MAX1617A_REMOTE_TEMP_OVER temp2:1
alarms SENSORS_MAX1617A_ALARMS alarms:1
Chip 'thmc10'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp - - R- 0
temp_low temp temp RW 0
temp_over temp temp RW 0
remote_temp - - R- 0
remote_temp_low remote_temp remote_temp RW 0
remote_temp_over remote_temp remote_temp RW 0
alarms - - R- 0
die_code - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp SENSORS_ADM1021_TEMP temp1:3
temp_low SENSORS_ADM1021_TEMP_HYST temp1:2
temp_over SENSORS_ADM1021_TEMP_OVER temp1:1
remote_temp SENSORS_ADM1021_REMOTE_TEMP temp2:3
remote_temp_low SENSORS_ADM1021_REMOTE_TEMP_HYST temp2:2
remote_temp_over SENSORS_ADM1021_REMOTE_TEMP_OVER temp2:1
alarms SENSORS_ADM1021_ALARMS alarms:1
die_code SENSORS_ADM1021_DIE_CODE die_code:1
Chip 'lm84'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp - - R- 0
temp_low temp temp RW 0
temp_over temp temp RW 0
remote_temp - - R- 0
remote_temp_low remote_temp remote_temp RW 0
remote_temp_over remote_temp remote_temp RW 0
alarms - - R- 0
die_code - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp SENSORS_ADM1021_TEMP temp1:3
temp_low SENSORS_ADM1021_TEMP_HYST temp1:2
temp_over SENSORS_ADM1021_TEMP_OVER temp1:1
remote_temp SENSORS_ADM1021_REMOTE_TEMP temp2:3
remote_temp_low SENSORS_ADM1021_REMOTE_TEMP_HYST temp2:2
remote_temp_over SENSORS_ADM1021_REMOTE_TEMP_OVER temp2:1
alarms SENSORS_ADM1021_ALARMS alarms:1
die_code SENSORS_ADM1021_DIE_CODE die_code:1
Chip 'gl523'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp - - R- 0
temp_low temp temp RW 0
temp_over temp temp RW 0
remote_temp - - R- 0
remote_temp_low remote_temp remote_temp RW 0
remote_temp_over remote_temp remote_temp RW 0
alarms - - R- 0
die_code - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp SENSORS_ADM1021_TEMP temp1:3
temp_low SENSORS_ADM1021_TEMP_HYST temp1:2
temp_over SENSORS_ADM1021_TEMP_OVER temp1:1
remote_temp SENSORS_ADM1021_REMOTE_TEMP temp2:3
remote_temp_low SENSORS_ADM1021_REMOTE_TEMP_HYST temp2:2
remote_temp_over SENSORS_ADM1021_REMOTE_TEMP_OVER temp2:1
alarms SENSORS_ADM1021_ALARMS alarms:1
die_code SENSORS_ADM1021_DIE_CODE die_code:1
Chip 'mc1066'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp - - R- 0
temp_low temp temp RW 0
temp_over temp temp RW 0
remote_temp - - R- 0
remote_temp_low remote_temp remote_temp RW 0
remote_temp_over remote_temp remote_temp RW 0
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp SENSORS_MAX1617_TEMP temp1:3
temp_low SENSORS_MAX1617_TEMP_HYST temp1:2
temp_over SENSORS_MAX1617_TEMP_OVER temp1:1
remote_temp SENSORS_MAX1617_REMOTE_TEMP temp2:3
remote_temp_low SENSORS_MAX1617_REMOTE_TEMP_HYST temp2:2
remote_temp_over SENSORS_MAX1617_REMOTE_TEMP_OVER temp2:1
alarms SENSORS_MAX1617_ALARMS alarms:1
Old Documentation (may be outdated)
-----------------------------------
This file documents the adm1021 directories for the Analog Devices ADM1021
and MAX1617 temperature sensor chip. Note that this last chip should be
fully compatible; it is not yet well-tested, though.
There will be one directory created for each detected ADM1021 chip. As
ADM1021 chips can only be on a SMBus, they will be called adm1021-i2c-?-??, with
the first question mark being the number of the i2c bus (see /proc/bus/i2c
for a list of them, if i2c-proc is loaded), and the SMBus (I2C) address
of the chip at the end. An ADM1021 is uniquely characterised with these
two numbers. Likewise, for each MAX1617 chip, a directory max1617-i2c-?-??
will be created. /proc/sys/dev/sensors/chips contains the SYSCTL values for
all chip directories.
Within each ADM1021 or MAX1617 directory, you can find the following files:
* die_code (ADM1021_SYSCTL_DIE_CODE)
Silicon die (mask) revision code. This driver was written using a sample
device of die code 3. Normally this kind of information isn't reported
in its own proc file, but for a device this simple I didn't think it
would hurt.
* status (ADM1021_SYSCTL_STATUS)
This is an intergral number composed of 8-bits, which indicate the
different alarms and conversion status's of the chip. Here is what
each bit indicates:
7 BUSY 1 When ADC Converting.
6 LHIGH# 1 When Local High Temp Limit Tripped.
5 LLOW# 1 When Local Low Temp Limit Tripped.
4 RHIGH# 1 When Remote High Temp Limit Tripped.
3 RLOW# 1 When Remote Low Temp Limit Tripped.
2 OPEN# 1 When Remote Sensor Open-Circuit. (i.e., no connected remote
sensor)
1-0 Reserved.
Note: # - These flags stay high until the status register is read or they
are reset by POR.
* temp1 (ADM1021_SYSCTL_TEMP)
A list of three numbers. The first number is the Overtemperature Shutdown
value, the second number is Low limit value, and the third number is the
current temperature. The first two values can be modified. Each value can
be set and read to full-degree accuracy. All values are in degrees Celsius.
An alarm is issued (usually to a connected ADM9240) when the temperature
gets higher then the Overtemperature Shutdown value; it stays on until
the temperature falls back below the Overtemperature Shutdown value.
NOTE: This is different than the way most remote temperature sensors work
(e.g. the LM75), they usually use the lower limit to clear the alarm set
from initially going above the Overtemperature limit. Instead, the
ADM1021 acts much the way that voltage limits work on, say, the LM78 or
ADM9240. A disadvantage to this is that the alarm doesn't have a
hysteresis (like a shmidt-trigger or thermostat) type of function for
doing things like controlling over-heat fans and such. Instead, the
lower limit can be used to signal an alarm if (goodness forbid!) the
computer gets too cold.
If accessed through sysctl, this is a list of longs, each being the
temperature times 10.
* temp2 (ADM1021_SYSCTL_REMOTE_TEMP)
Works exactly the same way as 'temp1', but uses an external temperature
probe for the sensing. The temperature probe is of a silicon diode type
and not of a thermal-resistive type. A probe can easily be made from a
common transister (see the ADM1021 for qualification specs) by shorting
the base to the collector. From the docs: "Transistors such as 2N3904,
2N3906 or equivalents in SOT-23 package are suitable to use."
The data for each chip is updated each 1.5 seconds, but only if it is
actually read. And, any alarms triggered between reads which always be
present in the next read just after the alarm was triggered (regardless if
the alarm situation has been resolved or not).
This driver was written and is maintained by Philip Edelbrock
<phil@netroedge.com>. Please send corrections/comments to him. For
further technical information on this chip, please get the Acrobat PDF
documentation available from www.analog.com. We'd also like to thank
Analog Devices for helping us with correspondance and free samples to make
this driver (and other Analog Devices drivers) possible.
doc/chips/adm1024
-12
View File
@@ -1,12 +0,0 @@
Kernel driver `adm1024.o'
=========================
Status: Complete; Alpha.
Supported chips:
* Analog Devices ADM1024
Prefix: 'adm1024'
Addresses scanned: I2C 0x2c - 0x2e
Datasheet: Publicly available at the Analog Devices website
Author: Ken Bowley <ken@opnix.com>
doc/chips/adm1025
-135
View File
@@ -1,135 +0,0 @@
Kernel driver `adm1025.o'
=========================
Status: Complete, known to work but not heavily tested
Supported chips:
* Analog Devices ADM1025
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.
Author: Chen-Yuan Wu <gwu@esoft.com> and Jean Delvare <khali@linux-fr.org>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_adm1025: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `adm1025' chip
* force_ne1619: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `ne1619' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
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.
Chip Features
-------------
Chips 'adm1025' and 'ne1619'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
in0 - - R- 2
in1 - - R- 2
in2 - - R- 2
in3 - - R- 2
in4 - - R- 2
in5 - - R- 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in5_min in5 in5 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
in5_max in5 in5 RW 2
temp1 - - R- 1
temp1_low temp1 temp1 RW 1
temp1_high temp1 temp1 RW 1
temp2 - - R- 1
temp2_low temp2 temp2 RW 1
temp2_high temp2 temp2 RW 1
vid - - R- 3
vrm - - RW 1
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
in0 SENSORS_ADM1025_IN0 in0:3
in1 SENSORS_ADM1025_IN1 in1:3
in2 SENSORS_ADM1025_IN2 in2:3
in3 SENSORS_ADM1025_IN3 in3:3
in4 SENSORS_ADM1025_IN4 in4:3
in5 SENSORS_ADM1025_IN5 in5:3
in0_min SENSORS_ADM1025_IN0_MIN in0:1
in1_min SENSORS_ADM1025_IN1_MIN in1:1
in2_min SENSORS_ADM1025_IN2_MIN in2:1
in3_min SENSORS_ADM1025_IN3_MIN in3:1
in4_min SENSORS_ADM1025_IN4_MIN in4:1
in5_min SENSORS_ADM1025_IN5_MIN in5:1
in0_max SENSORS_ADM1025_IN0_MAX in0:2
in1_max SENSORS_ADM1025_IN1_MAX in1:2
in2_max SENSORS_ADM1025_IN2_MAX in2:2
in3_max SENSORS_ADM1025_IN3_MAX in3:2
in4_max SENSORS_ADM1025_IN4_MAX in4:2
in5_max SENSORS_ADM1025_IN5_MAX in5:2
temp1 SENSORS_ADM1025_TEMP1 temp1:3
temp1_low SENSORS_ADM1025_TEMP1_LOW temp1:2
temp1_high SENSORS_ADM1025_TEMP1_HIGH temp1:1
temp2 SENSORS_ADM1025_TEMP2 temp2:3
temp2_low SENSORS_ADM1025_TEMP2_LOW temp2:2
temp2_high SENSORS_ADM1025_TEMP2_HIGH temp2:1
vid SENSORS_ADM1025_VID vid:1
vrm SENSORS_ADM1025_VRM vrm:1
alarms SENSORS_ADM1025_ALARMS alarms:1
doc/chips/adm1026
-217
View File
@@ -1,217 +0,0 @@
Kernel driver `adm1026.o'
======================
Status: In development
Supported chips:
* Analog Devices ADM1026
Prefix: 'adm1026'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Author: Philip Pokorny <ppokorny@penguincomputing.com>
for Penguin Computing
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_adm1026: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
an `adm1026' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
The following only apply to the first ADM1026 detected. These are a
workaround for if your BIOS hasn't setup your chip.
* 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 measureable speed of a one pulse per rev fan is 1323
RPM. Two pulse per rev fans can be measured as slow as 661 RPM.
Voltage sensors (in0 to in16) report their values in volts. 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 automaticaly 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 degC, 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. If the VID value is wrong or
not wired as shown in the example, then you will need to write the
correct VID value to the driver either based on the GPIO values or
setting it directly. The value written to VID should be the *raw* VID
value (0 to 0x3f) or -1 (to restore the default value). When read,
the vid interface returns the scaled voltage according to the VRM spec
selected.
Example sensors.conf
--------------------
Here is an example sensors.conf configuration section for the ADM1026.
--------- cut here ---------
chip "adm1026-*"
# Voltage inputs
label in0 "V2.25_0" # Scaled for "SCSI terminator"?
label in1 "V2.25_1" # supply voltage?
label in2 "V2.25_2"
label in3 "V2.25_3"
label in4 "V2.25_4"
label in5 "V2.25_5"
label in6 "V1.875_0" # Unscaled inputs
label in7 "V1.875_1"
# If temp3 is enabled, in8 and in9 are disabled.
# label in8 "V1.875_2"
# label in9 "V1.875_3"
ignore in8
ignore in9
# Dedicated voltage inputs
label in10 "Vbat"
label in11 "V3.3STBY"
label in12 "V3.3MAIN"
label in13 "V5"
label in14 "Vccp"
label in15 "V12"
label in16 "V-12"
# Temperature inputs
label temp1 "Board"
label temp2 "CPU0"
label temp3 "CPU1"
# Fan inputs
label fan0 "CPU_Fan"
label fan1 "Fan1"
label fan2 "Fan2"
label fan3 "Fan3"
label fan4 "Fan4"
label fan5 "Fan5"
label fan6 "Fan6"
label fan7 "Fan7"
# PWM Outputs
label pwm "PWM"
# Voltage scaling is done on-chip. No 'compute' directive
# should be necessary. If in0-in9 have external scaling,
# set it here.
# compute in0 @ * 2.5, @ / 2.5
# Adjust fans speeds for actual pulses per rev
# compute fan0 @ / 2, @ * 2 # 2 pulse per rev
# compute fan1 @ / 3, @ * 3 # 3 pulse per rev
# compute fan2 @ / 4, @ * 4 # 4 pulse per rev
# compute fan3 @ / 8, @ * 8 # 8 pulse per rev
# Set VRM version
set vrm 9.1
# set vid 1.580
# Set voltage limits
set in10_min 3.0 * 0.95
set in10_max 3.0 * 1.05
set in11_min 3.3 * 0.95
set in11_max 3.3 * 1.05
set in12_min 3.3 * 0.95
set in12_max 3.3 * 1.05
set in13_min 5.0 * 0.95
set in13_max 5.0 * 1.05
# Uncomment if VID is wired or set above
# set in14_min vid * 0.95
# set in14_max vid * 1.05
set in15_min 12 * 0.95
set in15_max 12 * 1.05
set in16_min -12 * 0.95
set in16_max -12 * 1.05
# Set Fan limits
set fan0_min 7000
set fan1_min 7000
set fan2_min 7000
set fan3_min 7000
set fan4_min 3000
set fan5_min 3000
set fan6_min 3000
set fan7_min 3000
doc/chips/adm1031
-109
View File
@@ -1,109 +0,0 @@
Kernel driver `adm1031.o'
=========================
Status: Driver supports basic temp and fan readings, min/max/crit settings
alarms. This driver does not support auto fan control.
Supported chips:
* Analog Devices ADM1030
Prefix: 'adm1030'
Addresses scanned: I2C 0x2c to 0x2e
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/en/prod/0,2877,ADM1030,00.html
* Analog Devices ADM1031
Prefix: 'adm1031'
Addresses scanned: I2C 0x2c to 0x2e
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/en/prod/0,2877,ADM1031,00.html
Author: Alexandre d'Alton <alex@alexdalton.org>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_adm1030: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `adm1030' chip
* force_adm1031: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `adm1031' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
Description
-----------
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.
Chip Features
-------------
Chip 'adm1030'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp1 - - R- 3
temp1_high temp1 temp1 RW 3
temp1_low temp1 temp1 RW 3
temp1_crit temp1 temp1 RW 3
temp2 - - R- 3
temp2_high temp2 temp2 RW 3
temp2_low temp2 temp2 RW 3
temp2_crit temp2 temp2 RW 3
fan1_input - - R- 0
fan1_min fan1 fan1 RW 0
fan1_div fan1 - RW 0
alarms - - R- 0
Chip 'adm1031'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp1 - - R- 3
temp1_high temp1 temp1 RW 3
temp1_low temp1 temp1 RW 3
temp1_crit temp1 temp1 RW 3
temp2 - - R- 3
temp2_high temp2 temp2 RW 3
temp2_low temp2 temp2 RW 3
temp2_crit temp2 temp2 RW 3
temp3 - - R- 3
temp3_high temp3 temp3 RW 3
temp3_low temp3 temp3 RW 3
temp3_crit temp3 temp3 RW 3
fan1_input - - R- 0
fan1_min fan1 fan1 RW 0
fan1_div fan1 - RW 0
fan2_input - - R- 0
fan2_min fan2 fan2 RW 0
fan2_div fan2 - RW 0
alarms - - R- 0
doc/chips/adm9240
-424
View File
@@ -1,424 +0,0 @@
Kernel driver `adm9240.o'
=========================
Status: Complete and tested
Supported chips:
* Analog Devices ADM9240
Prefix: 'adm9240'
Addresses scanned: I2C 0x2c - 0x2f
Datasheet: Publicly available at the Analog Devices website
* Dallas Semiconductor DS1780
Prefix: 'ds1780'
Addresses scanned: I2C 0x2c - 0x2f
Datasheet: Publicly available at the Dallas Semiconductor website
* National Semiconductor LM81
Prefix: 'lm81'
Addresses scanned: I2C 0x2c - 0x2f
Datasheet: Publicly available at the National Semiconductor website
Author: Frodo Looijaard <frodol@dds.nl> and Philip Edelbrock
<phil@netroedge.com>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_adm9240: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `adm9240' chip
* force_ds1780: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `ds1780' chip
* force_lm81: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm81' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This driver implements support for the Analog Devices ADM9240,
Dallas Semiconductor DS1780, and National Semiconductor LM81 chips.
These chips appear to be completely
identical, except for the manufacturer IDs encoded in two registers, and
the speed with which they update their sensor readings.
The chips implement six voltage sensors, a temperature sensor,
two fan rotation speed sensors, VID lines and some miscellaneous stuff.
Temperatures are measured in degrees Celsius. An alarm is triggered whenever
the temperature is above the hot limit, and will continue to be generated
until the temperature has dropped beneath the hysteresis limit. Measurements
are guaranteed between -40 and +125 degrees. The current temperature
has a resolution of 0.5 degrees, the limits of 1 degree.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts.
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.
IMPORTANT: The current voltage measurement system is very probably broken.
Please report back to us if you have a ADM9240 or DS1780!
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. When it is unconnected, you will often find the
value 3.50 V here.
The analog output can be programmed separatedly. It can take values
between 0 and 255. What it actually does is mainboard-dependent; it
might influence the fan speed. Please report to us whether this is
the case with your ADM9240.
In addition to the alarms described above, the CHAS alarm triggers
if your computer case is open.
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 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
Thes ADM9240 only updates its values every 0.5 seconds; the DS1780 one
every 2 seconds; and the LM81 every 0.4 seconds.
Reading them more often will do no harm, but will return
'old' values. (NB: theoretically, this could be done much faster for the
ADM9240, but there is no real reason to do so, and this way the SMBus use
is kept within reasonable limits)
Chip Features
-------------
Chip `adm9240'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
2.5V NONE NONE R 2
Vccp1 NONE NONE R 2
3.3V NONE NONE R 2
5V NONE NONE R 2
12V NONE NONE R 2
Vccp2 NONE NONE R 2
2.5V_min 2.5V 2.5V RW 2
Vccp1_min Vccp1 Vccp1 RW 2
3.3V_min 3.3V 3.3V RW 2
5V_min 5V 5V RW 2
12V_min 12V 12V RW 2
Vccp2_min Vccp2 Vccp2 RW 2
2.5V_max 2.5V 2.5V RW 2
Vccp1_max Vccp1 Vccp1 RW 2
3.3V_max 3.3V 3.3V RW 2
5V_max 5V 5V RW 2
12V_max 12V 12V RW 2
Vccp2_max Vccp2 Vccp2 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
vid NONE NONE R 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
alarms NONE NONE R 0
analog_out NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
2.5V SENSORS_ADM9240_IN0 2.5V:3
Vccp1 SENSORS_ADM9240_IN1 Vccp1:3
3.3V SENSORS_ADM9240_IN2 3.3V:3
5V SENSORS_ADM9240_IN3 5V:3
12V SENSORS_ADM9240_IN4 12V:3
Vccp2 SENSORS_ADM9240_IN5 Vccp2:3
2.5V_min SENSORS_ADM9240_IN0_MIN 2.5V:1
Vccp1_min SENSORS_ADM9240_IN1_MIN Vccp1:1
3.3V_min SENSORS_ADM9240_IN2_MIN 3.3V:1
5V_min SENSORS_ADM9240_IN3_MIN 5V:1
12V_min SENSORS_ADM9240_IN4_MIN 12V:1
Vccp2_min SENSORS_ADM9240_IN5_MIN Vccp2:1
2.5V_max SENSORS_ADM9240_IN0_MAX 2.5V:2
Vccp1_max SENSORS_ADM9240_IN1_MAX Vccp1:2
3.3V_max SENSORS_ADM9240_IN2_MAX 3.3V:2
5V_max SENSORS_ADM9240_IN3_MAX 5V:2
12V_max SENSORS_ADM9240_IN4_MAX 12V:2
Vccp2_max SENSORS_ADM9240_IN5_MAX Vccp2:2
fan1 SENSORS_ADM9240_FAN1 fan1:2
fan2 SENSORS_ADM9240_FAN2 fan2:2
fan1_min SENSORS_ADM9240_FAN1_MIN fan1:1
fan2_min SENSORS_ADM9240_FAN2_MIN fan2:1
temp SENSORS_ADM9240_TEMP temp:3
temp_hyst SENSORS_ADM9240_TEMP_HYST temp:2
temp_over SENSORS_ADM9240_TEMP_OVER temp:1
vid SENSORS_ADM9240_VID vid:1
fan1_div SENSORS_ADM9240_FAN1_DIV fan_div:1
fan2_div SENSORS_ADM9240_FAN2_DIV fan_div:2
alarms SENSORS_ADM9240_ALARMS alarms:1
analog_out SENSORS_ADM9240_ANALOG_OUT analog_out:1
Chip `ds1780'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
2.5V NONE NONE R 2
Vccp1 NONE NONE R 2
3.3V NONE NONE R 2
5V NONE NONE R 2
12V NONE NONE R 2
Vccp2 NONE NONE R 2
2.5V_min 2.5V 2.5V RW 2
Vccp1_min Vccp1 Vccp1 RW 2
3.3V_min 3.3V 3.3V RW 2
5V_min 5V 5V RW 2
12V_min 12V 12V RW 2
Vccp2_min Vccp2 Vccp2 RW 2
2.5V_max 2.5V 2.5V RW 2
Vccp1_max Vccp1 Vccp1 RW 2
3.3V_max 3.3V 3.3V RW 2
5V_max 5V 5V RW 2
12V_max 12V 12V RW 2
Vccp2_max Vccp2 Vccp2 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
vid NONE NONE R 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
alarms NONE NONE R 0
analog_out NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
2.5V SENSORS_DS1780_IN0 2.5V:3
Vccp1 SENSORS_DS1780_IN1 Vccp1:3
3.3V SENSORS_DS1780_IN2 3.3V:3
5V SENSORS_DS1780_IN3 5V:3
12V SENSORS_DS1780_IN4 12V:3
Vccp2 SENSORS_DS1780_IN5 Vccp2:3
2.5V_min SENSORS_DS1780_IN0_MIN 2.5V:1
Vccp1_min SENSORS_DS1780_IN1_MIN Vccp1:1
3.3V_min SENSORS_DS1780_IN2_MIN 3.3V:1
5V_min SENSORS_DS1780_IN3_MIN 5V:1
12V_min SENSORS_DS1780_IN4_MIN 12V:1
Vccp2_min SENSORS_DS1780_IN5_MIN Vccp2:1
2.5V_max SENSORS_DS1780_IN0_MAX 2.5V:2
Vccp1_max SENSORS_DS1780_IN1_MAX Vccp1:2
3.3V_max SENSORS_DS1780_IN2_MAX 3.3V:2
5V_max SENSORS_DS1780_IN3_MAX 5V:2
12V_max SENSORS_DS1780_IN4_MAX 12V:2
Vccp2_max SENSORS_DS1780_IN5_MAX Vccp2:2
fan1 SENSORS_DS1780_FAN1 fan1:2
fan2 SENSORS_DS1780_FAN2 fan2:2
fan1_min SENSORS_DS1780_FAN1_MIN fan1:1
fan2_min SENSORS_DS1780_FAN2_MIN fan2:1
temp SENSORS_DS1780_TEMP temp:3
temp_hyst SENSORS_DS1780_TEMP_HYST temp:2
temp_over SENSORS_DS1780_TEMP_OVER temp:1
vid SENSORS_DS1780_VID vid:1
fan1_div SENSORS_DS1780_FAN1_DIV fan_div:1
fan2_div SENSORS_DS1780_FAN2_DIV fan_div:2
alarms SENSORS_DS1780_ALARMS alarms:1
analog_out SENSORS_DS1780_ANALOG_OUT analog_out:1
Chip `lm81'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
2.5V NONE NONE R 2
Vccp1 NONE NONE R 2
3.3V NONE NONE R 2
5V NONE NONE R 2
12V NONE NONE R 2
Vccp2 NONE NONE R 2
2.5V_min 2.5V 2.5V RW 2
Vccp1_min Vccp1 Vccp1 RW 2
3.3V_min 3.3V 3.3V RW 2
5V_min 5V 5V RW 2
12V_min 12V 12V RW 2
Vccp2_min Vccp2 Vccp2 RW 2
2.5V_max 2.5V 2.5V RW 2
Vccp1_max Vccp1 Vccp1 RW 2
3.3V_max 3.3V 3.3V RW 2
5V_max 5V 5V RW 2
12V_max 12V 12V RW 2
Vccp2_max Vccp2 Vccp2 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
vid NONE NONE R 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
alarms NONE NONE R 0
analog_out NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
2.5V SENSORS_ADM9240_IN0 2.5V:3
Vccp1 SENSORS_ADM9240_IN1 Vccp1:3
3.3V SENSORS_ADM9240_IN2 3.3V:3
5V SENSORS_ADM9240_IN3 5V:3
12V SENSORS_ADM9240_IN4 12V:3
Vccp2 SENSORS_ADM9240_IN5 Vccp2:3
2.5V_min SENSORS_ADM9240_IN0_MIN 2.5V:1
Vccp1_min SENSORS_ADM9240_IN1_MIN Vccp1:1
3.3V_min SENSORS_ADM9240_IN2_MIN 3.3V:1
5V_min SENSORS_ADM9240_IN3_MIN 5V:1
12V_min SENSORS_ADM9240_IN4_MIN 12V:1
Vccp2_min SENSORS_ADM9240_IN5_MIN Vccp2:1
2.5V_max SENSORS_ADM9240_IN0_MAX 2.5V:2
Vccp1_max SENSORS_ADM9240_IN1_MAX Vccp1:2
3.3V_max SENSORS_ADM9240_IN2_MAX 3.3V:2
5V_max SENSORS_ADM9240_IN3_MAX 5V:2
12V_max SENSORS_ADM9240_IN4_MAX 12V:2
Vccp2_max SENSORS_ADM9240_IN5_MAX Vccp2:2
fan1 SENSORS_ADM9240_FAN1 fan1:2
fan2 SENSORS_ADM9240_FAN2 fan2:2
fan1_min SENSORS_ADM9240_FAN1_MIN fan1:1
fan2_min SENSORS_ADM9240_FAN2_MIN fan2:1
temp SENSORS_ADM9240_TEMP temp:3
temp_hyst SENSORS_ADM9240_TEMP_HYST temp:2
temp_over SENSORS_ADM9240_TEMP_OVER temp:1
vid SENSORS_ADM9240_VID vid:1
fan1_div SENSORS_ADM9240_FAN1_DIV fan_div:1
fan2_div SENSORS_ADM9240_FAN2_DIV fan_div:2
alarms SENSORS_ADM9240_ALARMS alarms:1
analog_out SENSORS_ADM9240_ANALOG_OUT analog_out:1
Old Documentation
-----------------
Supports the Analog Devices ADM9240 and the Dallas Semiconductor DS1780.
These chips are apparently identical except for the manufacturer ID
register.
The proc directory will be adm9240-i2c-x-xx for the adm9240 and
ds1780-i2c-x-xx for the ds1780.
-----------------------------------------------------------------------
This file documents the adm9240 directories for the Analog Devices
ADM9240 hardware health monitoring chip found on some Intel mainboards
(and others?).
There will be one directory created for each detected ADM9240 chip.
Each chip must be on the SMBus. Directories are called things
like adm9240-i2c-1-2c. /proc/sys/dev/sensors/chips contains the SYSCTL
values for all chip directories.
Within each ADM9240 directory, you can find the following files:
* alarms (ADM9240_SYSCTL_ALARMS)
A number which indicates which alarms are on. An alarm gets triggered when
some limit has been crossed. This number is composed from a 16 bit
value which is the combination of the Interrupt Status Register 1
(low byte) and 2 (high byte).
This file can not be written to.
The number is the logical OR of the following components (bit #
followed by a description):
0 +2.5 V_Error Read Only A "1" indicates a high or low limit has been exceeded.
1 VCCP_Error Read Only A "1" indicates a high or low limit has been exceeded.
2 +3.3 V_Error Read Only A "1" indicates a high or low limit has been exceeded.
3 +5 V_Error Read Only A "1" indicates a high or low limit has been exceeded.
4 Temp_Error Read Only A "1" indicates that a temperature interrupt has been set.
5 Reserved Read Only Undefined.
6 FAN1_Error Read Only A "1" indicates that a fan count limit has been exceeded.
7 FAN2_Error Read Only A "1" indicates that a fan count limit has been exceeded.
8 +12 V_Error Read Only A "1" indicates a high or low limit has been exceeded.
9 VCCP2_Error Read Only A "1" indicates a high or low limit has been exceeded.
10 Reserved Read Only Undefined.
11 Reserved Read Only Undefined.
12 Chassis_Error Read Only A "1" indicates chassis intrusion has gone high.
13 Reserved Read Only Undefined.
14 Reserved Read Only Undefined.
15 Reserved Read Only Undefined.
If accessed through sysctl, this value is a long.
* fan[1-3] (ADM9240_SYSCTL_FAN[1-2])
A list of two numbers. The first is the minimum fan rotation limit; the
second is the current fan rotation speed. Both are in RPM (rotations per
minute). An alarm is triggered if the rotation speed drops below the
limit. The first value can be changed. Not all RPM values can accurately
be represented, so some rounding is done.
If accessed through sysctl, this is a list of longs.
* fan_div (LM78_SYSCTL_FAN_DIV)
A list of two numbers, one for each fan. Each number can be either 1, 2,
4 or 8. It is the internal scaling factor used for the fan rotations. If
you change this number, the fan readings get more or less detailed, but
the range in which they can be read too. Higher numbers give better
resolution, but less range. The first two numbers can be changed, the
third not.
If accessed through sysctl, this is a list of longs.
* 2.5V, Vccp1, 3.3V, 5V, 12V, and Vccp2 (ADM9240_SYSCTL_IN[0-5] in the
order shown)
A list of three numbers. The first is the minimum limit, the second is the
maximum limit, and the third is the current value. Note that
minimum means 'closest to zero'; so if the normal value equals -10, a
minimum could equal -9, and a maximum -11. Vccp1 and Vccp2 reflect core
voltages; they are by default set from the vid values, or set to 2.80V
if the vid lines seem to be unconnected. Not all voltage values
can be accurately represented, so some rounding is done.
The first two numbers can be changed, the third not.
If accessed through sysctl, this is a list of longs, each being the voltage
times 100.
* temp
A list of three numbers. The first number is the Overtemperature Shutdown
value; the second is the Hysteresis value and the third number is the
current value. The first two values can be modified. All values are in
degrees Celsius. An alarm is issued when the temperature first gets above
the Overtemperature Shutdown value; no more alarms are issued until the
temperature gets below the Hysteresis value, at which moment another alarm
is issued, and the state is reset. A more useful behaviour can be found
by setting the Hysteresis value to +127 degrees Celsius; in this case,
alarms are issued during all the time when the actual temperature is
above the Overtemperature Shutdown value.
The first two numbers can be changed, the third not.
If accessed through sysctl, this is a list of longs, each being the
temperature in degrees Celsius times 10.
* vid
The core voltage value (the voltage level your processor should work with),
in volts. This is the value IN0 and IN1 are initialized to. If unconnected,
it usually reads 3.50V.
This number can not be changed.
If accessed through sysctl, this is a long, being the voltage times 100.
* analog_out
This is feature is specific to the ADM9240. It is a DAC voltage
control register for the Analog-Out pin. Valid values are from 255
to 0 (with 255 being the highest voltage, and 0 the lowest). From
the docs: "The ADM9240 has a single analog output from an unsigned
8-bit DAC which produces 0 V - 1.25 V."
The data for each ADM9240 is updated each 1.5 seconds,
but only if it is actually read.
Note: Much of this documentation is copied from the LM78 documenation
(the device from which most featuers of the ADM9240 is modelled from).
The maintainer of the ADM9240 is Philip Edelbrock
<phil@netroedge.com>; please forward corrections, suggestions, etc.
to him. For further technical information on this chip, I suggest
getting the Acrobat PDF documentation from www.analog.com.
Dallas documentation is at http://www.dalsemi.com.
doc/chips/asb100
-89
View File
@@ -1,89 +0,0 @@
Kernel driver `asb100.o'
========================
Status: Work in progress
Supported Chips:
* Asus ASB100 and ASB100-A "Bach"
Prefix: 'asb100'
Addresses scanned: I2C 0x2d
Datasheet: none released
Author: Mark M. Hoffman <mhoffman@lightlink.com>
Module Parameters
-----------------
<TODO: fill in here>
Asus' BIOS is often broken
--------------------------
If you have an Asus P4PE, you need to read prog/hotplug/README.p4b.
If you have any other (Asus) board for which sensors-detect finds neither
asb100 nor an I2C bus, please read prog/hotplug/README.p4b before sending
a bug report.
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...
* Fix bogus client deregistration (like w83781d in 2.6).
* Fix fan divisor / fan minimum interaction (like lm78).
* Cleanups, no doubt...
doc/chips/bmcsensors
-140
View File
@@ -1,140 +0,0 @@
Kernel driver `bmcsensors.o'
==========================
Status: Alpha
Supported chips:
* IPMI BMC
Prefix: 'bmc'
Requires dummy adapter i2c-ipmi;
Driver will be registered as bmc-ipmi-0000.
Author: M. Studebaker <mdsxyz123@yahoo.com>
License: GPL
Module Parameters
-----------------
None.
Detection
---------
Registers only with i2c-ipmi.
Description
-----------
Together with the i2c-ipmi module, this provides high-level
access to sensors known by the BMC. For low-level access to
IPMB (I2C/SMBus) busses behind the BMC, use the i2c-ipmb module
and individual chip drivers.
This module REQUIRES the IPMI kernel patch by Corey Minyard,
v13 or higher, available at http://openipmi.sourceforge.net .
Other IPMI drivers are not supported.
See http://www.intel.com/design/servers/ipmi/ for
IPMI standards information.
You must configure the following features in your kernel
(under Character Devices):
IPMI top-level message handler
IPMI KCS handler
The IPMI device interface and IPMI watchdog handler are not required.
You must modprobe i2c-ipmi separately, it will not
load automatically when you modprobe bmcsensors.
If the KCS handler (ipmi_kcs_drv) is configured as a module,
you must also modprobe it separately, it will not load automatically
when you modprobe i2c-ipmi or ipmi_msghandler (unless you set up
/etc/modules.conf to load ipmi_kcs_drv when ipmi_msghandler is loaded).
/proc entries
-------------
The BMC SDR's (Sensor Data Records) are scanned and
the /proc table is built dynamically. Sensor types and quantities
depend on what the BMC supports.
curr1-n Currents. Max, min, and reading in amps.
fan1-n Fan speeds. Min and reading in RPM.
in1-n Voltages. Max, min, and reading in volts.
temp1-n Temps. Max, hysteresis or min, and reading in degrees C.
Thresholds will appear as 0 if unsupported or unreadable, as indicated
in the SDR.
If the thresholds are not settable (as indicated in the SDR), the
/proc permissions for that sensor will be 444.
After the SDR's are scanned, the module will print
the sensor names and bindings to syslog/dmesg.
Cut these messages out and paste them to /etc/sensors.conf
so that 'sensors' has correct labeling.
Issues
------
The module will not register in /proc/sys/dev/sensors until
the SDR's are scanned. This may take several seconds.
The driver uses a very simple state machine. It only sends
one message at a time and then waits for a response.
This makes the driver relatively slow.
If a response is an error or does not arrive, the driver
will probably be stuck.
/proc access kicks off an update but returns the old data,
not the new; need to wait for update to finish and then return.
Probably there are some locking issues.
Every attempt is made to present the sensor data in /proc in a
manner consistent with lm_sensors /proc standards, as defined
in doc/developers/proc. Given the wide variation in possible SDR definitions,
this may not generate expected or useful data.
IPMI supports up to 4 max and 4 min thresholds (non-recoverable, critical,
non-critical, and hysteresis) for each sensor. This driver
tries to pick out the best one and exports it as the max and min
to /proc.
ins start at 1, other modules start at in0.
Alarms and thresholds are not yet supported.
Threshold-only sensors are not supported.
Threshold setting is not yet supported.
1's and 2's complement formats not yet supported.
Non-linear conversions not supported, except for 1/x.
Fan divs are not supported (or required) - should the driver
export a fan_div entry (1 1 1 ...) for compatibility?
Supports only sensor types 1-4 (temp, voltage, current, and fan).
Libsensors can't handle dynamic /proc entries so the table
in lib/chips.c must be static and contain the max number of
each sensor. Bmcsensors can register more of a sensor type
than libsensors supports in its static table.
Only one BMC is supported - shouldn't be a problem.
Alpha!
**********************
The lm_sensors project gratefully acknowledges the support of
Hewlett Packard (Ft. Collins) in the development of this driver.
doc/chips/bt869
-397
View File
@@ -1,397 +0,0 @@
Kernel driver `bt869.o'
======================
Status: 'Beta' and needs further development and testing
Supported chips:
* Brooktree BT869 Video Modulator chips
Prefix: 'bt869'
Addresses scanned: I2C 0x44 - 0x45
Datasheet: Publicly available at the brooktree web site
(www.brooktree.com)
Author: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock
<phil@netroedge.com>, Ralph Metzler <rjkm@thp.uni-koeln.de>
Steve Davies <steve@daviesfam.org> added the 720x576 and
720x480 support, and the svideo configuration.
Main Contact: Philip Edelbrock <phil@netroedge.com>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_bt869: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `bt869' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This driver provides some access to the Brooktree bt869 found on some
video cards (like the 'Voodoo3 3000'). Typically, the output can be
either an s-video connection or composite video. Resolutions
supported using the chip's built in configurations are 640x480 or
800x600. In addition, a 720x576 PAL mode and a 720x480 NTSC mode,
both without overscan compensation, are supported - a convenient
configuration for video playback.
Other possible implementations may allow for double resolutions with some
decimations (e.g., a monitor running at 1280x960 but the TV out getting every
other pixel for 640x480).
Driver Features
---------------
Standards: (US) NTSC or PAL
Resolutions: 640x480, 800x600, 720x576 (PAL only), 720x480 (NTSC only)
Depths: 16, 24 or 32 bits
Colorbars: Switch on the built-in color bar generator. (FYI- using a blue
filter, you should see only alternating bright stripes of equal brightness.
Adjust your TV's color and saturation if this isn't the case.)
SVideo: composite or s-video output. Also, theoretically, RGB output, though
this isn't tested and will require that your card presents all three DAC outputs
(the 3dfx Voodoo3 doesn't)
In your XF86Config file, you should have these entries for NTSC output:
ModeLine "640x480NTSC" 28.195793 640 656 658 784 480 520 525 600
ModeLine "720x480NTSC" 27.5 720 744 800 872 480 483 485 525
ModeLine "800x600NTSC" 38.769241 800 812 814 880 600 646 649 735
or for PAL
ModeLine "640x480PAL" 29.50 640 675 678 944 480 530 535 625
ModeLine "720x576PAL" 27.50 720 744 800 880 576 581 583 625
ModeLine "800x600PAL" 36.00 800 818 820 960 600 653 655 750
Also, don't forget to add these modes to the resolutions list in the
'screen' sections of XF86Config. You can change modes on the fly in X by
pressing (usually) ctrl-alt-+ or ctrl-alt-(minus) with + and - being the
keys on your numeric 10-key pad.
BTW- My monitor doesn't like these entries very much, and as I've read:
don't run your monitor out of spec or else it will burst into fire. So,
having the monitor turned on while in any of these modes is at your own
risk. (I've never heard of a monitor breaking from this, but it seems to
be fashionable to warn about it.)
Chip Features
-------------
The chip is very flexible and customizable for many standards. Right
now the driver sticks with the chip's built in NTSC and PAL standards,
with the addition of the 720x576PAL and 720x480NTSC modes. It also
does some other wacky stuff like closed-captioning, Macro-vision
copy-protection, and other things. Check out the datasheet for more
info.
Issues
------
The depth register doesn't seem to do much? If you have troubles or
aren't sure the output is working, turn the color-bars on. If they display
OK, then the chip is syncing correctly. The next thing to try is the depth
setting. Lastly, turning off your computer and back on with your TV
connected but you monitor not, may force the video card to configure and
use the BT869 as your primary output device (all bets are off once X is
started). Let me know if you have problems which you can't figure out
(phil@netroedge.com).
--------------------------------
On May 3rd, 2001 (My birthday, as it happens to be :') Tomi Ollila sent me
a how-to from a user's perspective on using the BT869 with a 3Dfx card.
It should also provide insight for other video card users who have a
BT869 on board. Here is his document:
How-To
------
This text describes my successful attempt to eventually get the TV-Out
feature of 3DFX Voodoo 3 3000 (PAL) working in a Linux environment.
I've successfully configured the 800x600 mode -- And currently I am
not interested in 640x480 -- hardware scaling rules in all cases
I need the tv-out. My monitor works much less worse w/ 800x600PAL...
All the information is based on my best knowledge but there might be
some mistakes. In any case, THE ENTIRE RISK OF USING THIS INFORMATION
IS WITH YOU, AND NO ONE ELSE IS LIABLE OF ANY PROBLEMS ENCOUNTERED.
Please fix any mistakes, inaccuracies, writing errors, etc. you
notice in this document.
I was about to write briefly, but sorry due to limited resources
I did not have time to write briefly (too much thinking ;).
Well, browse through the text and skip all irrelevant parts
to proceed...
Tomi Ollila <too@iki.fi>
The first time I got the the tv-out working I was working w/ Linux kernel
2.4.3. Now I am redoing the work w/ Linux 2.4.4 and recording the steps
in this document. Description of my system and software used is as follows:
RedHat 7.0 linux distribution (probably any distribution will do, since
all of the needed software is compiled from packages that are not RH-pagkaged)
(maybe if anything is important, are modutils-2.3.14-3 and kernel-headers-2.4.0-0.26)
XFree-4.0.3. I don't see any reason anyone uses any older. HW acceleration
of Voodoo3 3000 works out of the box with this. Also Windowed!!!
lm_sensors-2.5.5: Get this or newer. I have not used any older.
i2c-2.5.5: Probably 2.4.x -kernel distributions has recent enough version
of i2c. Since I also have IOmega BUZ and it's (working) versions require
i2c-old, I cannot use the one's kernel provided. Since I cannot say anything
about not using this i2c as separate package I suggest you do the same
and compile this also.
I have used kgcc that comes in RedHat 7.0 -distribution to compile all
stuff. Probably all other recent gcc -compilers will produce good results
also: kgcc -v outputs:
Reading specs from /usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
--
1) The work starts w/ kernel compilation (or skip to step 2, I quess it will
work w/ any recent 2.2 and 2.4 -kernels)
# run make config, make menuconfig or make xconfig (I suggest 'xconfig')
For sure you need kernel module support and /proc -filesystem support
(XXX add more absolute requirements)
Now I cannot say for sure, if following things needs to be compiled
at kernel compilation time or does i2c-2.5.5 bring all these:
character devices->i2c support->i2c support
character devices->i2c support->i2c bit-banging interfaces (*)
character devices->i2c support->i2c devices (**)
character devices->/dev/agpart support
character devices->Direct Rendering Manager (XFree86 DRI support) (+)
character devices->3dfx banshee/Voodoo3+
make above as modules.
(*) I already forgot why I wanted some special attention for this
(**) It seems I never need this
(+) Hmm, It seems I have compiled this as part of the kernel binary
There is of course lot of other options you need to choose but these
are probably the ones needed...
# run make dep
# run make bzImage
# run make modules
# run make modules_install (as root)
# copy arch/i386/boot/bzImage to /boot/vmlinuz-2.4.4 (as root)
# edit /etc/lilo.conf and run lilo (as root)
2) In order to (the most easiest way) compile separate i2c and lm_sensors
-package, symlink your linux source tree to /usr/src/linux (unless it is
there already) and do the following
# tar zxvf i2c-2.5.5.tar.gz
# cd i2c-2.5.5
# make
# make install (as root)
# cd ..
# tar zxvf lm_sensors-2.5.5.tar.gz
# cd lm_sensors-2.5.5
# make
# make install (as root)
# cd ..
Now you have all necessary modules installed on the system (and
/usr/local/bin/sensors and /usr/local/sbin/sensors-detect).
But there is some configuration missing in order to activate
the needed functionality of the modules...
3) Now, before going any further, let's take a look the modifications that
is required in XFree86 -configuration so that X is ready for the
tv-out functionality next time it is started.
XFree86-4.x uses the configuration file /etc/X11/XF86Config-4. Older
configuration files needed "ModeLine"s for all display resolutions
that are needed, but XFree86 version 4 can figure out those by itself.
But what it cannot figure out, are some special ModeLines that may
be reguired in various cases... and this is one of these.
For Voodoo 3 3000 TV out feature, special modelines are needed for
the supported resolutions, 640x480 and 800x600 (there might be others
but I don't know enough of the issue. In this document, I only
activate the 800x600 mode.
Make backup copy of your /etc/X11/XF86Config-4 in case you accidentally
screw something up so you can then reuse the old file if this happens.
Open /etc/X11/XF86Config-4 in your favourite editor and find line
that contains `Section "Monitor"'. At the end of that section,
just before line `EndSection', add the following lines:
ModeLine "640x480PAL" 29.50 640 675 678 944 480 530 535 625
ModeLine "800x600PAL" 36.00 800 818 820 960 600 653 655 750
Then, find lines that starts with something like:
Section "Screen"
Identifier "Screen0"
Device "3Dfx Interactive, Inc.|Voodoo 3"
Monitor "<Your monitor>"
DefaultDepth 16
...
Subsection "Display"
Depth 16
# Modes "1024x768" "640x480" "800x600" "800x600PAL" #"400x300"
Modes "1024x768" "800x600PAL"
EndSubSection
Make sure that `DefaultDepth' is set 16 (I don't know if any other works)
Then you notice there my resolutions as `Modes' -lines. I have outcommented
the first `Modes' -line so that testing is easier. You can do what
you widh here, just make sure to add that `"800x600PAL"' -line there.
Save the file and exit editor.
4) It's is time to reboot (with new kernel), that is the easiest way to
continue.
5) After rebooting, and X startup `lsmod' in my machine output following:
Module Size Used by
tdfx 54536 1
es1371 28500 0
ac97_codec 8808 0 [es1371]
tdfx -module was loaded by X, and sound module by some RH -startup script.
Now you could run /usr/local/sbin/sensors-detect. After that was run in
my PII class -machine it suggested I add the following:
to /etc/modules.conf
alias char-major-89 i2c-dev
to some startup script (i choose append to /etc/rc.local)
# I2C adapter drivers
/sbin/modprobe i2c-piix4
/sbin/modprobe i2c-voodoo3
# I2C chip drivers
/sbin/modprobe w83781d
/sbin/modprobe eeprom
(you run the prg and add the stuff it suggests)
Let's now /sbin/modprobe -v i2c-voodoo3. Now I have:
Module Size Used by
i2c-voodoo3 3012 0 (unused)
i2c-algo-bit 7796 2 [i2c-voodoo3]
i2c-core 12844 0 [i2c-algo-bit]
tdfx 54536 1
es1371 28500 0
ac97_codec 8808 0 [es1371]
I think this is the only one of the above that is required for the task.
(If that is not true, I'll revise this text and you never know I though
such a thing)
Now, turn on your TV set (unless it is already open) and make sure it
is getting (either s-video or composite... I personally have only
tested composite) input from your voodoo3 card. Don't change any
screen resolution just yet...
You notice the tv set screen is still blank. Changing screen resolutions
won't do any change on that, don't bother trying.
So, how to continue from there. The answer was found looking through
all the files that are found with zsh command line in lm_sensors dir:
grep -i voodoo3 **/*(.) | less
The file doc/chips/bt869 contains interesting information, with it
and some other information I found somewhere else, don't remember
either, I did:
modprobe -v bt869 (or insmod /lib/modules/2.x.x/misc/bt869)
NOW! you should see some noise on your TV-Set screen.
and `lsmod' returns (on my machine)
Module Size Used by
bt869 5392 0 (unused)
i2c-voodoo3 3012 0 (unused)
sensors 6140 0 [bt869]
i2c-algo-bit 7796 2 [i2c-voodoo3]
i2c-core 12844 0 [bt869 sensors i2c-algo-bit]
tdfx 54536 1
es1371 28500 0
ac97_codec 8808 0 [es1371]
If you now try to change mode to `800x600PAL' The noise pattern just
changes. That's because there are various parameters for bt869 to
make it operate in different systems.
The configuration entries for bt869 live somewhere in `proc' filesystem
and since it is so hard to remember, the following commands helps out:
# find /proc -name "bt869*" -print
In my system that output: /proc/sys/dev/sensors/bt869-i2c-0-44. Since
the last few characters may be different on your system I'll use...
# ls /proc/sys/dev/sensors/bt869* ... and this outputs:
colorbars: Output colorbars instead of display data. Default `0'.
depth: Display depth. Seems to be `16' on my system.
half: No idea. Default `0'.
ntsc: 1: use NTSC, 0: use PAL. Default: `1'.
res; Screen resolution to use. Defaut: `640 480'.
status: Outputs some status info I do not know what that is.
For me, in order to get TV sync with incoming signal (or is it Voodoo3
that needs syncing), I first put colorbars on, and when I get colorbars
visible I shut colorbars off -- and then I have part of my 1024x768
displayed on TV-screen. Normal WIMP screen doesn't look so nice, but
games, pictures, etc. Looks just fine. And HW acceleration rules.
Do the following to achieve this:
# echo 1 > /proc/sys/dev/sensors/bt869*/colorbars
# echo 0 > /proc/sys/dev/sensors/bt869*/ntsc
# echo 800 600 > /proc/sys/dev/sensors/bt869*/res
Press ctrl-alt-num_keypad_+
Now you should see vertical colorbars on your TV-Set
# echo 0 > /proc/sys/dev/sensors/bt869*/colorbars
Now (part of) your computer display should be visible on your TV-Set.
... Ok, I did just that... after ctrl-alt-num_keypad_+ I did not get
synchronized colorbar output visible on my TV. So, at this time I
re-did...
# echo 1 > /proc/sys/dev/sensors/bt869*/colorbars
... and got colorbars, and ...
# echo 0 > /proc/sys/dev/sensors/bt869*/colorbars
... got my computer display visible on my TV.
#EOF
doc/chips/ddcmon
-272
View File
@@ -1,272 +0,0 @@
Kernel driver `ddcmon.o'
========================
Status: As complete as we want it to be, lightly tested
Supported chips:
* Any DDC Monitor EDID EEPROM chip at 0x50
Prefix: 'ddcmon'
Addresses scanned: I2C 0x50
Standards: available for purchase from VESA http://www.vesa.org
Datasheets: Publicly available from Atmel (www.atmel.com),
Fairchild (www.fairchildsemi.com), and
Microchip (www.microchip.com)
Chip Size (bits) Address
24C01 1K 0x50 (shadows at 0x51 - 0x57)
(Typical device in monitors)
24C01A 1K 0x50 - 0x57 (Typical device in monitors)
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)
Author: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock
<phil@netroedge.com>, Mark Studebaker <mdsxyz123@yahoo.com> and
Jean Delvare <khali@linux-fr.org>
Special assistance on DDC provided by Petr Vandrovec <vandrove@vc.cvut.cz>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_ddcmon: short array (min = 1, max = 48)
Same as 'force'
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* checksum: int
Only accept eeproms whose checksum is correct
Description
-----------
This is a simple module for reading the EEPROM on a DDC-compliant monitor.
DDC (Display Data Channel) is the I2C-based communication channel
to the monitor. The EEPROM contains a 128-byte data structure defined
by the EDID (Extended Display Identification Data) standard.
Use:
After inserting the module (and any other required smbus/i2c modules), you
should have a directory in /proc/sys/dev/sensors/ with a name such
as "ddcmon-i2c-3-50". Inside each of these is a series of files which
represent interesting data from the DDC monitor.
/proc entries:
dpms: bitmask
DPMS support flags
0x20 Active Off
0x40 Suspend
0x80 Standby
edid: 2 integers
EDID version and revision
gamma: 1 float
gamma factor
id: 2 integers
manufacturer ID and product ID
Manufacturer ID is encoded, see 'sensors'
source ../../prog/sensors/chips.c.
maxclock: 1 integer
max pixel clock (also known as video bandwidth) (MHz)
0 if not available.
serial: 1 integer
serial number
Encoding depends on the manufacturer, don't expect the
real serial number here. 0 probably means "not available".
size: 2 integers
vertical monitor size (cm)
horizontal monitor size (cm)
sync: 4 integers
minimum vertical sync frequency (Hz)
maximum vertical sync frequency (Hz)
minimum horizontal sync frequency (KHz)
maximum horizontal sync frequency (KHz)
0 0 0 0 if not available.
time: 2 integers
Manufacture year and week
timing[1-8]: 3 integers
supported standard timing
horizontal resolution
vertical resolution
(vertical) refresh rate
0 0 0 if not used.
timings: bitmask
supported established timings
0x000001 720x400@70Hz (VGA 640x400, IBM)
0x000002 720x400@88Hz (XGA2)
0x000004 640x480@60Hz (VGA)
0x000008 640x480@67Hz (Mac II, Apple)
0x000010 640x480@72Hz (VESA)
0x000020 640x480@75Hz (VESA)
0x000040 800x600@56Hz (VESA)
0x000080 800x600@60Hz (VESA)
0x000100 800x600@72Hz (VESA)
0x000200 800x600@75Hz (VESA)
0x000400 832x624@75Hz (Mac II)
0x000800 1024x768@87Hz interlaced (8514A)
0x001000 1024x768@60Hz (VESA)
0x002000 1024x768@70Hz (VESA)
0x004000 1024x768@75Hz (VESA)
0x008000 1280x1024@75Hz (VESA)
0x010000 - 0x800000 Manufacturer reserved
0x800000 1152x870 @ 75 Hz (Mac II, Apple)?
Chip Features
-------------
Chip 'ddcmon'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
Manufacturer ID - - R- 0
Model Number - - R- 0
Monitor Size (cm) - - R- 0
hsize Monitor Size (cm) - R- 0
Vertical Sync (Hz) - - R- 0
v_sync_max Vertical Sync (Hz) - R- 0
Horizontal Sync (KHz) - - R- 0
h_sync_max Horizontal Sync (KHz) - R- 0
Established Timings - - R- 0
Serial Number - - R- 0
Manufacture Time - - R- 0
week Manufacture Time - R- 0
EDID Version - - R- 0
revision EDID Version - R- 0
Gamma Factor - - R- 2
DPMS Modes - - R- 0
Standard Timing 1 - - R- 0
vertical Standard Timing 1 - R- 0
refresh Standard Timing 1 - R- 0
Standard Timing 2 - - R- 0
vertical Standard Timing 2 - R- 0
refresh Standard Timing 2 - R- 0
Standard Timing 3 - - R- 0
vertical Standard Timing 3 - R- 0
refresh Standard Timing 3 - R- 0
Standard Timing 4 - - R- 0
vertical Standard Timing 4 - R- 0
refresh Standard Timing 4 - R- 0
Standard Timing 5 - - R- 0
vertical Standard Timing 5 - R- 0
refresh Standard Timing 5 - R- 0
Standard Timing 6 - - R- 0
vertical Standard Timing 6 - R- 0
refresh Standard Timing 6 - R- 0
Standard Timing 7 - - R- 0
vertical Standard Timing 7 - R- 0
refresh Standard Timing 7 - R- 0
Standard Timing 8 - - R- 0
vertical Standard Timing 8 - R- 0
refresh Standard Timing 8 - R- 0
Max Pixel Clock (MHz) - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
Manufacturer ID SENSORS_DDCMON_MAN_ID id:1
Model Number SENSORS_DDCMON_PROD_ID id:2
Monitor Size (cm) SENSORS_DDCMON_VERSIZE size:1
hsize SENSORS_DDCMON_HORSIZE size:2
Vertical Sync (Hz) SENSORS_DDCMON_VERSYNCMIN sync:1
v_sync_max SENSORS_DDCMON_VERSYNCMAX sync:2
Horizontal Sync (KHz) SENSORS_DDCMON_HORSYNCMIN sync:3
h_sync_max SENSORS_DDCMON_HORSYNCMAX sync:4
Established Timings SENSORS_DDCMON_TIMINGS timings:1
Serial Number SENSORS_DDCMON_SERIAL serial:1
Manufacture Time SENSORS_DDCMON_YEAR time:1
week SENSORS_DDCMON_WEEK time:2
EDID Version SENSORS_DDCMON_EDID_VER edid:1
revision SENSORS_DDCMON_EDID_REV edid:2
Gamma Factor SENSORS_DDCMON_GAMMA gamma:1
DPMS Modes SENSORS_DDCMON_DPMS dpms:1
Standard Timing 1 SENSORS_DDCMON_TIMING1_HOR timing1:1
vertical SENSORS_DDCMON_TIMING1_VER timing1:2
refresh SENSORS_DDCMON_TIMING1_REF timing1:3
Standard Timing 2 SENSORS_DDCMON_TIMING2_HOR timing2:1
vertical SENSORS_DDCMON_TIMING2_VER timing2:2
refresh SENSORS_DDCMON_TIMING2_REF timing2:3
Standard Timing 3 SENSORS_DDCMON_TIMING3_HOR timing3:1
vertical SENSORS_DDCMON_TIMING3_VER timing3:2
refresh SENSORS_DDCMON_TIMING3_REF timing3:3
Standard Timing 4 SENSORS_DDCMON_TIMING4_HOR timing4:1
vertical SENSORS_DDCMON_TIMING4_VER timing4:2
refresh SENSORS_DDCMON_TIMING4_REF timing4:3
Standard Timing 5 SENSORS_DDCMON_TIMING5_HOR timing5:1
vertical SENSORS_DDCMON_TIMING5_VER timing5:2
refresh SENSORS_DDCMON_TIMING5_REF timing5:3
Standard Timing 6 SENSORS_DDCMON_TIMING6_HOR timing6:1
vertical SENSORS_DDCMON_TIMING6_VER timing6:2
refresh SENSORS_DDCMON_TIMING6_REF timing6:3
Standard Timing 7 SENSORS_DDCMON_TIMING7_HOR timing7:1
vertical SENSORS_DDCMON_TIMING7_VER timing7:2
refresh SENSORS_DDCMON_TIMING7_REF timing7:3
Standard Timing 8 SENSORS_DDCMON_TIMING8_HOR timing8:1
vertical SENSORS_DDCMON_TIMING8_VER timing8:2
refresh SENSORS_DDCMON_TIMING8_REF timing8:3
Max Pixel Clock (MHz) SENSORS_DDCMON_MAXCLOCK maxclock:1
Notes
-----
- The eeprom.o module will also attach to a DDC monitor. Install the
ddcmon.o module before the eeprom.o module to prevent this.
Alternatively, give the eeprom.o module an ignore= parameter or
a checksum= parameter. The ddcmon.o module will not attach to non-DDC
eeproms because it checks for a DDC 'signature' at the beginning
of the DDC Monitor's eeprom. Additionally, you can give it a checksum=
parameter.
- If a DDC monitor eeprom lacks the 'signature', you may use the
'force' parameter (modprobe ddcmon force=x,0x50 where 'x' is the
i2c bus number).
- This module requires a bus driver for your video chip to access the
DDC bus. In this package, drivers exist for Voodoo3/Banshee chips.
See documentation for those drivers in ../busses. Other drivers
(Matrox and NVidia, for example) are available in the kernel or
elsewhere. See our 'Supported Devices' web page for details.
- There is a checksum over the 128 bytes in the eeprom. The driver
used not to check it, now it does (providing you give it a
checksum= parameter).
- More information is available in the eeprom which could be made
available by enhancing the driver.
To see the entire eeprom, use the eeprom.o module instead of ddcmon.o.
However, then you lose the DDC-specific formatting.
Also see ../../prog/eeprom/decode-edid.pl.
- This driver does not support the DDC/CI (DDC2Bi) bidirectional
communications channel to the monitor for controlling the monitor.
- The driver caches the data from the monitor and only rereads it
from the eeprom if the cache is more than 5 minutes old.
- X 4.0 also accesses the DDC monitor EEPROM to auto-configure itself.
There could possibly be conflicts from these multiple accesses, but
none were ever reported so far.
doc/chips/ds1307
-25
View File
@@ -1,25 +0,0 @@
Kernel driver `ds1307.o'
========================
Status: Complete and well-tested
Supported chips:
* Dallas Semiconductor DS1307 Real-time clock
Author: Abraham vd Merwe <abraham@2d3d.co.za>
Module Parameters
-----------------
There are no module parameters. The driver only scans address 0x68 for
presence of the real-time clock chip (which is the only possible address).
Description
-----------
This module provides an API for drivers RTC and NVRAM drivers to use in
order to access the DS1307 real-time clock. Examples of drivers that uses
this API are the frodo-nvram and frodo-rtc drivers.
doc/chips/ds1621
-237
View File
@@ -1,237 +0,0 @@
Kernel driver `ds1621.o'
========================
Status: Complete and tested; enhanced features experimental
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/
Author: Christian W. Zuckschwerdt <zany@triq.net>
valueable contributions by Jan M. Sendler <sendler@sendler.de>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_ds1621: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to
contain a `ds1621' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
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. Unfortunally though, you will need a hash table or even a
conversion routine for that.
Temperature readings are internally converted into a 9bit value to be
read straight via the i2c-bus, but higher resolutions may be obtained
with little effort via 'precise_temp' access or using a simple algorithm.
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' proc file interface. The result consits 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.
This driver also detects DS1625. As this chip is discontinued, you
should use a DS1621 instead. Detected 1625s also get the
"ds1621"-prefix, but the accuracy registers are not supported.
The latest modification of this driver was not checked against 1625s,
though, but should work well with them.
Default values written into the DS1621 upon detection are:
Temperature limits: High 60.0; low 0.0 degree Celsius;
Continuous mode (not enabled), Tout active high, alarms reset.
Accessing DS1621 via /proc interface (part I)
---------------------------------------------
On detection (i.e. insmod, modprobe et al.), directories are being
created for each detected DS1621:
/proc/sys/dev/sensors/ds1621-<0>-<1>/
where <0> is the bus the chip was detected on (e. g. i2c-0)
and <1> the chip address ([48..4f]): ./ds1621-i2c-0-48/
Inside these directories, there are five files each:
alarms, continuous, enable, polarity and temp.
The temp, alarms and enable are LM75-like for compatibility reasons:
The temp file is rw. Reading gives TEMP_HIGH:TEMP_HYST:TEMP, where
TEMP_HIGH is the upper limit temp, TEMP_HYST is the hysteresis (lower
limit) temp and TEMP is the actual temperature. (For things like
ONE_SHOT, see below.) - Writing takes two results (read: input
values): TEMP_HIGH:TEMP_HYST. This provides an easy way to set limits.
The alarms file is ro. Basically, it is 0x40 ("64") for the high alarm
bit set plus 0x20 ("32") for the low one. Since alarms are being reset
by the module when the limit conditions are no longer met, you should
first read the alarms before you do anything else (such as reading the
temperature), or the information may be lost.
The polarity file is rw. Reading gives "0" for active high, which
describes a need for cooling corresponds to Tout status. "1" means
active low, so you can connect a powerful heater directly to Tout
(DON'T TRY!). - Writing accepts "0" and "1" accordingly. Again, note
that the statements on page 5 of the DS1621 data sheet are misleading;
change the orientation of the vertical arrows in the sketch there
instead.
To understand the use of the other things, it is useful to have a
brief look at the internal DS1621 procedures:
High Accuracy Temperature Reading
---------------------------------
As said before, the temperature issued via the 9bit 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 accuracy 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 9bit 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.
Accessing DS1621 via /proc interface (part II and end)
------------------------------------------------------
The continuous file is rw. Reading gives "1" when the chip is in
continuous mode and "0" for 1SHOT. - Writing accepts "1" to put it
into continuous mode or "0" for 1SHOT.
The enable file is rw. Reading gives "1" if in continuous mode the
DS1621 is "running" or if in 1SHOT mode it is "shooting". In fact, the
value returned here is the negated DONE bit, just like a "BUSY"
flag. This means, that the "1" tells you that the values in REG_COUNT
and REG_SLOPE are not valid. "0", on the other hand, means that the
continuous conversion had been stopped long enough to provide valid
readings and that one shot has successfully been fi- red,
respectively. - Writing accepts "1" to start continuous conversion or
to pull the trigger in 1SHOT mode, and "0" stops continuous conversion
to allow for valid readings. Writing "0" in 1SHOT doesn't make much
sense since you cannot catch a bullet, can you? No, the thing is that
DS1621 does only do one conversion then anyway, and after that,
there's nothing to stop.
Last, but best try writing "0" to the "continuous" file and after that
"1" to the "enable" file. This gives you the precise temperature with
two digits after the radix (decimal point).
The precise results are only updated if the DONE bit was set, thus you
have to stop continuous conversion early enough prior to reading,
i. e. 1000ms. And, on the other hand, you shouldn't forget to fire off
1SHOT in order to get the actual temperature rather than that of the
day before yesterday. So read enable before any of these.
Chip Features
-------------
Chip `ds1621'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
alarms NONE NONE R 0
enable NONE NONE RW 0
continuous NONE NONE RW 0
polarity NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
temp SENSORS_DS1621_TEMP temp:3
temp_hyst SENSORS_DS1621_TEMP_HYST temp:2
temp_over SENSORS_DS1621_TEMP_OVER temp:1
alarms SENSORS_DS1621_ALARMS alarms:1
enable SENSORS_DS1621_ENABLE enable:1
continuous SENSORS_DS1621_CONTINUOUS continuous:1
polarity SENSORS_DS1621_POLARITY polarity:1
doc/chips/eeprom
-228
View File
@@ -1,228 +0,0 @@
Kernel driver `eeprom.o'
========================
Status: Complete and well-tested
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
Author: Frodo Looijaard <frodol@dds.nl> and Philip Edelbrock
<phil@netroedge.com>
Module Parameters
-----------------
* checksum: int
Only accept eeproms whose checksum is correct
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_eeprom: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `eeprom' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
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. See the 'ddcmon' driver which has
specialized /proc entries for DDC monitors. If the eeprom driver is
loaded before the ddcmon driver and there is no 'ignore' line in the
/etc/sensors.conf file, the eeprom driver will latch onto the DDC monitor
eeprom.
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 /proc/sys/dev/sensors/ of names such
as "eeprom-i2c-0-50". Inside each of these is a series of files which
represent 16 bytes blocks from the EEPROM. The data is in decimal (base
10) delimited by spaces.
Note:
EEPROMs reported are not nessesarily all from DIMMs. Xeon processors, for
example, have serial EEPROMs in them connected to the SMBus which will be
found by the module. Take care to ignore the output of decode-dimms.pl for
these EEPROMs. There is decode-xeon.pl for them. Same applies to Vaio
EEPROMs, which have decode-vaio.pl.
The driver caches the data from the monitor and only rereads it
from the eeprom if the cache is more than 5 minutes old.
Decode-dimms.pl
---------------
This Perl script attempts to make sense of the first 128 bytes of a SDRAM
PC-100 DIMM. Using the 'Serial Presence Detect (SPD)' Spec (Rev1.2a)** from
Intel. When finished, it will decode and report all the values defined in
the spec. Much of the information is technical timing and interfacing info
(probably not all used by the BIOS or clocking IC).
Note: During testing, we noticed that many DIMMs have trucated SPD records.
I'm not sure if these conform to an old spec, or if the manufacturers are
simply just taking shortcuts. But, many DIMMs have all zeros stored past
byte 21. I asked an Intel SDRAM tester, Sat Kolli (skolli@smartm.com),
about this and this is what he had to say:
"[...] Now in terms of SPD contents, you are right that people do all kinds
of things. The way to insure that any module works is to look for the most
basic information, such as module bank density, number of banks, and device
addresses. That will give you the module size and what devices are used. It
is very difficult to verify if the module is PC-100, because of
inconsistencies between spd data from different manufacturers. You could
read the timing information or the special Intel bytes (126 & 127) but I do
not know how many program that information. These inconsistencies may be
minimized if you or your customers stay with some of the better known
manufacturers." (Thanks goes to Sat Kolli for his comments and help.)
Use:
After inserting the necessary modules, run the script!
Notes:
The script assumes that Perl can be found at /usr/bin/perl. If different,
you will need to adjust the first line of the file accordingly, or else
you will get a strange "decode-dimms.pl: no such file or directory" error.
Also note that the script assumes that _all_ the eeproms belong to DIMMs,
which may not be the case.
Decode-vaio.pl
--------------
This Perl script looks for a Sony Vaio EEPROM at 0x57. If your system is not
a Sony Vaio laptop, you just don't care. If your system is an old Vaio, you
probably don't have an EEPROM on it and this script will be useless to you
as well.
Use:
After inserting the necessary modules, run the script!
Notes:
The script assumes that Perl can be found at /usr/bin/perl. If different,
you will need to adjust the first line of the file accordingly, or else
you will get a strange "decode-vaio.pl: no such file or directory" error.
Decode-edid.pl
This Perl script acts as an interface between the eeprom module and
parse-edid, which is part of read-edid. Read-edid is a tool for gathering
information on VESA PNP monitors. It is somewhat similar to what our
ddcmon driver does, except that ddcmon outputs user-oriented data while
read-edid generates a a computer oriented configuration file (primarily
for XFree86).
Read-edid is made of two components, get-edid which retrieves binary data
from the monitor, and parse-edid which decodes the data into useful
information. Get-edid uses low level functions, and relies on compliance
of both the video card and the monitor to some standard (DCC as it is
called). It may not work for everyone. On the other hand, some video
cards make this information available on an I2C bus and we are able to
get it using our eeprom module. That's why we wrote this script that
converts the data as exported by our eeprom module into what parse-edid
expects from get-edid. That way, users who can't get get-edid to work
still have a chance to be able to retrieve the wanted information thanks
to the lm_sensors modules and tools.
Use:
Unload the ddcmon if it was loaded, load the eeprom module instead. Then,
run the script. The script will try to figure out on which I2C bus and at
which address is the eeprom, but it may fail. In this case, you can pass
the parameters to the script. Examples:
decode-edid.pl 1
decode-edid.pl 2 0x50
You will find additional details in the script itself. Read-edid is avilable
there:
http://john.fremlin.de/programs/linux/read-edid/
doc/chips/f71805f
-107
View File
@@ -1,107 +0,0 @@
Kernel driver `f71805f.o'
=========================
Status: Beta.
Supported chips:
* Fintek F71805F/FG
Addresses scanned: none, address read from Super I/O config space
Prefix: 'f71805f'
Datasheet: Provided by Fintek on request
Author: Jean Delvare <khali@linux-fr.org>
Thanks to Denis Kieft from Barracuda Networks for the donation of a
test system (custom Jetway K8M8MS motherboard, with CPU and RAM) and
for providing initial documentation.
Thanks to Kris Chen from Fintek for answering technical questions and
providing additional documentation.
Thanks to Chris Lin from Jetway for providing wiring schematics and
answering technical questions.
Description
-----------
The Fintek F71805F/FG Super I/O chip includes complete hardware monitoring
capabilities. It can monitor up to 9 voltages (counting its own power
source), 3 fans and 3 temperature sensors.
This chip also has fan controlling features, using either DC or PWM, in
three different modes (one manual, two automatic). The driver doesn't
support these features yet.
The driver assumes that no more than one chip is present, which seems
reasonable.
Voltage Monitoring
------------------
Voltages are sampled by an 8-bit ADC with a LSB of 8 mV. The supported
range is thus from 0 to 2.040 V. Voltage values outside of this range
need external resistors. An exception is in0, which is used to monitor
the chip's own power source (+3.3V), and is divided internally by a
factor 2.
The two LSB of the voltage limit registers are not used (always 0), so
you can only set the limits in steps of 32 mV (before scaling).
The wirings and resistor values suggested by Fintek are as follow:
pin expected
name use R1 R2 divider raw val.
in0 VCC VCC3.3V int. int. 2.00 1.65 V
in1 VIN1 VTT1.2V 10K - 1.00 1.20 V
in2 VIN2 VRAM 100K 100K 2.00 ~1.25 V (1)
in3 VIN3 VCHIPSET 47K 100K 1.47 2.24 V (2)
in4 VIN4 VCC5V 200K 47K 5.25 0.95 V
in5 VIN5 +12V 200K 20K 11.00 1.05 V
in6 VIN6 VCC1.5V 10K - 1.00 1.50 V
in7 VIN7 VCORE 10K - 1.00 ~1.40 V (1)
in8 VIN8 VSB5V 200K 47K 1.00 0.95 V
(1) Depends on your hardware setup.
(2) Obviously not correct, swapping R1 and R2 would make more sense.
These values can be used as hints at best, as motherboard manufacturers
are free to use a completely different setup. As a matter of fact, the
Jetway K8M8MS uses a significantly different setup. You will have to
find out documentation about your own motherboard, and edit sensors.conf
accordingly.
Each voltage measured has associated low and high limits, each of which
triggers an alarm when crossed.
Fan Monitoring
--------------
Fan rotation speeds are reported as 12-bit values from a gated clock
signal. Speeds down to 366 RPM can be measured. There is no theoretical
high limit, but values over 6000 RPM seem to cause problem. The effective
resolution is much lower than you would expect, the step between different
register values being 10 rather than 1.
The chip assumes 2 pulse-per-revolution fans.
An alarm is triggered if the rotation speed drops below a programmable
limit or is too low to be measured.
Temperature Monitoring
----------------------
Temperatures are reported in degrees Celsius. Each temperature measured
has a high limit, those crossing triggers an alarm. There is an associated
hysteresis value, below which the temperature has to drop before the
alarm is cleared.
All temperature channels are external, there is no embedded temperature
sensor. Each channel can be used for connecting either a thermal diode
or a thermistor. The driver reports the currently selected mode, but
doesn't allow changing it. In theory, the BIOS should have configured
everything properly.
doc/chips/fscher
-266
View File
@@ -1,266 +0,0 @@
Kernel driver `fscher.o'
=======================
Status: Stable
Tested with motherboard D1562
Think twice before you're using the write mode of some
variables, especially the watchdog
Supported chips:
* Fujitsu-Siemens Hermes chip
Prefix: 'fscher'
Addresses scanned: I2C 0x73
Author: Reinhard Nissl <rnissl@gmx.de> based on work from Hermann Jung
<hej@odn.de>, Frodo Looijaard <frodol@dds.nl> and Philip Edelbrock
<phil@netroedge.com>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_fscher: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `fscher' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
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.
* rev:1
READING & 0xff = 0x??: HERMES revision identification
* alarms:1
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:1
READING & 0x01 = 0x01: software event
READING & 0x01 = 0x00: no software event
WRITING & 0x01 = 0x01: set software event
WRITING & 0x01 = 0x00: clear software event
* wdog:3
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
* wdog:2
READING & 0x02 = 0x02: watchdog system reset occurred
READING & 0x02 = 0x00: no watchdog system reset occurred
WRITING & 0x02 = 0x02: clear watchdog event
* wdog:1
READING & 0xff = 0x??: configured watch dog time in units (see wdog:3 0x40)
WRITING & 0xff = 0x??: configure watch dog time in units
* in*:1 (0: +5V, 1: +12V, 2: onboard 3V battery)
READING: actual voltage value
* temp*:1 (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*:2 (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor)
READING: actual temperature value
* fan*:1 (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*:2 (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
READING & 0x03 = 0x03: 8 ripples are one fan turn
READING & 0x03 = 0x02: 4 ripples are one fan turn
READING & 0x03 = 0x01: 2 ripples are one fan turn
WRITING & 0x03 = 0x03: set prescaler to "8 ripples are one fan turn"
WRITING & 0x03 = 0x02: set prescaler to "4 ripples are one fan turn"
WRITING & 0x03 = 0x01: set prescaler to "2 ripples are one fan turn"
* fan*:3 (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*:4 (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 controled by this implementation.
Chip Features
-------------
Chip 'fscher'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
rev - - R- 0
alarms - - R- 0
control - - RW 0
in0 - - R- 2
in1 - - R- 2
in2 - - R- 2
temp1 - - R- 0
temp2 - - R- 0
temp3 - - R- 0
temp1_state temp1 temp1 RW 0
temp2_state temp2 temp2 RW 0
temp3_state temp3 temp3 RW 0
fan1 - - R- 0
fan2 - - R- 0
fan3 - - R- 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan3_min fan3 fan3 RW 0
fan1_state fan1 fan1 RW 0
fan2_state fan2 fan2 RW 0
fan3_state fan3 fan3 RW 0
fan1_ripple fan1 fan1 RW 0
fan2_ripple fan2 fan2 RW 0
fan3_ripple fan3 fan3 RW 0
wdog_preset - - RW 0
wdog_state wdog_preset wdog_preset RW 0
wdog_control wdog_preset wdog_preset RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
rev SENSORS_FSCHER_REV rev:1
alarms SENSORS_FSCHER_EVENT alarms:1
control SENSORS_FSCHER_CONTROL control:1
in0 SENSORS_FSCHER_VOLTAGE1 in0:1
in1 SENSORS_FSCHER_VOLTAGE2 in1:1
in2 SENSORS_FSCHER_VOLTAGE3 in2:1
temp1 SENSORS_FSCHER_TEMP1 temp1:2
temp2 SENSORS_FSCHER_TEMP2 temp2:2
temp3 SENSORS_FSCHER_TEMP3 temp3:2
temp1_state SENSORS_FSCHER_TEMP1_STATE temp1:1
temp2_state SENSORS_FSCHER_TEMP2_STATE temp2:1
temp3_state SENSORS_FSCHER_TEMP3_STATE temp3:1
fan1 SENSORS_FSCHER_FAN1 fan1:4
fan2 SENSORS_FSCHER_FAN2 fan2:4
fan3 SENSORS_FSCHER_FAN3 fan3:4
fan1_min SENSORS_FSCHER_FAN1_MIN fan1:2
fan2_min SENSORS_FSCHER_FAN2_MIN fan2:2
fan3_min SENSORS_FSCHER_FAN3_MIN fan3:2
fan1_state SENSORS_FSCHER_FAN1_STATE fan1:1
fan2_state SENSORS_FSCHER_FAN2_STATE fan2:1
fan3_state SENSORS_FSCHER_FAN3_STATE fan3:1
fan1_ripple SENSORS_FSCHER_FAN1_RIPPLE fan1:3
fan2_ripple SENSORS_FSCHER_FAN2_RIPPLE fan2:3
fan3_ripple SENSORS_FSCHER_FAN3_RIPPLE fan3:3
wdog_preset SENSORS_FSCHER_WDOG_PRESET wdog:1
wdog_state SENSORS_FSCHER_WDOG_STATE wdog:2
wdog_control SENSORS_FSCHER_WDOG_CONTROL wdog:3
doc/chips/fscpos
-122
View File
@@ -1,122 +0,0 @@
Kernel driver `fscpos.o'
======================
Status: Beta
Tested with motherboard d1107
Think twice before you're using the write mode of some
variables, especially the watchdog
Supported chips:
* Fujitsu Siemens Poseidon chip
Prefix: 'fscpos'
Addresses scanned: I2C 0x73
Author: Hermann Jung <hej@odn.de>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This driver implements support for the Fujitsu Siemens Poseidon chip.
It is descibed in the 'Register Set Specification BMC Poseidon based
Systemboard' from Fujitsu Siemens.
The poseidon 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 shutdown the system.
The chip provides three temperature values (cpu, motherboard and auxiliary),
three current values (12 volt, 5 volt 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, 4 or 8) 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.
Chip Features
-------------
Chip `fscpos'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
rev NONE NONE R 0
event NONE NONE R 0
control NONE NONE RW 0
volt12 NONE NONE R 2
volt5 NONE NONE R 2
voltbatt NONE NONE R 2
temp1 NONE NONE R 0
temp2 NONE NONE R 0
temp3 NONE NONE R 0
temp1_state temp1 temp1 RW 0
temp2_state temp2 temp2 RW 0
temp3_state temp3 temp3 RW 0
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan3 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan1_state fan1 fan1 RW 0
fan2_state fan2 fan2 RW 0
fan3_state fan3 fan3 RW 0
fan1_ripple fan1 fan1 RW 0
fan2_ripple fan2 fan2 RW 0
fan3_ripple fan3 fan3 RW 0
wdog_preset NONE NONE RW 0
wdog_state wdog_preset wdog_preset RW 0
wdog_control wdog_preset wdog_preset RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
rev FSCPOS_SYSCTL_REV rev:1
event FSCPOS_SYSCTL_EVENT event:1
control FSCPOS_SYSCTL_CONTROL control:1
volt12 FSCPOS_SYSCTL_VOLTAGE1 volt0:1
volt5 FSCPOS_SYSCTL_VOLTAGE2 volt1:1
voltbatt FSCPOS_SYSCTL_VOLTAGE3 volt2:1
temp1 FSCPOS_SYSCTL_TEMP1 temp0:2
temp2 FSCPOS_SYSCTL_TEMP2 temp1:2
temp3 FSCPOS_SYSCTL_TEMP3 temp2:2
temp1_state FSCPOS_SYSCTL_TEMP1_STATE temp0:1
temp2_state FSCPOS_SYSCTL_TEMP2_STATE temp1:1
temp3_state FSCPOS_SYSCTL_TEMP3_STATE temp2:1
fan1 FSCPOS_SYSCTL_FAN1 fan0:4
fan2 FSCPOS_SYSCTL_FAN2 fan1:4
fan3 FSCPOS_SYSCTL_FAN3 fan2:4
fan1_min FSCPOS_SYSCTL_FAN1_MIN fan0:2
fan2_min FSCPOS_SYSCTL_FAN2_MIN fan1:2
fan1_state FSCPOS_SYSCTL_FAN1_STATE fan0:1
fan2_state FSCPOS_SYSCTL_FAN2_STATE fan1:1
fan3_state FSCPOS_SYSCTL_FAN3_STATE fan2:1
fan1_ripple FSCPOS_SYSCTL_FAN1_RIPPLE fan0:3
fan2_ripple FSCPOS_SYSCTL_FAN2_RIPPLE fan1:3
fan3_ripple FSCPOS_SYSCTL_FAN3_RIPPLE fan2:3
wdog_preset FSCPOS_SYSCTL_WDOG_PRESET wdog:1
wdog_state FSCPOS_SYSCTL_WDOG_STATE wdog:2
wdog_control FSCPOS_SYSCTL_WDOG_CONTROL wdog:3
doc/chips/fscscy
-251
View File
@@ -1,251 +0,0 @@
Kernel driver `fscscy.o'
======================
Status: Beta
Tested with motherboard D1230
Should also work with D1204, D1306 and D1307
Think twice before you're using the write mode of some
variables, especially the watchdog (Not my comment, but it makes
good sense to observe :-)
Supported chips:
* Fujitsu Siemens Scylla chip
Prefix: 'fscscy'
Addresses scanned: I2C 0x73
Author: Martin Knoblauch <mkn@teraport.de>
Acknowledgement:
This code has been greatly inspired by Hermann Jung <hej@odn.de>
and his work on the Poseidon driver (fscpos)
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This driver implements support for the Fujitsu Siemens Scylla chip.
The code is based on the "fscpos" driver for the FSC Poseidon chip.
In fact, it seems the Scylla is a superset of the "Poseidon", "Poseidon II"
and "Hydra" chips.
The register readings/setting have been deduced from the 'Register Set
Specification BMC Poseidon based Systemboard' by Fujitsu Siemens and the
"sbbmon.ini" file from the Fujitsu-Siemens ServerView software.
The scylla 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 shutdown the system. See above for more details about using
the watchdog feature.
The chip provides four temperature values (cpu0/1, motherboard and auxiliary),
three current values (12 volt, 5 volt and battery) and up to
six fans (power supply, cpu and auxiliary).
Temperatures are measured in degrees Celsius. The resolution is 1 degree.
In addition to state and actual temperature, the temperature sensors also export
a LIMIT temperature for each sensor. The meaning of the information itself is
obvious. The rest is guesswork. It likely triggers an alarm/event as soon as it is
reached. The authors feeling is that it is even a writeable register. But beeing of
the cautios kind he did not implement writing the LIMIT resister. The driver itself
keeps track of the minimum and maximum temperatures since module load. The more often
the module is accessed, the more meaningful these values are.
Fan rotation speeds are reported in RPM (rotations per minute).
The value can be divided by a programmable divider (1, 2, 4 or 8) 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.
Using The Watchdog
------------------
This part was mostly contributed by A'rpi <arpi@thot.banki.hu>. Thanks!
I (Jean Delvare) edited the text for greater clarity, mainly to integrate
the e-mail exchange I and A'rpi had as a sequel of the original report.
Here it goes.
I've spent few hours experiencing with the watchdog feature of the Fujitsu
Siemens server board (don't ask the model name, what I know is that it uses
Serverworks CSB5 chipset) using lm_sensors' fscscy driver.
OK, so there is /proc/sys/dev/sensors/fscscy-i2c-0-73/wdog, containing 3
8-bit values for the 3 watchdog registers.
The first one is the time counter, it counts backwards. It's in 2 seconds
base, so writting 30 there means 60 seconds delay. It seems the whole range
(0 to 255) is supported, so up to 510 seconds (8.5 minutes). Writting 0 means
immediate hardware reset. The value you can read back is the same as you wrote
there, not the current value of the counter (as I expected).
The second number is supposed to be a state register. It doesn't matter what
value I put there. It's always 0. Even if I write a non-zero value there, i got
0 back. Maybe it's non-zero at the moment of reset :)
The third is the control register, with 5th (value 16), 6th (value 32) and 8th
(value 128) bits used only. If I write 16 or 144 (128+16), it means system
reset when the counter reaches 0. If I add 32 (for a value of 48 or 176), no
reset will occur.
So, the world's simplest watchdog using this mainboard:
while true ; do
echo 30 0 16 > /proc/sys/dev/sensors/fscscy-i2c-0-73/wdog
sleep 10
done
It does hardware reset after 1 minute, if this script is killed or system
hang-up occurs. Adjust the 30 and 10 values according to you needs, but
remember you must sleep less than the reset countdown time (here, 30*2-10
gives us a 50 seconds margin, which is more than enough).
Also note that BIOS has a strange setting, named 'OS Boot Retry Count', set
to 0 by default, it changes watchdog behaviour to power off instead of reset.
(0=poweroff 1..7=reset). It took me a while to find this. This behavior is
probably related to the "Reset Limit" parameter defined by the ACPI
specification (3.3.24 System Reset (Type 23)). It sets how many unintentional
resets can be performed in a row before giving up (and shut down).
Please add the above to the documentation (doc/chips/fscscy), so i can save
a few hours of resetting for other people :)
Chip Features
-------------
Chip `fscscy'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
rev NONE NONE R 0
event NONE NONE R 0
control NONE NONE RW 0
volt12 NONE NONE R 2
volt5 NONE NONE R 2
voltbatt NONE NONE R 2
temp1 NONE NONE R 0
temp2 NONE NONE R 0
temp3 NONE NONE R 0
temp4 NONE NONE R 0
temp1_state temp1 temp1 RW 0
temp2_state temp2 temp2 RW 0
temp3_state temp3 temp3 RW 0
temp4_state temp4 temp4 RW 0
temp1_lim temp1 temp1 R* 0
temp2_lim temp2 temp2 R* 0
temp3_lim temp3 temp3 R* 0
temp4_lim temp4 temp4 R* 0
temp1_min temp1 temp1 R 0
temp2_min temp2 temp2 R 0
temp3_min temp3 temp3 R 0
temp4_min temp4 temp4 R 0
temp1_max temp1 temp1 R 0
temp2_max temp2 temp2 R 0
temp3_max temp3 temp3 R 0
temp4_max temp4 temp4 R 0
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan3 NONE NONE R 0
fan4 NONE NONE R 0
fan5 NONE NONE R 0
fan6 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan3_min fan3 fan3 RW 0
fan4_min fan4 fan4 RW 0
fan5_min fan5 fan5 RW 0
fan6_min fan6 fan6 RW 0
fan1_state fan1 fan1 RW 0
fan2_state fan2 fan2 RW 0
fan3_state fan3 fan3 RW 0
fan4_state fan4 fan4 RW 0
fan5_state fan5 fan5 RW 0
fan6_state fan6 fan6 RW 0
fan1_ripple fan1 fan1 RW 0
fan2_ripple fan2 fan2 RW 0
fan3_ripple fan3 fan3 RW 0
fan4_ripple fan4 fan4 RW 0
fan5_ripple fan5 fan5 RW 0
fan6_ripple fan6 fan6 RW 0
wdog_preset NONE NONE RW 0
wdog_state wdog_preset wdog_preset RW 0
wdog_control wdog_preset wdog_preset RW 0
R*: Maybe writable, but due to lack of documentation the author did not dare
to implement it :-)
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
rev FSCSCY_SYSCTL_REV rev:1
event FSCSCY_SYSCTL_EVENT event:1
control FSCSCY_SYSCTL_CONTROL control:1
volt12 FSCSCY_SYSCTL_VOLTAGE1 volt0:1
volt5 FSCSCY_SYSCTL_VOLTAGE2 volt1:1
voltbatt FSCSCY_SYSCTL_VOLTAGE3 volt2:1
temp1 FSCSCY_SYSCTL_TEMP1 temp0:2
temp2 FSCSCY_SYSCTL_TEMP2 temp1:2
temp3 FSCSCY_SYSCTL_TEMP3 temp2:2
temp4 FSCSCY_SYSCTL_TEMP4 temp3:2
temp1_state FSCSCY_SYSCTL_TEMP1_STATE temp0:1
temp2_state FSCSCY_SYSCTL_TEMP2_STATE temp1:1
temp3_state FSCSCY_SYSCTL_TEMP3_STATE temp2:1
temp4_state FSCSCY_SYSCTL_TEMP4_STATE temp3:1
temp1_lim FSCSCY_SYSCTL_TEMP1_LIM temp0:3
temp2_lim FSCSCY_SYSCTL_TEMP2_LIM temp1:3
temp3_lim FSCSCY_SYSCTL_TEMP3_LIM temp2:3
temp4_lim FSCSCY_SYSCTL_TEMP4_LIM temp3:3
temp1_min FSCSCY_SYSCTL_TEMP1_MIN temp0:4
temp2_min FSCSCY_SYSCTL_TEMP2_MIN temp1:4
temp3_min FSCSCY_SYSCTL_TEMP3_MIN temp2:4
temp4_min FSCSCY_SYSCTL_TEMP4_MIN temp3:4
temp1_max FSCSCY_SYSCTL_TEMP1_MIN temp0:5
temp2_max FSCSCY_SYSCTL_TEMP2_MIN temp1:5
temp3_max FSCSCY_SYSCTL_TEMP3_MIN temp2:5
temp4_max FSCSCY_SYSCTL_TEMP4_MIN temp3:5
fan1 FSCSCY_SYSCTL_FAN1 fan0:4
fan2 FSCSCY_SYSCTL_FAN2 fan1:4
fan3 FSCSCY_SYSCTL_FAN3 fan2:4
fan4 FSCSCY_SYSCTL_FAN4 fan3:4
fan5 FSCSCY_SYSCTL_FAN5 fan4:4
fan6 FSCSCY_SYSCTL_FAN6 fan5:4
fan1_min FSCSCY_SYSCTL_FAN1_MIN fan0:2
fan2_min FSCSCY_SYSCTL_FAN2_MIN fan1:2
fan3_min FSCSCY_SYSCTL_FAN3_MIN fan2:2
fan4_min FSCSCY_SYSCTL_FAN4_MIN fan3:2
fan5_min FSCSCY_SYSCTL_FAN5_MIN fan4:2
fan6_min FSCSCY_SYSCTL_FAN6_MIN fan5:2
fan1_state FSCSCY_SYSCTL_FAN1_STATE fan0:1
fan2_state FSCSCY_SYSCTL_FAN2_STATE fan1:1
fan3_state FSCSCY_SYSCTL_FAN3_STATE fan2:1
fan4_state FSCSCY_SYSCTL_FAN4_STATE fan3:1
fan5_state FSCSCY_SYSCTL_FAN5_STATE fan4:1
fan6_state FSCSCY_SYSCTL_FAN6_STATE fan5:1
fan1_ripple FSCSCY_SYSCTL_FAN1_RIPPLE fan0:3
fan2_ripple FSCSCY_SYSCTL_FAN2_RIPPLE fan1:3
fan3_ripple FSCSCY_SYSCTL_FAN3_RIPPLE fan2:3
fan4_ripple FSCSCY_SYSCTL_FAN3_RIPPLE fan3:3
fan5_ripple FSCSCY_SYSCTL_FAN3_RIPPLE fan4:3
fan6_ripple FSCSCY_SYSCTL_FAN3_RIPPLE fan5:3
wdog_preset FSCSCY_SYSCTL_WDOG_PRESET wdog:1
wdog_state FSCSCY_SYSCTL_WDOG_STATE wdog:2
wdog_control FSCSCY_SYSCTL_WDOG_CONTROL wdog:3
doc/chips/gl518sm
-184
View File
@@ -1,184 +0,0 @@
Kernel driver `gl518sm.o'
=========================
Status: Complete and well-tested
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
Author: Frodo Looijaard <frodol@dds.nl>,
Kyösti Mälkki <kmalkki@cc.hut.fi>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_gl518sm_r00: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `gl518sm_r00' chip
* force_gl518sm_r80: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `gl518sm_r80' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
IMPORTANT: For the revision 0x00 chip, the
in0, in1, and in2 values (+5, +3, and +12) CANNOT be read
unless you use the slow 'iterate' method. Limits will still
work even when iterate=0. See below. This is a limitation
of the chip, not the driver.
Note that the 'iterate' method was trimmed while porting the
driver to Linux 2.6 as we considered it too ugly for the thin
benefit.
This driver supports the Genesys Logic GL518SM chip. There are at least
two revision of this chip, which we call revision 0x00 and 0x80. Revision
0x80 chips support the reading of voltages directly, 0x00 only for VIN3.
The GL518SM implements one temperature sensor, two fan rotation speed
sensors, and four voltage sensors. It can report alarms through the
computer speakers.
Temperatures are measured in degrees Celsius. An alarm goes off while the
temperature is above the over temperature limit, and has not yet dropped
below the hysteresis limit. The alarm always reflects the current situation.
Measurements are guaranteed between -10 degrees and +110 degrees, with
a resolution of +-3 degrees.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit.
In case when you have selected to turn Fan1 off, no Fan1 alarm is triggered.
Fan readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 1900 RPM.
Voltage sensors (also known as VIN sensors) report their values in volts. 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. The VDD input
measures voltages between 0.000 and 5.865 volt, with a resolution of 0.023
volt. The other inputs measure voltages between 0.000 and 4.845 volt, with a
resolution of 0.019 volt. Note that revision 0x00 chips do not support
reading the current voltage of any input except for VIN3; limit setting and
alarms work fine, though. There is code to compute them by iterating.
When an alarm goes off, you can be warned by a beeping signal through
your computer speaker. It is possible to enable all beeping globally,
or only the beeping for some alarms.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once (except for temperature alarms). 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 1.5 seconds since the last update). This means that
you can easily miss once-only alarms.
The GL518SM only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
Iteration Code
--------------
IMPORTANT: For the revision 0x00 chip only,
you may select between three modes to read the vin0-2 inputs with
the following lines in /etc/sensors.conf:
set iterate 0 Don't read in0-in2 inputs.
set iterate 1 Run the iteration loop, this takes up to 10 seconds.
set iterate 2 Show the results of the last iteration loop,
and start a new loop to run in the background.
You may also set the iteration type with
'echo n > /proc/sys/dev/sensors/gl518sm-i2c-x-y/iterate'.
If you have a rev 0x80 chip, the in0-in2 inputs are readable.
In this case, 'iterate' will be read-only and the read value is 3.
This does NOT apply to the Linux 2.6 kernel driver, where the 'iteration'
code was dropped for being too ugly.
Chip Features
-------------
Chip `gl518sm'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
vdd NONE NONE R 2
vin1 NONE NONE R 2
vin2 NONE NONE R 2
vin3 NONE NONE R 2
vdd_min vdd vdd RW 2
vin1_min vin1 vin1 RW 2
vin2_min vin2 vin2 RW 2
vin3_min vin3 vin3 RW 2
vdd_max vdd vdd RW 2
vin1_max vin1 vin1 RW 2
vin2_max vin2 vin2 RW 2
vin3_max vin3 vin3 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
alarms NONE NONE R 0
beep_enable alarms NONE RW 0
beeps alarms alarms RW 0
fan1_off NONE NONE RW 0
fan1_off_pin NONE NONE RW 0
iterate NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
vdd SENSORS_GL518_VDD vdd:3
vin1 SENSORS_GL518_VIN1 vin1:3
vin2 SENSORS_GL518_VIN2 vin2:3
vin3 SENSORS_GL518_VIN3 vin3:3
vdd_min SENSORS_GL518_VDD_MIN vdd:1
vin1_min SENSORS_GL518_VIN1_MIN vin1:1
vin2_min SENSORS_GL518_VIN2_MIN vin2:1
vin3_min SENSORS_GL518_VIN3_MIN vin3:1
vdd_max SENSORS_GL518_VDD_MAX vdd:2
vin1_max SENSORS_GL518_VIN1_MAX vin1:2
vin2_max SENSORS_GL518_VIN2_MAX vin2:2
vin3_max SENSORS_GL518_VIN3_MAX vin3:2
fan1 SENSORS_GL518_FAN1 fan1:2
fan2 SENSORS_GL518_FAN2 fan2:2
fan1_min SENSORS_GL518_FAN1_MIN fan1:1
fan2_min SENSORS_GL518_FAN2_MIN fan2:1
temp SENSORS_GL518_TEMP temp:3
temp_hyst SENSORS_GL518_TEMP_HYST temp:2
temp_over SENSORS_GL518_TEMP_OVER temp:1
fan1_div SENSORS_GL518_FAN1_DIV fan_div:1
fan2_div SENSORS_GL518_FAN2_DIV fan_div:2
alarms SENSORS_GL518_ALARMS alarms:1
beep_enable SENSORS_GL518_BEEP_ENABLE beep:1
beeps SENSORS_GL518_BEEPS beep:2
fan1_off SENSORS_GL518_FAN1OFF fan1off:1
fan1_off_pin SENSORS_GL518_FAN1PIN fan1off:2
iterate SENSORS_GL518_ITERATE iterate:1
doc/chips/gl520sm
-146
View File
@@ -1,146 +0,0 @@
Kernel driver `gl520sm.o'
=========================
Status: Complete but experimental
Supported chips:
* Genesys Logic GL520SM release 0x00
Prefix: 'gl520sm'
Addresses scanned: I2C 0x2c and 0x2d
Datasheet: Not openly available
Author: Frodo Looijaard <frodol@dds.nl>,
Kyösti Mälkki <kmalkki@cc.hut.fi>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This driver supports the Genesys Logic GL520SM chip.
The GL520SM implements one temperature sensor, two fan rotation speed
sensors, four voltage sensors and the cpu VID lines. In addition, one input
can be configured as either a temperature or voltage sensor.
The sensor can report alarms through the computer speakers.
Temperatures are measured in degrees Celsius. An alarm goes off while the
temperature is above the over temperature limit, and has not yet dropped
below the hysteresis limit. The alarm always reflects the current situation.
Measurements are guaranteed between 0 degrees and +110 degrees, with
a resolution of +-3 degrees.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit.
In case when you have selected to turn Fan1 off, no Fan1 alarm is triggered
if measured temperature is below 'over temperature' limit.
Fan readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 1900 RPM.
Voltage sensors (also known as VIN sensors) report their values in volts. 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. The VDD input
measures voltages between 0.000 and 5.865 volt, with a resolution of 0.023
volt. The other inputs measure voltages between 0.000 and 4.845 volt, with a
resolution of 0.019 volt.
When an alarm goes off, you can be warned by a beeping signal through
your computer speaker. It is possible to enable all beeping globally,
or only the beeping for some alarms.
If an alarm triggers, it will remain triggered until the hardware register
is read at least once (except for temperature alarms). 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 1.5 seconds since the last update). This means that
you can easily miss once-only alarms.
The GL520SM only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
Chip Features
-------------
Chip `gl520sm'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
vdd NONE NONE R 2
vin1 NONE NONE R 2
vin2 NONE NONE R 2
vin3 NONE NONE R 2
vin4 NONE NONE R 2
vdd_min vdd vdd RW 2
vin1_min vin1 vin1 RW 2
vin2_min vin2 vin2 RW 2
vin3_min vin3 vin3 RW 2
vin4_min vin4 vin4 RW 2
vdd_max vdd vdd RW 2
vin1_max vin1 vin1 RW 2
vin2_max vin2 vin2 RW 2
vin3_max vin3 vin3 RW 2
vin4_max vin4 vin4 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
temp1 NONE NONE R 1
temp2 NONE NONE R 1
temp1_hyst temp1 temp1 RW 1
temp2_hyst temp2 temp2 RW 1
temp1_over temp1 temp1 RW 1
temp2_over temp2 temp2 RW 1
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
alarms NONE NONE R 0
beep_enable alarms NONE RW 0
beeps alarms alarms RW 0
two_temps NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
vdd SENSORS_GL520_VDD vdd:3
vin1 SENSORS_GL520_VIN1 vin1:3
vin2 SENSORS_GL520_VIN2 vin2:3
vin3 SENSORS_GL520_VIN3 vin3:3
vin4 SENSORS_GL520_VIN4 vin3:3
vdd_min SENSORS_GL520_VDD_MIN vdd:1
vin1_min SENSORS_GL520_VIN1_MIN vin1:1
vin2_min SENSORS_GL520_VIN2_MIN vin2:1
vin3_min SENSORS_GL520_VIN3_MIN vin3:1
vin4_min SENSORS_GL520_VIN4_MIN vin3:1
vdd_max SENSORS_GL520_VDD_MAX vdd:2
vin1_max SENSORS_GL520_VIN1_MAX vin1:2
vin2_max SENSORS_GL520_VIN2_MAX vin2:2
vin3_max SENSORS_GL520_VIN3_MAX vin3:2
vin4_max SENSORS_GL520_VIN4_MAX vin3:2
fan1 SENSORS_GL520_FAN1 fan1:2
fan2 SENSORS_GL520_FAN2 fan2:2
fan1_min SENSORS_GL520_FAN1_MIN fan1:1
fan2_min SENSORS_GL520_FAN2_MIN fan2:1
temp1 SENSORS_GL520_TEMP1 temp1:3
temp2 SENSORS_GL520_TEMP2 temp2:3
temp1_hyst SENSORS_GL520_TEMP1_HYST temp1:2
temp2_hyst SENSORS_GL520_TEMP2_HYST temp2:2
temp1_over SENSORS_GL520_TEMP1_OVER temp1:1
temp2_over SENSORS_GL520_TEMP2_OVER temp2:1
fan1_div SENSORS_GL520_FAN1_DIV fan_div:1
fan2_div SENSORS_GL520_FAN2_DIV fan_div:2
alarms SENSORS_GL520_ALARMS alarms:1
beep_enable SENSORS_GL520_BEEP_ENABLE beep:1
beeps SENSORS_GL520_BEEPS beep:2
two_temps SENSORS_GL520_TWOTEMPS config:1
doc/chips/it87
-273
View File
@@ -1,273 +0,0 @@
Kernel driver `it87.o'
======================
Status: Complete, stable
Supported chips:
* IT8705F
Prefix: 'it87'
Addresses scanned: ISA autodetected
Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/
* IT8712F
Prefix: 'it8712'
Addresses scanned: I2C 0x28 - 0x2f, ISA autodetected
Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/
* SiS950 [clone of IT8705F]
Prefix: 'it87'
Addresses scanned: ISA autodetected
Datasheet: No longer publicly available
Author: Christophe Gauthron
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* update_vbat: integer 0 if vbat should report power on value, 1 if
vbat should be updated after each read. Default is 0.
On some boards the battery voltage is provided by either the battery or
the onboard power supply. Only the first reading at power on will be
the actual battery voltage (which the chip does automatically). On other
boards the battery voltage is always fed to the chip so can be read at
any time. Excessive reading may decrease battery life but no information
is given in the datasheet.
* reset: integer 1 if the registers of the chip should be reset at
module load time, 0 to not reset the registers. Default is 0.
Description
-----------
This driver implements support for the IT8705F, IT8712F and SiS950 chips.
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
joysticks and other miscellaneous stuff. For hardware monitoring,
they include an 'environmnent controller' with 3 temperature sensors,
3 fan rotation speed sensors, 8 voltage sensors, and associated alarms.
The IT8712F additionally features VID inputs.
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts.
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. All voltage
inputs can measure voltages between 0 and 4.08 volts, with a resolution
of 0.016 volt. The battery voltage in8 does not have limit registers.
The VID lines (IT8712F only) 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.
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 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
The IT87xx only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
The sensor type can be set at runtime as of release 2.8.2.
To change sensor N to a thermistor, 'echo 2 > sensorN'
where N is 1, 2, or 3.
To change sensor N to a thermal diode, 'echo 3 > sensorN'.
Give 0 for unused sensor. Any other value is invalid.
To configure this at startup, put the following lines in the it87 section
of /etc/sensors.conf.
(2 = thermistor; 3 = thermal diode; 0 = unused)
set sensor1 3
set sensor2 3
set sensor3 3
If you set a sensor to 0, you'll also want to ignore its value:
ignore tempN
The fan speed control features can be enabled by setting the bits 0-2 of
the fan_ctl register to 1. (Note: bits 6-4 of this register must be set to
1 to enable the fan monitoring).
0x40 : enable fan speed monitoring for fan3
0x20 : enable fan speed monitoring for fan2
0x10 : enable fan speed monitoring for fan1
0x04 : enable fan smart guardian mode for fan3
0x02 : enable fan smart guardian mode for fan2
0x01 : enable fan smart guardian mode for fan1
If a fan's smart guardian bit is not set this fan is in on-off mode.
It can be switched on or off by setting/clearing the corresponding bit 0-2
of the second fan control register fan_on_off. This register has no effect if
a fan is in smart guardian mode.
0x04 : fan3 is on
0x02 : fan2 is on
0x01 : fan1 is on
Bit 7 of the pwm[1-3] registers enables/disables the chip's automatic
temperature control mode for the specified fan. If Bit 7 is set the bits
1 and 0 encode the number of the temperature sensor used for this feature.
Possible register values are:
0x00-0x7f direct power control for the fan speed
0x80 automatic smart guardian mode use temperature sensor 1
0x81 automatic smart guardian mode use temperature sensor 2
0x82 automatic smart guardian mode use temperature sensor 3
In automatic smart guardian mode pwm values for low, medium and high speed
can be set in sg_pwm[1-3]. The temperature limits for fan off, low, medium,
hi speed and over temperature are set in sg_tl[1-3]. While the sensor's
temperature is between the low and medium speed value the fan will run in
low speed. When the sensor's temperature is between the medium and high speed
value the fan spins in medium speed. When the sensor's temperature is between
the high speed and over temperature value the fan spins in high speed.
If the sensor's temperature is higher than the over temperature limit the
fan will spin with the highest possible speed.
Example:
The preconfigured (BIOS set) values of the Shuttle XPC SN41G2 Barebone.
The MB uses temp2 to monitor the CPU temperature and fan3 as the fan for their
special ICE heatpipe cooling system.
$ cat fan_ctl
116
$ cat tan_on_off
215
$ cat pwm3
129
$ cat sg_tl3
16.0 16.0 48.0 54.0 58.0
$ cat sg_pwm3
3 4 9
Explanation:
fan_ctl -> 116 = 0x74 = 01110100 : fan monitoring on for all fans,
and fan3 is in smart guardian mode.
fan_on_off -> 215 = 0xd7 =11010111 : all fans are on this setting is
ignored for fan3 which is in smart guardian mode
pwm3 -> 129 = 0x81 = 10000001 : fan3 is in automatic mode and uses
temp2 for speed control
sg_tl3 -> 16.0 16.0 48.0 54.0 58.0 : off, low, med, high, and
over temperature limits of fan3
sg_pwm3 -> 3 4 9 : pwm values for low, medium and high fan speed of fan3.
Chip features
-------------
Chip `it87`
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 2
in1 NONE NONE R 2
in2 NONE NONE R 2
in3 NONE NONE R 2
in4 NONE NONE R 2
in5 NONE NONE R 2
in6 NONE NONE R 2
in7 NONE NONE R 2
in8 NONE NONE R 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in5_min in5 in5 RW 2
in6_min in6 in6 RW 2
in7_min in6 in6 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
in5_max in5 in5 RW 2
in6_max in6 in6 RW 2
in7_max in6 in6 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan3 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan3_min fan3 fan3 RW 0
temp1 NONE NONE R 1
temp2 NONE NONE R 1
temp3 NONE NONE R 1
temp1_low temp temp RW 1
temp1_over temp temp RW 1
temp2_low temp temp RW 1
temp2_over temp temp RW 1
temp3_low temp temp RW 1
temp3_over temp temp RW 1
vid NONE NONE R 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
fan3_div fan3 NONE R 0
alarms_vin NONE NONE R 0
alarms_fan NONE NONE R 0
alarms_temp NONE NONE R 0
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
in0 SENSORS_IT87_IN0 in0:3
in1 SENSORS_IT87_IN1 in1:3
in2 SENSORS_IT87_IN2 in2:3
in3 SENSORS_IT87_IN3 in3:3
in4 SENSORS_IT87_IN4 in4:3
in5 SENSORS_IT87_IN5 in5:3
in6 SENSORS_IT87_IN6 in6:3
in7 SENSORS_IT87_IN7 in7:3
in0_min SENSORS_IT87_IN0_MIN in0:1
in1_min SENSORS_IT87_IN1_MIN in1:1
in2_min SENSORS_IT87_IN2_MIN in2:1
in3_min SENSORS_IT87_IN3_MIN in3:1
in4_min SENSORS_IT87_IN4_MIN in4:1
in5_min SENSORS_IT87_IN5_MIN in5:1
in6_min SENSORS_IT87_IN6_MIN in6:1
in7_min SENSORS_IT87_IN7_MIN in7:1
in0_max SENSORS_IT87_IN0_MAX in0:2
in1_max SENSORS_IT87_IN1_MAX in1:2
in2_max SENSORS_IT87_IN2_MAX in2:2
in3_max SENSORS_IT87_IN3_MAX in3:2
in4_max SENSORS_IT87_IN4_MAX in4:2
in5_max SENSORS_IT87_IN5_MAX in5:2
in6_max SENSORS_IT87_IN6_MAX in6:2
in7_max SENSORS_IT87_IN7_MAX in7:2
fan1 SENSORS_IT87_FAN1 fan1:2
fan2 SENSORS_IT87_FAN2 fan2:2
fan3 SENSORS_IT87_FAN3 fan3:2
fan1_min SENSORS_IT87_FAN1_MIN fan1:1
fan2_min SENSORS_IT87_FAN2_MIN fan2:1
fan3_min SENSORS_IT87_FAN3_MIN fan3:1
temp1 SENSORS_IT87_TEMP1 temp1:3
temp2 SENSORS_IT87_TEMP2 temp2:3
temp3 SENSORS_IT87_TEMP3 temp3:3
temp1_low SENSORS_IT87_TEMP1_LOW temp1:2
temp1_over SENSORS_IT87_TEMP1_HIGH temp1:1
temp2_low SENSORS_IT87_TEMP2_LOW temp2:2
temp2_over SENSORS_IT87_TEMP2_HIGH temp2:1
temp3_low SENSORS_IT87_TEMP3_LOW temp3:2
temp3_over SENSORS_IT87_TEMP3_HIGH temp3:1
vid SENSORS_IT87_VID vid:1
fan1_div SENSORS_IT87_FAN1_DIV fan_div:1
fan2_div SENSORS_IT87_FAN2_DIV fan_div:2
fan3_div SENSORS_IT87_FAN3_DIV fan_div:3
alarms_fan SENSORS_IT87_ALARMS_FAN alarms_fan:1
alarms_vin SENSORS_IT87_ALARMS_VIN alarms_vin:1
alarms_temp SENSORS_IT87_ALARMS_TEMP alarms_temp:1
doc/chips/lm63
-102
View File
@@ -1,102 +0,0 @@
Kernel driver `lm63.o'
======================
Status: Complete, lightly tested
Supported chips:
* National Semiconductor LM63
Prefix: 'lm63'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM63.html
Author: Jean Delvare <khali@linux-fr.org>
Thanks go to Tyan and especially Alex Buckingham for setting up a remote
access to their S4882 test platform for this driver.
http://www.tyan.com/
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_lm63: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm63' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
Description
-----------
The LM63 is a digital temperature sensor with integrated fan monitoring
and control.
All temperature values are given in degrees Celsius. Resolution is 1.0
degree for the local temperature, 0.125 degree for the remote temperature.
The fan speed is measured using a tachometer. Contrary to most chips which
store the value in an 8-bit register and have a selectable clock divider
to make sure that the result will fit in the register, the LM63 uses 16-bit
value for measuring the speed of the fan. It can measure fan speeds down to
83 RPM, at least in theory.
Note that the pin used for fan monitoring is shared with an alert out
function. Depending on how the board designer wanted to use the chip, fan
speed monitoring will or will not be possible. The proper chip configuration
is left to the BIOS, and the driver will blindly trust it.
A PWM output can be used to control the speed of the fan. The LM63 has two
PWM modes: manual and automatic. Automatic mode is not fully implemented yet
(you cannot define your custom pwm/temperature curve), and mode change isn't
supported either.
The lm63 driver will not update its values more frequently than every
second; reading them more often will do no harm, but will return 'old'
values.
Chip Features
-------------
Chip 'lm63'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp1 - - R- 0
temp1_high temp1 temp1 RW 0
temp2 - - R- 3
temp2_high temp2 temp2 RW 3
temp2_low temp2 temp2 RW 3
temp2_crit temp2 temp2 R- 0
temp2_crit_hyst temp2 temp2 RW 0
fan1 - - R- 0
fan1_low fan1 fan1 RW 0
pwm1 - - RW 0
pwm1_enable pwm1 - R- 0
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp1 SENSORS_LM63_LOCAL_TEMP temp1:2
temp1_high SENSORS_LM63_LOCAL_HIGH temp1:1
temp2 SENSORS_LM63_REMOTE_TEMP temp2:3
temp2_high SENSORS_LM63_REMOTE_HIGH temp2:1
temp2_low SENSORS_LM63_REMOTE_LOW temp2:2
temp2_crit SENSORS_LM63_REMOTE_TCRIT temp2_crit:1
temp2_crit_hyst SENSORS_LM63_REMOTE_TCRIT_HYST temp2_crit_hyst:1
fan1 SENSORS_LM63_FAN fan1:2
fan1_low SENSORS_LM63_FAN_LOW fan1:1
pwm1 SENSORS_LM63_PWM pwm1:1
pwm1_enable SENSORS_LM63_PWM_ENABLE pwm1:2
alarms SENSORS_LM63_ALARMS alarms:1
doc/chips/lm75
-107
View File
@@ -1,107 +0,0 @@
Kernel driver `lm75.o'
=====================
Status: Complete and well-tested
Supported chips:
* National Semiconductor LM75
Prefix: 'lm75'
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 Maxim website
http://www.maxim-ic.com/
* Dallas Semiconductor DS1775
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/
* Maxim MAX6625, MAX6626
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4b
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/
* Microchip (TelCom) TCN75
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Microchip website
http://www.microchip.com/
* Texas Instruments TMP100, TMP101
Prefix: 'lm75'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the TI website
http://www.ti.com/
Author: Frodo Looijaard <frodol@dds.nl>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_lm75: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm75' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
The LM75 implements one temperature sensor. Limits can be set through the
Overtemperature Shutdown register and Hysteresis register. Each value can be
set and read to half-degree accuracy.
An alarm is issued (usually to a connected LM78) when the temperature
gets higher then the Overtemperature Shutdown value; it stays on until
the temperature falls below the Hysteresis value.
All temperatures are in degrees Celsius, and are guaranteed within a
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, MAX6626, and others 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 prefix in the /proc directory is still 'lm75'.
The LM75 is essentially an industry standard; there may be other
LM75 clones not listed here, with or without various enhancements,
that are supported.
The LM77 is not supported, contrary to what we pretended for a long time.
Both chips are simply not compatible, value encoding differs.
Chip Features
-------------
Chip `lm75'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
temp SENSORS_LM75_TEMP temp:3
temp_hyst SENSORS_LM75_TEMP_HYST temp:2
temp_over SENSORS_LM75_TEMP_OVER temp:1
doc/chips/lm78
-337
View File
@@ -1,337 +0,0 @@
Kernel driver `lm78.o'
======================
Status: Complete and well-tested
Supported chips:
* National Semiconductor LM78
Prefix: 'lm78'
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
Datasheet: Publicly available at the National Semiconductor website
* National Semiconductor LM78-J
Prefix: 'lm78-j'
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
Datasheet: Publicly available at the National Semiconductor website
* National Semiconductor LM79
Prefix: 'lm79'
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
Datasheet: Publicly available at the National Semiconductor website
Author: Frodo Looijaard <frodol@dds.nl>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_lm78: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm78' chip
* force_lm78j: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm78j' chip
* force_lm79: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm79' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This driver implements support for the National Semiconductor LM78, LM78-J
and LM79. They are described as `Microprocessor System Hardware Monitors'.
There is almost no difference between the three supported chips. Functionally,
the LM78 and LM78-J are exactly identical. The LM79 has one more VID line,
which is used to report the lower voltages newer Pentium processors use.
From here on, LM7* means either of these three types.
The LM7* implements one temperature sensor, three fan rotation speed sensors,
seven voltage sensors, VID lines, alarms, and some miscellaneous stuff.
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed; it is triggered again
as soon as it drops below the Hysteresis value. A more useful behaviour
can be found by setting the Hysteresis value to +127 degrees Celsius; in
this case, alarms are issued during all the time when the actual temperature
is above the Overtemperature Shutdown value. Measurements are guaranteed
between -55 and +125 degrees, with a resolution of 1 degree.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts.
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. All voltage
inputs can measure voltages between 0 and 4.08 volts, with a resolution
of 0.016 volt.
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. When it is unconnected, you will often find the
value 3.50 V here.
In addition to the alarms described above, there are a couple of additional
ones. There is a BTI alarm, which gets triggered when an external chip has
crossed its limits. Usually, this is connected to all LM75 chips; if at
least one crosses its limits, this bit gets set. The CHAS alarm triggers
if your computer case is open. The FIFO alarms should never trigger; it
indicates an internal error. The SMI_IN alarm indicates some other chip
has triggered an SMI interrupt. As we do not use SMI interrupts at all,
this condition usually indicates there is a problem with some other
device.
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 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
The LM7* only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
Chip features
-------------
Chip `lm78'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 2
in1 NONE NONE R 2
in2 NONE NONE R 2
in3 NONE NONE R 2
in4 NONE NONE R 2
in5 NONE NONE R 2
in6 NONE NONE R 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in5_min in5 in5 RW 2
in6_min in6 in6 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
in5_max in5 in5 RW 2
in6_max in6 in6 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan3 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan3_min fan3 fan3 RW 0
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
vid NONE NONE R 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
fan3_div fan3 NONE R 0
alarms NONE NONE R 0
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
in0 SENSORS_LM78_IN0 in0:3
in1 SENSORS_LM78_IN1 in1:3
in2 SENSORS_LM78_IN2 in2:3
in3 SENSORS_LM78_IN3 in3:3
in4 SENSORS_LM78_IN4 in4:3
in5 SENSORS_LM78_IN5 in5:3
in6 SENSORS_LM78_IN6 in6:3
in0_min SENSORS_LM78_IN0_MIN in0:1
in1_min SENSORS_LM78_IN1_MIN in1:1
in2_min SENSORS_LM78_IN2_MIN in2:1
in3_min SENSORS_LM78_IN3_MIN in3:1
in4_min SENSORS_LM78_IN4_MIN in4:1
in5_min SENSORS_LM78_IN5_MIN in5:1
in6_min SENSORS_LM78_IN6_MIN in6:1
in0_max SENSORS_LM78_IN0_MAX in0:2
in1_max SENSORS_LM78_IN1_MAX in1:2
in2_max SENSORS_LM78_IN2_MAX in2:2
in3_max SENSORS_LM78_IN3_MAX in3:2
in4_max SENSORS_LM78_IN4_MAX in4:2
in5_max SENSORS_LM78_IN5_MAX in5:2
in6_max SENSORS_LM78_IN6_MAX in6:2
fan1 SENSORS_LM78_FAN1 fan1:2
fan2 SENSORS_LM78_FAN2 fan2:2
fan3 SENSORS_LM78_FAN3 fan3:2
fan1_min SENSORS_LM78_FAN1_MIN fan1:1
fan2_min SENSORS_LM78_FAN2_MIN fan2:1
fan3_min SENSORS_LM78_FAN3_MIN fan3:1
temp SENSORS_LM78_TEMP temp:3
temp_hyst SENSORS_LM78_TEMP_HYST temp:2
temp_over SENSORS_LM78_TEMP_OVER temp:1
vid SENSORS_LM78_VID vid:1
fan1_div SENSORS_LM78_FAN1_DIV fan_div:1
fan2_div SENSORS_LM78_FAN2_DIV fan_div:2
fan3_div SENSORS_LM78_FAN3_DIV fan_div:3
alarms SENSORS_LM78_ALARMS alarms:1
Chip `lm78-j'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 2
in1 NONE NONE R 2
in2 NONE NONE R 2
in3 NONE NONE R 2
in4 NONE NONE R 2
in5 NONE NONE R 2
in6 NONE NONE R 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in5_min in5 in5 RW 2
in6_min in6 in6 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
in5_max in5 in5 RW 2
in6_max in6 in6 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan3 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan3_min fan3 fan3 RW 0
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
vid NONE NONE R 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
fan3_div fan3 NONE R 0
alarms NONE NONE R 0
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
in0 SENSORS_LM78J_IN0 in0:3
in1 SENSORS_LM78J_IN1 in1:3
in2 SENSORS_LM78J_IN2 in2:3
in3 SENSORS_LM78J_IN3 in3:3
in4 SENSORS_LM78J_IN4 in4:3
in5 SENSORS_LM78J_IN5 in5:3
in6 SENSORS_LM78J_IN6 in6:3
in0_min SENSORS_LM78J_IN0_MIN in0:1
in1_min SENSORS_LM78J_IN1_MIN in1:1
in2_min SENSORS_LM78J_IN2_MIN in2:1
in3_min SENSORS_LM78J_IN3_MIN in3:1
in4_min SENSORS_LM78J_IN4_MIN in4:1
in5_min SENSORS_LM78J_IN5_MIN in5:1
in6_min SENSORS_LM78J_IN6_MIN in6:1
in0_max SENSORS_LM78J_IN0_MAX in0:2
in1_max SENSORS_LM78J_IN1_MAX in1:2
in2_max SENSORS_LM78J_IN2_MAX in2:2
in3_max SENSORS_LM78J_IN3_MAX in3:2
in4_max SENSORS_LM78J_IN4_MAX in4:2
in5_max SENSORS_LM78J_IN5_MAX in5:2
in6_max SENSORS_LM78J_IN6_MAX in6:2
fan1 SENSORS_LM78J_FAN1 fan1:2
fan2 SENSORS_LM78J_FAN2 fan2:2
fan3 SENSORS_LM78J_FAN3 fan3:2
fan1_min SENSORS_LM78J_FAN1_MIN fan1:1
fan2_min SENSORS_LM78J_FAN2_MIN fan2:1
fan3_min SENSORS_LM78J_FAN3_MIN fan3:1
temp SENSORS_LM78J_TEMP temp:3
temp_hyst SENSORS_LM78J_TEMP_HYST temp:2
temp_over SENSORS_LM78J_TEMP_OVER temp:1
vid SENSORS_LM78J_VID vid:1
fan1_div SENSORS_LM78J_FAN1_DIV fan_div:1
fan2_div SENSORS_LM78J_FAN2_DIV fan_div:2
fan3_div SENSORS_LM78J_FAN3_DIV fan_div:3
alarms SENSORS_LM78J_ALARMS alarms:1
Chip `lm79'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 2
in1 NONE NONE R 2
in2 NONE NONE R 2
in3 NONE NONE R 2
in4 NONE NONE R 2
in5 NONE NONE R 2
in6 NONE NONE R 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in5_min in5 in5 RW 2
in6_min in6 in6 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
in5_max in5 in5 RW 2
in6_max in6 in6 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan3 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan3_min fan3 fan3 RW 0
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
vid NONE NONE R 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
fan3_div fan3 NONE R 0
alarms NONE NONE R 0
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
in0 SENSORS_LM79_IN0 in0:3
in1 SENSORS_LM79_IN1 in1:3
in2 SENSORS_LM79_IN2 in2:3
in3 SENSORS_LM79_IN3 in3:3
in4 SENSORS_LM79_IN4 in4:3
in5 SENSORS_LM79_IN5 in5:3
in6 SENSORS_LM79_IN6 in6:3
in0_min SENSORS_LM79_IN0_MIN in0:1
in1_min SENSORS_LM79_IN1_MIN in1:1
in2_min SENSORS_LM79_IN2_MIN in2:1
in3_min SENSORS_LM79_IN3_MIN in3:1
in4_min SENSORS_LM79_IN4_MIN in4:1
in5_min SENSORS_LM79_IN5_MIN in5:1
in6_min SENSORS_LM79_IN6_MIN in6:1
in0_max SENSORS_LM79_IN0_MAX in0:2
in1_max SENSORS_LM79_IN1_MAX in1:2
in2_max SENSORS_LM79_IN2_MAX in2:2
in3_max SENSORS_LM79_IN3_MAX in3:2
in4_max SENSORS_LM79_IN4_MAX in4:2
in5_max SENSORS_LM79_IN5_MAX in5:2
in6_max SENSORS_LM79_IN6_MAX in6:2
fan1 SENSORS_LM79_FAN1 fan1:2
fan2 SENSORS_LM79_FAN2 fan2:2
fan3 SENSORS_LM79_FAN3 fan3:2
fan1_min SENSORS_LM79_FAN1_MIN fan1:1
fan2_min SENSORS_LM79_FAN2_MIN fan2:1
fan3_min SENSORS_LM79_FAN3_MIN fan3:1
temp SENSORS_LM79_TEMP temp:3
temp_hyst SENSORS_LM79_TEMP_HYST temp:2
temp_over SENSORS_LM79_TEMP_OVER temp:1
vid SENSORS_LM79_VID vid:1
fan1_div SENSORS_LM79_FAN1_DIV fan_div:1
fan2_div SENSORS_LM79_FAN2_DIV fan_div:2
fan3_div SENSORS_LM79_FAN3_DIV fan_div:3
alarms SENSORS_LM79_ALARMS alarms:1
doc/chips/lm80
-149
View File
@@ -1,149 +0,0 @@
Kernel driver `lm80.o'
======================
Status: Complete and tested
Supported chips:
* National Semiconductor LM80
Prefix: 'lm80'
Addresses scanned: I2C 0x20 - 0x2f
Author: Frodo Looijaard <frodol@dds.nl> and Philip Edelbrock
<phil@netroedge.com>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_lm80: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm80' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This driver implements support for the National Semiconductor LM80.
It is descibed as a `Serial Interface ACPI-Compatible Microprocessor
System Hardware Monitor'.
The LM80 implements one temperature sensor, two fan rotation speed sensors,
seven voltage sensors, alarms, and some miscellaneous stuff.
Temperatures are measured in degrees Celsius. There are two sets of limits
which operate independently. When the HOT Temperature Limit is crossed,
this will cause an alarm that will be reasserted until the temperature
drops below the HOT Hysteresis. The Overtemperature Shotdown (OS) limits
should work in the same way (but this must be checked; the datasheet
is unclear about this). Measurements are guaranteed between -55 and
+125 degrees. The current temperature measurement has a resolution of
0.0625 degrees; the limits have a resolution of 1 degree.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage ensors (also known as IN sensors) report their values in volts.
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. All voltage
inputs can measure voltages between 0 and 2.55 volts, with a resolution
of 0.01 volt.
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 LM80 only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
Chip Features
-------------
Chip `lm80'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 2
in1 NONE NONE R 2
in2 NONE NONE R 2
in3 NONE NONE R 2
in4 NONE NONE R 2
in5 NONE NONE R 2
in6 NONE NONE R 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in5_min in5 in5 RW 2
in6_min in6 in6 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
in5_max in5 in5 RW 2
in6_max in6 in6 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan1_min fan1 NONE RW 0
fan2_min fan2 NONE RW 0
temp NONE NONE R 2
temp_hot_hyst temp temp RW 2
temp_hot_max temp temp RW 2
temp_os_hyst temp temp RW 2
temp_os_max temp temp RW 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
alarms NONE NONE R 0
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
in0 SENSORS_LM80_IN0 in0:3
in1 SENSORS_LM80_IN1 in1:3
in2 SENSORS_LM80_IN2 in2:3
in3 SENSORS_LM80_IN3 in3:3
in4 SENSORS_LM80_IN4 in4:3
in5 SENSORS_LM80_IN5 in5:3
in6 SENSORS_LM80_IN6 in6:3
in0_min SENSORS_LM80_IN0_MIN in0:1
in1_min SENSORS_LM80_IN1_MIN in1:1
in2_min SENSORS_LM80_IN2_MIN in2:1
in3_min SENSORS_LM80_IN3_MIN in3:1
in4_min SENSORS_LM80_IN4_MIN in4:1
in5_min SENSORS_LM80_IN5_MIN in5:1
in6_min SENSORS_LM80_IN6_MIN in6:1
in0_max SENSORS_LM80_IN0_MAX in0:2
in1_max SENSORS_LM80_IN1_MAX in1:2
in2_max SENSORS_LM80_IN2_MAX in2:2
in3_max SENSORS_LM80_IN3_MAX in3:2
in4_max SENSORS_LM80_IN4_MAX in4:2
in5_max SENSORS_LM80_IN5_MAX in5:2
in6_max SENSORS_LM80_IN6_MAX in6:2
fan1 SENSORS_LM80_FAN1 fan1:2
fan2 SENSORS_LM80_FAN2 fan2:2
fan1_min SENSORS_LM80_FAN1_MIN fan1:1
fan2_min SENSORS_LM80_FAN2_MIN fan2:1
temp SENSORS_LM80_TEMP temp:5
temp_hot_hyst SENSORS_LM80_TEMP_HOT_HYST temp:2
temp_hot_max SENSORS_LM80_TEMP_HOT_MAX temp:1
temp_os_hyst SENSORS_LM80_TEMP_OS_HYST temp:4
temp_os_max SENSORS_LM80_TEMP_OS_MAX temp:3
fan1_div SENSORS_LM80_FAN1_DIV fan_div:1
fan2_div SENSORS_LM80_FAN2_DIV fan_div:2
alarms SENSORS_LM80_ALARMS alarms:1
doc/chips/lm83
-156
View File
@@ -1,156 +0,0 @@
Kernel driver `lm83.o'
=====================
Status: Complete and lightly tested
Supported chips:
* National Semiconductor LM83
Prefix: 'lm83'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM83.html
* National Semiconductor LM82
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM82.html
Author: Jean Delvare <khali@linux-fr.org>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_lm83: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm83' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
Description
-----------
The LM83 is a digital temperature sensor. It senses its own temperature as
well as the temperature of up to three external diodes. The LM82 is
a stripped down version of the LM83 that only supports one external diode.
Both are compatible with many other devices such as the LM84 and all
other ADM1021 clones. The main difference between the LM83 and the LM84
in that the later can only sense the temperature of one external diode.
Using the adm1021 driver for a LM83 should work, but only two temperatures
will be reported instead of four.
The LM83 is only found on a handful of motherboards. Both a confirmed
list and an unconfirmed list follow. If you can confirm or infirm the
fact that any of these motherboards do actually have an LM83, please
contact us. Note that the LM90 can easily be misdetected as a LM83.
Confirmed motherboards:
SBS P014
SBS PSL09
Unconfirmed motherboards:
Gigabyte GA-8IK1100
Iwill MPX2
Soltek SL-75DRV5
The LM82 is confirmed to have been found on most AMD Geode reference
designs and test platforms.
The driver has been successfully tested by Magnus Forsström, who I'd
like to thank here. More testers will be of course welcome.
The fact that the LM83 is only scarcely used can be easily explained.
Most motherboards come with more than just temperature sensors for
health monitoring. They also have voltage and fan rotation speed
sensors. This means that temperature-only chips are usually used as
secondary chips coupled with another chip such as an IT8705F or similar
chip, which provides more features. Since systems usually need three
temperature sensors (motherboard, processor, power supply) and primary
chips provide some temperature sensors, the secondary chip, if needed,
won't have to handle more than two temperatures. Thus, ADM1021 clones
are sufficent, and there is no need for a four temperatures sensor
chip such as the LM83. The only case where using an LM83 would make
sense is on SMP systems, such as the above-mentioned Iwill MPX2,
because you want an additional temperature sensor for each additional
CPU.
On the SBS P014, this is different, since the LM83 is the only hardware
monitoring chipset. One temperature sensor is used for the motherboard
(actually measuring the LM83's own temperature), one is used for the
CPU. The two other sensors must be used to measure the temperature of
two other points of the motherboard. We suspect these points to be the
north and south bridges, but this couldn't be confirmed.
All temperature values are given in degrees Celsius. Local temperature
is given within a range of 0 to +85 degrees. Remote temperatures are
given within a range of 0 to +125 degrees. Resolution is 1.0 degree,
accuracy is guaranteed to 3.0 degrees (see the datasheet for more
details).
Each sensor has its own high limit, but the critical limit is common to
all four sensors. There is no hysteresis mechanism as found on most
recent temperature sensors.
The lm83 driver will not update its values more frequently than every
other second; reading them more often will do no harm, but will return
'old' values.
Chip Features
-------------
Chip 'lm83'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp1 - - R- 0
temp1_high temp1 temp1 RW 0
temp2 - - R- 0
temp2_high temp2 temp2 RW 0
temp3 - - R- 0
temp3_high temp3 temp3 RW 0
temp4 - - R- 0
temp4_high temp4 temp4 RW 0
tcrit - - RW 0
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp1 SENSORS_LM83_LOCAL_TEMP temp1:2
temp1_high SENSORS_LM83_LOCAL_HIGH temp1:1
temp2 SENSORS_LM83_REMOTE1_TEMP temp2:2
temp2_high SENSORS_LM83_REMOTE1_HIGH temp2:1
temp3 SENSORS_LM83_REMOTE2_TEMP temp3:2
temp3_high SENSORS_LM83_REMOTE2_HIGH temp3:1
temp4 SENSORS_LM83_REMOTE3_TEMP temp4:2
temp4_high SENSORS_LM83_REMOTE3_HIGH temp4:1
tcrit SENSORS_LM83_TCRIT tcrit:1
alarms SENSORS_LM83_ALARMS alarms:1
Chip 'lm82'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp1 - - R- 0
temp1_high temp1 temp1 RW 0
temp3 - - R- 0
temp3_high temp3 temp3 RW 0
tcrit - - RW 0
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp1 SENSORS_LM83_LOCAL_TEMP temp1:2
temp1_high SENSORS_LM83_LOCAL_HIGH temp1:1
temp3 SENSORS_LM83_REMOTE2_TEMP temp3:2
temp3_high SENSORS_LM83_REMOTE2_HIGH temp3:1
tcrit SENSORS_LM83_TCRIT tcrit:1
alarms SENSORS_LM83_ALARMS alarms:1
doc/chips/lm85
-527
View File
@@ -1,527 +0,0 @@
Kernel driver `lm85.o'
======================
Status: Complete and somewhat tested
Supported chips:
* National Semiconductor LM85 (B and C versions)
Prefix: 'lm85'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.national.com/pf/LM/LM85.html
* Analog Devices ADM1027
Prefix: 'adm1027'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.analog.com/en/prod/0,,766_825_ADM1027,00.html
* Analog Devices ADT7463
Prefix: 'adt7463'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.analog.com/en/prod/0,,766_825_ADT7463,00.html
* SMSC EMC6D100, SMSC EMC6D101
Prefix: 'emc6d100'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.smsc.com/main/tools/discontinued/6d100.pdf
* SMSC EMC6D102, SMSC EMC6D101
Prefix: 'emc6d102'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.smsc.com/main/catalog/emc6d102.html
Authors:
Philip Pokorny <ppokorny@penguincomputing.com>
Frodo Looijaard <frodol@dds.nl>
Richard Barrington <rich_b_nz@clear.net.nz>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to assume to be present. Autodetection
of the target device will still be attempted. Use one of the more
specific force directives below if this doesn't detect the device.
* force_lm85b: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm85-B' chip
* force_lm85c: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm85-C' chip
* force_adm1027: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `adm1027' chip
* force_adt7463: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `adt7463' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This driver implements support for the National Semiconductor LM85
and compatible chips including the Analog Devices ADM1027 and ADT7463,
and SMSC EMC6D100, EMC6D101 and EMC6D102.
The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
specification. Using an analog to digital converter it measures three
(3) temperatures and five (5) voltages. It has four (4) 16-bit
counters for measuring fan speed. Five (5) digital inputs are
provided for sampling the VID signals from the processor to the VRM.
Lastly, there are three (3) PWM outputs that can be used to control
fan speed.
The voltage inputs have internal scaling resistors so that the
following voltage can be measured without external resistors:
2.5V, 3.3V, 5V, 12V, and CPU core voltage (2.25V)
The temperatures measured are one internal diode, and two remote
diodes. Remote 1 is generally the CPU temperature. These inputs are
designed to measure a thermal diode like the one in a Pentium 4
processor in a socket 423 or socket 478 package. They can also
measure temperature using a transistor like the 2N3904.
A sophisticated control system for the PWM outputs is designed into
the LM85 that allows fan speed to be adjusted automatically based on
any of the three temperature sensors. Each PWM output is individually
adjustable and programmable. Once configured, the LM85 will adjust
the PWM outputs in response to the measured temperatures without
further host intervention. This feature can also be disabled for
manual control of the PWM's.
Each of the measured inputs (voltage, temperature, fan speed) has
corresponding high/low limit values. The LM85 will signal an ALARM if
any measured value exceeds either limit.
The LM85 samples all inputs continuously. The lm85 driver will not
read the registers more often than once a second. Further, configuration
data is only read once each 5 minutes. There is twice as much config
data as measurements, so this would seem to be a worthwhile
optimization.
Special Features
The LM85 has four fan speed monitoring modes. The ADM1027 has only
two. Both have special circuitry to compensate for PWM interactions
with the TACH signal from the fans. The ADM1027 can be configured to
measure the speed of a two wire fan, but the input conditioning
circuitry is different for 3-wire and 2-wire mode. For this reason,
the 2-wire fan modes are not exposed to user control. The BIOS should
initialize them to the correct mode. If you've designed your own
ADM1027, you'll have to modify the init_client function and add an
insmod parameter to set this up.
To smooth the response of fans to changes in temperature, the LM85 has
an optional filter for smoothing temperatures. The ADM1027 has the
same config option but uses it to rate limit the changes to fan speed
instead. In libsensors, we associate the smoothing feature with a
zone in the LM85 and with a PWM in the ADM1027.
The ADM1027 and ADT7463 have a 10-bit ADC and can therefore measure
temperatures with 0.25 degC resolution. They also provide an offset to
the temperature readings that is automatically applied during
measurement. This offset can be used to zero out any errors due to
traces and placement. The documentation says that the offset is in
0.25 degC steps, but in initial testing of the ADM1027 it was 1.00
degC steps. Analog Devices has confirmed this "bug". The ADT7463 is
reported to work as described in the documentation. Accordingly, the
driver currently reports 1.00 degC steps for the ADM1027 and 0.25 degC
steps for the ADT7463. If you have an ADT7463, please confirm to the
LM85 maintainer that the temperature offset works as implemented.
The ADT7463 has a THERM asserted counter. This counter has a 22.76ms
resolution and a range of 5.8 seconds. The driver implements a 31-bit
accumulator of the counter value to extend the range to over a year.
The counter will stay at it's max value until read. If you want to
insure no counts get lost, you need to trigger the driver to read the
counter every 5 seconds. You can do this by reading just the
therm_signal value. The driver implements reads of 'therm_signal'
without reading the other values for speed. A background shell script
like:
#!/bin/bash
while [ 1 ] ; do
cat /proc/sys/dev/sensors/adt7463-*/therm_signal > /dev/null
sleep 5
done
Or if you want to record the values:
#!/bin/bash
last=0
while [ 1 ] ; do
read tlim total ovfl < /proc/sys/dev/sensors/adt7463-*/therm_signal
if [ $total -gt $last ]; then
echo $(date) - $tlim $total $ovfl
last=$total
fi
sleep 5;
done
Either script should insure no counts are lost.
See the vendor datasheets for more information. There is application
note from National (AN-1260) with some additional information about
the LM85. The Analog Devices datasheet is very detailed and describes
a procedure for determining an optimal configuration for the automatic
PWM control.
Hardware Configurations
-----------------------
The LM85 can be jumpered for 3 different SMBus addresses. There are
no other hardware configuration options for the LM85.
The lm85 driver detects both LM85B and LM85C revisions of the chip.
See the datasheet for a complete description of the differences.
Other than identifying the chip, the driver behaves no differently
with regard to these two chips. The LM85B is recommended for new
designs.
The ADM1027 and ADT7463 chips have an optional SMBALERT output that
can be used to signal the chipset in case a limit is exceeded or the
temperature sensors fail. Individual sensor interrupts can be masked
with 'alarm_mask' so they won't trigger SMBALERT. The SMBALERT output
if configured replaces one of the other functions (PWM2 or IN0). The
driver will print a message if the BIOS has configured this option
when the chip is detected.
The ADT7463 also has an optional THERM output/input which can be
connected to the processor PROC_HOT output. If available, the autofan
control dynamic Tmin feature can be enabled to keep the system
temperature within spec (just?!) with the least possible fan noise.
Configuration Notes
-------------------
The voltage, temperature and fan inputs are available in libsensors
and the sensors executable. In addition, the automatic control of the
PWM outputs can also be configured via sensors.conf. This
configuration is described below:
* Temperatures and Zones
Each temperature sensor is associated with a Zone. There are three
sensors and therefore three zones. Each zone has the following
temperature configuration points:
Limit temp -- Temperature at which the fan will turn on
[ absolute deg C from 0.0 to 127.0 ]
[ sensors.conf: zone#_limit ]
Hysteresis -- Degrees below the limit that fan will remain
on before turning off.
[ relative C from 0.0 to -15.0 ]
[ sensors.conf: zone#_hyst ]
Range -- Degrees above the limit over which the fan
PWM will be adjusted (from PWM_MIN to 100%)
[ relative deg C from 2.0 to 80.0 ]
[ sensors.conf: zone#_range ]
Critical temp -- Temperature above which other fans will be
forced to 100% PWM
[ absolute deg C from 0.0 to 127.0 ]
[ sensors.conf: zone#_critical ]
** Temperature Range for a Zone
The RANGE value for a given zone can have one of 16 different values
in an approximately logrithmic spacing:
Selecting a RANGE not in this list will cause the next larger range to
be used.
Temperature ranges: 2.0, 2.5, 3.3, 4.0, 5.0, 6.6, 8.0, 10.0,
(in deg C) 13.3, 16.0, 20.0, 26.6, 32.0, 40.0, 53.3,
80.0
* Temperature Smoothing or Acoustic Enhancement
The LM85 and ADM1027 use this value in different ways. In the LM85
it's used to filter the temperature input of a zone. In this way, it
affects all PWM's controlled by that zone temperature. In the
ADM1027, it limits the rate of change in fan speed. Thus it is part
of the PWM control algorithm.
Smooth filter -- Optional filter constant to smooth the system
response to temperature spikes. It either
filters the measured temperatures or limits the
rate of change of fan speed. This improves
the system by limiting rapid changes in fan
speed.
[ seconds from 0.8 to 35.0 or 0.0 for OFF ]
[ sensors.conf: zone#_smooth or pwm#_smooth ]
The smoothing can be disabled, or enabled and set to one of the values
listed below. Selecting a filter time constant not on this list will
cause the next smaller value to be used. Setting the time constant to
0 will disable the filtering.
Filter time constant: 35.0, 17.6, 11.8, 7.0, 4.4, 3.0, 1.6, 0.8
(in seconds)
* PWM Control
There are three PWM outputs. The LM85 datasheet suggests that the
pwm3 output control both fan3 and fan4. Each PWM can be individually
configured and assigned to a zone for it's control value. Each PWM can be
configured individually according to the following options.
Spinup time -- When turning on a fan that was off, the PWM will
temporarily be set to 100% for this length of
time to insure the fan starts spinning.
[ seconds from 0.0 to 4.0 ]
[ sensors.conf: pwm#_spinup ]
Minimum PWM -- This is the PWM value at the limit temp of the
referenced zone.
[ PWM value from 0.0 to 255.0 ]
[ sensors.conf: pwm#_min ]
Frequency -- This is the base frequency of the PWM output.
[ Hz from 10.0 to 98.0 ]
[ sensors.conf: pwm#_freq ]
Min/Off flag -- This flag determines if the PWM will be off or
"min PWM" below the limit temperature.
[ 0.0 means PWM off (0%) below limit ]
[ sensors.conf: pwm#_min_ctl ]
Invert flag -- This flag causes the PWM output to be inverted.
If inverted, a PWM setting of 0 will be full on
and 100 will be off.
[ 0.0 means PWM is "normal" ]
[ sensors.conf: pwm#_invert ]
** Spinup Time
Spinup time can be one of eight (8) values. Selecting a spinup time
not on this list will result in the next larger spinup time being
selected. Note, the value 0.2 actually results in a setting of 0.250
seconds.
Spinup Time 0.0, 0.1, 0.2, 0.4, 0.7, 1.0, 2.0, 4.0
(in seconds)
** PWM Frequency
The base frequency of the PWM can be controlled. The frequency can be
set to one of the following 8 values. Setting the frequency to a
value not on this list, will result in the next higher frequency being
selected. The actual device frequency may vary slightly from this
specification as designed by the manufacturer. Consult the datasheet
for more details.
PWM Frequency 10.0, 15.0, 23.0, 30.0, 38.0, 47.0, 62.0, 98.0
(in Hz)
** Min/Off Flag
Below the temperature "Limit - Hysteresis" from the controlling zone,
the PWM can turn off (set to 0) or it can stay at the minimum PWM
value. Setting this flag to 1 will cause the PWM value to be the
"Minimum PWM" value below this limit. Setting it to 0 will set the
PWM to 0 (off) below that limit.
NOTE: It has been reported that there is a bug in the LM85 that causes
the Min/Off flag to be associated with the zones not the PWMs. This
contradicts all the published documentation. Setting pwm#_min_ctl in
this case actually affects all PWMs controlled by zone '#'.
** Invert Flag
The PWM output can be inverted. This may be useful if the fan power
circuitry is inverted. (A low output turns on power and a high output
turns off power to the fan). Alternatively, if a slower fan speed is
needed for higher temperatures, this could be set.
Setting this flag to 1 will invert the PWM output. A value of 0
does not invert the PWM output.
* PWM Controlling Zone selection
PWM's can be controlled by zones according to the following
configuration choices:
Value Meaning
------ ------------------------------------------------
1 Controlled by Zone 1
2 Controlled by Zone 2
3 Controlled by Zone 3
23 Controlled by higher temp of Zone 2 or 3
123 Controlled by highest temp of Zone 1, 2 or 3
0 PWM alwasy 0% (off)
-1 PWM always 100% (full on)
-2 Manual control (write to 'pwm#' to set)
These are specified in sensors.conf using 'pwm#_zone'
* /proc Interface
These values can also be set using the /proc interface. The following
files contain the above settings in the order listed below:
Name Values
---------- ----------------------------------------------------
zone# Limit, Hysteresis, Range, Critical
pwm#_cfg Spinup, PWM at low limit, Frequency, Min/Off, Invert
pwm#_zone Control Zone choice
smooth# Filtering
The National LM85's have two vendor specific configuration
features. Tach. mode and Spinup Control. For more details on these,
see the LM85 datasheet or Application Note AN-1260.
Name Values
------------ --------------------------------------------------
tach_mode For best fan speed measurement when PWM's are in use,
the Tach Mode should be set to 2 for all three (Fan's
3 and 4 share a config setting) config values. If
PWM's are not in use or not wired to control fan
speed, mode 0 or 1 may be better.
[ sensors.conf: fan#_tach_mode ]
spinup_ctl Setting spinup_ctl to 1 will modify the fan spinup
algorithm. Instead of setting the PWM to 100% for
the configured period of time, it will be set to 100%
until the measured RPM is greater than the RPM limit
register or the time period elapses.
[ sensors.conf: pwm#_spinup_ctl ]
The Analog Devices ADM1027 has several vendor specific enhancements.
The number of pulses-per-rev of the fans can be set, Tach monitoring
can be optimized for PWM operation, and an offset can be applied to
the temperatures to compensate for systemic errors in the
measurements.
Name Values
------------ --------------------------------------------------
tach_mode For best fan speed measurement when PWM's are in use,
the Tach Mode should be set to 0. If PWM's are not
in use or not wired to control fan speed, a mode of 1
can be selected. This will also increase the rate
of fan speed measurement from 1 per second to 4 per
second.
[ sensors.conf: fan#_tach_mode ]
fan_ppr You can set the pulses per rev to 1, 2, 3 or 4 so
that fan speeds don't have to be scaled.
[ sensors.conf: fan#_ppr ]
temp#_offset This is the value to be added or subtracted from the
measured temperature before reporting it. This also
affects the PWM control algorithms.
[ sensors.conf: temp#_offset ]
In addition to the ADM1027 features, the ADT7463 also has Tmin control
and THERM asserted counts. Automatic Tmin control acts to adjust the
Tmin value to maintain the measured temperature sensor at a specified
temperature. There isn't much documentation on this feature in the
ADT7463 data sheet. The following values control this feature.
(These are not available via sensors.conf)
Enable Flag -- When set to 1, the Tmin control is enabled. When
set to 0, Tmin will remain unchanged.
[ 1 means Tmin control is enabled ]
[ sensors.conf: none ]
Control Loop -- This value sets the cycle time of the control
loop which adjusts the Tmin value. The mapping
from raw value to loop period is non-linear.
[ Raw value from 0 to 7 (4sec) ]
[ sensors.conf: none ]
Set on THERM -- If enabled, this causes the operating point to be
set from the current temperature when THERM is
asserted. If THERM is connected to a PROC_HOT
signal, this can automatically set the operating
point to the highest value that is within spec.
allowing the lowest/quietest fan speed possible.
[ 1 means set op-point on THERM asserted ]
[ sensors.conf: none ]
Target Temp -- This is the target temperature. Tmin will be
adjusted to keep the measured temperature at this
value.
[ degC -127 to 127 degC ]
[ sensors.conf: none ]
The THERM signal monitoring has three parameters:
THERM Limit -- How long THERM can be asserted before an ALARM is
triggered.
[ 22.7 ms counts ]
[ sensors.conf: none ]
THERM Total -- How long THERM has been asserted since the driver
was loaded.
[ 22.7 ms counts ]
[ sensors.conf: none ]
Overflows -- How many times the THERM counter was read with a
max value indicating it overflowed.
[ count ]
[ sensors.conf: none ]
These values are available via /proc under the following names in the
listed order.
Name Values
------------ --------------------------------------------------
tmin_ctl# Enable, Control Period, Set on THREM, Target
therm_signal Limit, Total, Overflows
* Sample sensors.conf Config File
Here is a sample LM85 chip config for sensors.conf
--------- cut here ---------
chip "lm85c-*" "adm1027-*" "adt7463-*" "lm85-*" "lm85b-*"
# Voltage inputs
label in0 "V1.5" # AGP on Intel S845WD1-E
label in1 "VCore"
label in2 "V3.3"
label in3 "V5"
label in4 "V12"
# Temperature inputs
label temp1 "CPU"
label temp2 "Board"
label temp3 "Remote"
# Fan inputs
label fan1 "CPU_Fan"
label fan2 "Fan2"
label fan3 "Fan3"
label fan4 "Fan4"
# PWM Outputs
label pwm1 "CPU_PWM"
label pwm2 "Fan2_PWM"
label pwm3 "Fan3_PWM"
# Voltage scaling is done on-chip. No 'compute' directive
# should be necessary. If in0 has external scaling set
# it here.
# compute in0 @ * 2.5, @ / 2.5
# Adjust fans speeds for actual pulses per rev
compute fan1 @ * 2, @ / 2 # 1 pulse per rev
# set fan1_ppr 1 # ADM1027 or ADT7463
compute fan2 @ / 2, @ * 2 # 4 pulse per rev
# set fan2_ppr 4 # ADM1027 or ADT7463
# Set VRM version
set vrm 9.1 # Pentium 4
# Set voltage limits
set in0_min 1.5 * 0.95
set in0_max 1.5 * 1.05
set in1_min vid * 0.95
set in1_max vid * 1.05
set in2_min 3.3 * 0.95
set in2_max 3.3 * 1.05
set in3_min 5.0 * 0.95
set in3_max 5.0 * 1.05
set in4_min 12 * 0.95
set in4_max 12 * 1.05
# Set Fan limits
set fan1_min 3000
set fan2_min 3000
set fan3_min 3000
set fan4_min 3000
doc/chips/lm87
-150
View File
@@ -1,150 +0,0 @@
Kernel driver `lm87.o'
======================
Status: Complete and somewhat tested
Supported chips:
* National Semiconductor LM87
Prefix: 'lm87'
Addresses scanned: I2C 0x2c - 0x2e
Datasheet: http://www.national.com/pf/LM/LM87.html
Authors: Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Mark Studebaker <mdsxyz123@yahoo.com>,
and Stephen Rousset <stephen.rousset@rocketlogix.com>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_lm87: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm87' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This driver implements support for the National Semiconductor LM87.
The LM87 implements up to three temperature sensors, up to two fan
rotation speed sensors, up to seven voltage sensors, alarms, and some
miscellaneous stuff.
Temperatures are measured in degrees Celsius. Each input has a high
and low alarm settings. A high limit produces an alarm when the value
goes above it, and an alarm is also produced when the value goes below
the low limit.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in
volts. 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.
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 1.0 second since the last update). This means that you can easily
miss once-only alarms.
The lm87 driver only updates its values each 1.0 seconds; reading it more
often will do no harm, but will return 'old' values.
Hardware Configurations
-----------------------
The LM87 has four pins which can serve one of two possible functions,
depending on the hardware configuration. These pins are:
Vccp2/D2- (pin 17)
+2.5V(IN0)/D2+ (pin 18)
FAN1/AIN1 (pin 5)
FAN2/AIN2 (pin 6)
The most common configuration is to use the values shown here on the
left (Vccp2, 2.5V, FAN1, and FAN2). However, for a third temperature
sensor, it is possible to do away with Vccp2 and 2.5V (IN0) for the
second external temp diode inputs. Strangely, it seems that you can
monitor the core voltage of the second processor or its temperature,
but never both at the same time. Also, either/both FAN1 and FAN2
inputs can be substituted for aux analog inputs AIN1 and/or AIN2,
respectively.
To adjust the driver for a hardware configuration other than the
default, simply uncomment the appropriate #defines in the
kernel/chips/lm87.c driver header, and then recompile/reinstall.
Here is a copy (as of this writing) of the header:
--snip--
/* Chip configuration settings. These should be set to reflect the
HARDWARE configuration of your chip. By default (read: when all of
these are left commented out), this driver assumes that the
configuration is the same as National's defaults for the Channel Mode
register.
Set to '1' the appropriate defines, as nessesary:
- External temp sensors 2 (possible second CPU temp)
This will disable the 2.5V and Vccp2 readings.
Strangely, National decided that you can read the
temperature of a second CPU or its core voltage,
but not both! Comment out if FAULT is reported. */
/* #define LM87_EXT2 1 */
/* Aux analog input. When enabled, the Fan 1 reading
will be disabled */
/* #define LM87_AIN1 1 */
/* Aux analog input 2. When enabled, the Fan 2 reading
will be disabled */
/* #define LM87_AIN2 1 */
/* Internal Vcc is 5V instead of 3.3V */
/* #define LM87_5V_VCC 1 */
/* That's the end of the hardware config defines. I would have made
them insmod params, but it would be too much work. ;') */
--snip--
Please note: Only adjust the #defines to reflect your HARDWARE
configuration. Otherwise some, if not all, the readings will be
wrong. Simply enabling different driver configurations does not
provide the desired readings. You must make hardware changes (which
is hard) if you really wish to get a different set of readings!!
If you may suspect that your configuration may be different than the
default, try enabling the different #defines. If you get a 'FAULT'
when using D2, it is most likely that you don't have a second external
diode, so recomment-out the #define. If you get strange readings for
some/all of the other values when enabling a AIN, then recomment-out
that #define.
Unfortunately, it's tough to 'detect' all hardware config's
automaticly. And, I needed to resort to using #defines instead of
insmod params to make life easier on myself.
doc/chips/lm90
-223
View File
@@ -1,223 +0,0 @@
Kernel driver `lm90.o'
======================
Status: Complete and well tested
Supported chips:
* National Semiconductor LM90
Prefix: 'lm90'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM90.html
* National Semiconductor LM89
Prefix: 'lm99'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/mpf/LM/LM89.html
* National Semiconductor LM99
Prefix: 'lm99'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/pf/LM/LM99.html
* National Semiconductor LM86
Prefix: 'lm86'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the National Semiconductor website
http://www.national.com/mpf/LM/LM86.html
* Analog Devices ADM1032
Prefix: 'adm1032'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the ON Semiconductor website
http://www.onsemi.com/PowerSolutions/product.do?id=ADM1032
* Analog Devices ADT7461
Prefix: 'adt7461'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the ON Semiconductor website
http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461
Note: Only if in ADM1032 compatibility mode
* Maxim MAX6657
Prefix: 'max6657'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
* Maxim MAX6658
Prefix: 'max6657'
Addresses scanned: I2C 0x4c
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
* Maxim MAX6659
Prefix: 'max6657'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the Maxim website
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
Author: Jean Delvare <khali@linux-fr.org>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_lm90: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm90' chip
* force_adm1032: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `adm1032' chip
* force_lm99: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm99' chip
* force_lm86: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm86' chip
* force_max6657: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `max6657' chip
* force_adt7461: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `adt7461' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
Description
-----------
The LM90 is a digital temperature sensor. It senses its own temperature as
well as the temperature of up to one external diode. It is compatible
with many other devices such as the LM86, the LM89, the LM99, the ADM1032,
the MAX6657, the MAX6658, and the MAX6659, all of which are supported by
this driver. Additionally, the ADT7461 is supported if found in ADM1032
compatibility mode.
The specificity of this family of chipsets over the ADM1021/LM84
family is that it features critical limits with hysteresis, and an
increased resolution of the remote temperature measurement.
The different chipsets of the family are not strictly identical, although
very similar. This driver doesn't handle any specific feature for now,
with the exception of SMBus PEC. For reference, here comes a non-exhaustive
list of specific features:
LM90:
* Filter and alert configuration register at 0xBF.
* ALERT is triggered by temperatures over critical limits.
LM86 and LM89:
* Same as LM90
* Better external channel accuracy
LM99:
* Same as LM89
* External temperature shifted by 16 degrees down
ADM1032:
* Consecutive alert register at 0x22.
* Conversion averaging.
* Up to 64 conversions/s.
* ALERT is triggered by open remote sensor.
* SMBus PEC support for Write Byte and Receive Byte transactions.
ADT7461
* Extended temperature range (breaks compatibility)
* Lower resolution for remote temperature
MAX6657 and MAX6658:
* Remote sensor type selecion
MAX6659
* Selectable address
* Second critical temperature limit
All temperature values are given in degrees Celsius. Resolution
is 1.0 degree for the local temperature, 0.125 degree for the remote
temperature.
Each sensor has its own high and low limits, plus a critical limit.
Additionally, there is a relative hysteresis value common to both critical
values. To make life easier to user-space applications, two absolute values
are exported, one for each channel, but these values are of course linked.
Only the local hysteresis can be set from user-space, and the same delta
applies to the remote hysteresis.
The lm90 driver will not update its values more frequently than every
other second; reading them more often will do no harm, but will return
'old' values.
PEC Support
-----------
The ADM1032 is the only chip of the family which supports PEC. It does
not support PEC on all transactions though, so some care must be taken.
When reading a register value, the PEC byte is computed and sent by the
ADM1032 chip. However, in the case of a combined transaction (SMBus Read
Byte), the ADM1032 computes the CRC value over only the second half of
the message rather than its entirety, because it thinks the first half
of the message belongs to a different transaction. As a result, the CRC
value differs from what the SMBus master expects, and all reads fail.
For this reason, the lm90 driver will enable PEC for the ADM1032 only if
the bus supports the SMBus Send Byte and Receive Byte transaction types.
These transactions will be used to read register values, instead of
SMBus Read Byte, and PEC will work properly.
Additionally, the ADM1032 doesn't support SMBus Send Byte with PEC.
Instead, it will try to write the PEC value to the register (because the
SMBus Send Byte transaction with PEC is similar to a Write Byte transaction
without PEC), which is not what we want. Thus, PEC is explicitly disabled
on SMBus Send Byte transactions in the lm90 driver.
PEC on byte data transactions represents a significant increase in bandwidth
usage (+33% for writes, +25% for reads) in normal conditions. With the need
to use two SMBus transaction for reads, this overhead jumps to +50%. Worse,
two transactions will typically mean twice as much delay waiting for
transaction completion, effectively doubling the register cache refresh time.
I guess reliability comes at a price, but it's quite expensive this time.
So, as not everyone might enjoy the slowdown, PEC can be disabled through
procfs. Just write 0 to the "pec" file and PEC will be disabled. Write 1
to that file to enable PEC again.
Chip Features
-------------
Chips 'lm90', adm1032', 'lm99', 'lm86', 'max6657' and 'adt7461'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp1 - - R- 0
temp1_high temp1 temp1 RW 0
temp1_low temp1 temp1 RW 0
temp2 - - R- 1
temp2_high temp2 temp2 RW 1
temp2_low temp2 temp2 RW 1
tcrit1 temp1 temp1 RW 0
tcrit2 temp2 temp2 RW 0
hyst1 temp1 temp1 RW 0
hyst2 temp2 temp2 R- 0
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp1 SENSORS_LM90_LOCAL_TEMP temp1:3
temp1_high SENSORS_LM90_LOCAL_HIGH temp1:1
temp1_low SENSORS_LM90_LOCAL_LOW temp1:2
temp2 SENSORS_LM90_REMOTE_TEMP temp2:3
temp2_high SENSORS_LM90_REMOTE_HIGH temp2:1
temp2_low SENSORS_LM90_REMOTE_LOW temp2:2
tcrit1 SENSORS_LM90_LOCAL_TCRIT tcrit1:1
tcrit2 SENSORS_LM90_REMOTE_TCRIT tcrit2:1
hyst1 SENSORS_LM90_LOCAL_TCRIT_HYST hyst1:1
hyst2 SENSORS_LM90_REMOTE_TCRIT_HYST hyst2:1
alarms SENSORS_LM90_ALARMS alarms:1
doc/chips/lm92
-89
View File
@@ -1,89 +0,0 @@
Kernel driver `lm92.o'
======================
Status: Complete and somewhat tested
Supported chips:
* National Semiconductor LM92
Prefix: 'lm92'
Addresses scanned: I2C 0x48 - 0x4b
* National Semiconductor LM76
Prefix: 'lm92'
Addresses scanned: none, force parameter needed
* Maxim MAX6633/MAX6634/MAX6635
Prefix: 'lm92'
Addresses scanned: I2C 0x48 - 0x4f
MAX6633 with address in 0x40 - 0x47 needs force parameter
Author: Abraham van der Merwe <abraham@2d3d.co.za>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_lm92: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `lm92' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
Description
-----------
This driver implements support for the National Semiconductor LM92
temperature sensor.
Each LM92 temperature sensor supports a single temperature sensor.
Temperatures are exported to proc in degrees Celsius * 10000 (in other
words temperatures are accurate to 4 decimal places). There are alarms
for high, low, and critical thresholds. There's also an hysteresis to
control the thresholds for resetting alarms.
At the moment the driver controls these sensors in comparator mode and the
interrupt pins (INT, T_CRIT_A) are ignored.
Support was added later for the LM76 and Maxim MAX6633/MAX6634/MAX6635,
which are mostly compatible. They have not all been tested, so you
may need to use the force parameter.
Hardware Configurations
-----------------------
The only thing that can be changed is enabling of the fault queue. Doing so
ensures that alarms will only be triggered if 4 consecutive readings all
cross the alarm thresholds. You can enable this behaviour by uncommenting
the #define in the driver source, and then recompile/reinstall.
Chip Features
-------------
Chip 'lm92'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp - - R- 4
temp_high temp temp RW 4
temp_low temp temp RW 4
temp_crit temp temp RW 4
temp_hyst temp temp RW 4
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp SENSORS_LM92_TEMP temp:1
temp_high SENSORS_LM92_TEMP_HIGH temp:2
temp_low SENSORS_LM92_TEMP_LOW temp:3
temp_crit SENSORS_LM92_TEMP_CRIT temp:4
temp_hyst SENSORS_LM92_TEMP_HYST temp:5
alarms SENSORS_LM92_ALARMS alarms:1
doc/chips/lm93
-386
View File
@@ -1,386 +0,0 @@
Kernel driver 'lm93.o'
======================
Status: In progress
Supported chips:
* National Semiconductor LM93
Prefix: 'lm93'
Addresses scanned: I2C 0x2c-0x2e
Author:
Mark M. Hoffman <mhoffman@lightlink.com>
Module Parameters
-----------------
(specific to LM93)
* init: integer
Set to zero to disable some initializations (default is 1)
* disable_block: integer
A "0" allows SMBus block data transactions if the host supports them. A "1"
disables SMBus block data transactions. The default is 0.
* vccp_limit_type: integer array (2)
Configures in7 and in8 limit type, where 0 means absolute and non-zero
means relative. "Relative" here refers to "Dynamic Vccp Monitoring using
VID" from the datasheet. It greatly simplifies the interface to allow
only one set of limits (absolute or relative) to be in operation at a
time (even though the hardware is capable of enabling both). There's
not a compelling use case for enabling both at once, anyway. The default
is "0,0".
* vid_agtl: integer
A "0" configures the VID pins for V(ih) = 2.1V min, V(il) = 0.8V max.
A "1" configures the VID pins for V(ih) = 0.8V min, V(il) = 0.4V max.
(The latter setting is referred to as AGTL+ Compatible in the datasheet.)
I.e. this parameter controls the VID pin input thresholds; if your VID
inputs are not working, trying changing this. The default value is "0".
(common among sensor drivers)
* force: short array (min = 1, max = 48)
List of adapter,address pairs to assume to be present. Autodetection
of the target device will still be attempted. Use one of the more
specific force directives below if this doesn't detect the device.
* force_lm93: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a 'lm93' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Hardware Description
--------------------
(from the datasheet)
The LM93, hardware monitor, has a two wire digital interface compatible with
SMBus 2.0. Using an 8-bit ADC, the LM93 measures the temperature of two remote
diode connected transistors as well as its own die and 16 power supply
voltages. To set fan speed, the LM93 has two PWM outputs that are each
controlled by up to four temperature zones. The fancontrol algorithm is lookup
table based. The LM93 includes a digital filter that can be invoked to smooth
temperature readings for better control of fan speed. The LM93 has four
tachometer inputs to measure fan speed. Limit and status registers for all
measured values are included. The LM93 builds upon the functionality of
previous motherboard management ASICs and uses some of the LM85's features
(i.e. smart tachometer mode). It also adds measurement and control support
for dynamic Vccp monitoring and PROCHOT. It is designed to monitor a dual
processor Xeon class motherboard with a minimum of external components.
User Interface
--------------
#PROCHOT:
The LM93 can monitor two #PROCHOT signals. The results are found in the
/proc files prochot1 and prochot2. There are three values per file: the first
value is the user limit. The second value is the current reading for the
most recent complete time interval. The third value is something like a
2 period exponential moving average (but not quite - check the datasheet).
Note that this third value is calculated by the chip itself. All values
range from 0-255 where 0 indicates no throttling, and 255 indicates > 99.6%.
The monitoring intervals for the two #PROCHOT signals is also configurable.
These intervals can be found in the /proc file prochot_interval. There are
two values in this file: one each for #P1_PROCHOT and #P2_PROCHOT, res-
pectively. Selecting a value not in this list will cause the driver to
use the next largest interval. The available intervals are (in seconds):
#PROCHOT intervals: 0.73, 1.46, 2.9, 5.8, 11.7, 23.3, 46.6, 93.2, 186, 372
It is possible to configure the LM93 to logically short the two #PROCHOT
signals. I.e. when #P1_PROCHOT is asserted, the LM93 will automatically
assert #P2_PROCHOT, and vice-versa. This mode is enabled by writing a
non-zero integer to the /proc file prochot_short.
The LM93 can also override the #PROCHOT pins by driving a PWM signal onto
one or both of them. When overridden, the signal has a period of 3.56 ms,
a minimum pulse width of 5 clocks (at 22.5kHz => 6.25% duty cycle), and
a maximum pulse width of 80 clocks (at 22.5kHz => 99.88% duty cycle).
The /proc file prochot_override has three values. The first two are boolean
integers which enable/disable the override funtion for #P1_PROCHOT and
#P2_PROCHOT, the third value is 0-15 where 0 indicates minimum duty cycle
and 15 indicates maximum.
#VRD_HOT:
The LM93 can monitor two #VRD_HOT signals. The results are found in the
/proc files vrdhot1 and vrdhot2. There is one value per file: a boolean for
which 1 indicates #VRD_HOT is asserted and 0 indicates it is negated. These
files are read-only.
Smart Tach Mode:
(from the datasheet)
If a fan is driven using a low-side drive PWM, the tachometer
output of the fan is corrupted. The LM93 includes smart tachometer
circuitry that allows an accurate tachometer reading to be
achieved despite the signal corruption. In smart tach mode all
four signals are measured within 4 seconds.
Smart tach mode is enabled by the driver by writing 1 or 2 (associating the
the fan tachometer with a pwm) to the /proc file fan<n>_smart_tach. A zero
will disable the function for that fan. Note that Smart tach mode cannot be
enabled if the PWM output frequency is 22500 Hz (see below).
Manual PWM:
The LM93 has a fixed or override mode for the two PWM outputs (although, there
are still some conditions that will override even this mode - see section
15.10.6 of the datasheet for details.) The /proc files pwm1 and pwm2 are
used to enable and control this mode. The first value of the file is an
integer (0-255) where 0 is 0% duty cycle, and 255 is 100%. The second value
is a boolean integer where 0 disables and 1 enables the manual control mode.
Note that the duty cycle values are constrained by the hardware. Selecting
a value which is not available will cause the driver to use the next largest
value. Also note: when manual PWM mode is disabled, the first value of the
/proc files indicates the current duty cycle chosen by the h/w.
PWM Output Frequency:
The LM93 supports several different frequencies for the PWM output channels.
The /proc files pwm1_freq and pwm2_freq are used to select the frequency. The
frequency values are constrained by the hardware. Selecting a value which is
not available will cause the driver to use the next largest value. Also note
that this parameter has implications for the Smart Tach Mode (see above).
PWM Output Frequencies: 12, 36, 48, 60, 72, 84, 96, 22500 Hz (h/w default)
Automatic PWM:
The LM93 is capable of complex automatic fan control, with many different
points of configuration. To start, each PWM output can be bound to any
combination of eight control sources. The final PWM is the largest of all
individual control sources to which the PWM output is bound.
The eight control sources are: temp1-temp4 (aka "zones" in the datasheet),
#PROCHOT 1 & 2, and #VRDHOT 1 & 2. The bindings are expressed as a bitmask
in the /proc files pwm<n>_auto_channels, where a "1" enables the binding, and
a "0" disables it. The h/w default is 0x0f (all temperatures bound).
0x01 - Temp 1
0x02 - Temp 2
0x04 - Temp 3
0x08 - Temp 4
0x10 - #PROCHOT 1
0x20 - #PROCHOT 2
0x40 - #VRDHOT 1
0x80 - #VRDHOT 2
The function y = f(x) takes a source temperature x to a PWM output y. This
function of the LM93 is derived from a base temperature and a table of 12
temperature offsets. The base temperature is expressed in degrees C in the
/proc files temp<n>_auto_base. The offsets are expressed in cumulative
degrees C, with all 12 values in the files temp<n>_auto_offsets. E.g. if the
base temperature is 40C:
offset # temp<n>_auto_offsets range pwm
1 0 - 25.00%
2 0 - 28.57%
3 1 40C - 41C 32.14%
4 1 41C - 42C 35.71%
5 2 42C - 44C 39.29%
6 2 44C - 46C 42.86%
7 2 48C - 50C 46.43%
8 2 50C - 52C 50.00%
9 2 52C - 54C 53.57%
10 2 54C - 56C 57.14%
11 2 56C - 58C 71.43%
12 2 58C - 60C 85.71%
> 60C 100.00%
Valid offsets are in the range 0C <= x <= 7.5C in 0.5C increments.
There is an independent base temperature for each temperature channel. Note,
however, there are only two tables of offsets: one each for temp[12] and
temp[34]. Therefore, any change to e.g. temp1_auto_offsets will also affect
temp2_auto_offsets.
The LM93 can also apply hysteresis to the offset table, to prevent unwanted
oscillation between two steps in the offsets table. These values are found in
the /proc files temp<n>_auto_offset_hyst. There is just one value; it has the
same representation as in temp<n>_auto_offsets.
If a temperature reading falls below the base value for that channel, the LM93
will use the minimum PWM value. These values are found in the /proc files
temp<n>_auto_pwm_min. Note, there are only two minimums: one each for temp[12]
and temp[34]. Therefore, any change to e.g. temp1_auto_pwm_min will also
affect temp2_auto_pwm_min.
PWM Spin-Up Cycle:
A spin-up cycle occurs when a PWM output is commanded from 0% duty cycle to
some value > 0%. The LM93 supports a minimum duty cycle during spin-up. These
values are found in the /proc files pwm<n>_auto_spinup_min. There is one value
per file; it has the same representation as other PWM duty cycle values. The
duration of the spin-up cycle is also configurable. These values are found in
the /proc files pwm<n>_auto_spinup_time. There is one value per file; it is
the spin-up time in seconds. The available spin-up times are constrained by
the hardware. Selecting a value which is not available will cause the driver
to use the next largest value.
Spin-up Durations: 0 (disabled, h/w default), 0.1, 0.25, 0.4, 0.7, 1.0, 2.0, 4.0
#PROCHOT and #VRDHOT PWM Ramping:
If the #PROCHOT or #VRDHOT signals are asserted while bound to a PWM output
channel, the LM93 will ramp the PWM output up to 100% duty cycle in discrete
steps. The duration of each step is configurable. There are two files, with
one value each in seconds: pwm_auto_prochot_ramp and pwm_auto_vrdhot_ramp.
The available ramp times are constrained by the hardware. Selecting a value
which is not available will cause the driver to use the next largest value.
Ramp Times: 0 (disabled, h/w default) to 0.75 in 0.05 second intervals
Fan Boost:
For each temperature channel, there is a boost temperature: if the channel
exceeds this limit, the LM93 will immediately drive both PWM outputs to 100%.
This limit is expressed in degrees C in the /proc files temp<n>_auto_boost.
There is also a hysteresis temperature for this function: after the boost
limit is reached, the temperature channel must drop below this value before
the boost function is disabled. This temperature is also expressed in degrees
C in the /proc files temp<n>_auto_boost_hyst.
GPIO Pins:
The LM93 can monitor the logic level of four dedicated GPIO pins as well as the
four tach input pins. GPIO0-GPIO3 correspond to (fan) tach 1-4, respectively.
All eight GPIOs are read by reading the bitmask in the /proc file gpio. The
LSB is GPIO0, and the MSB is GPIO7.
LM93 Unique /proc Files
-----------------------
file description
-------------------------------------------------------------
prochot<n> limit, current, and moving average #PROCHOT %
prochot_short enable or disable logical #PROCHOT pin short
prochot_override force #PROCHOT assertion as PWM
prochot_interval #PROCHOT PWM sampling interval
vrdhot<n> 0 means negated, 1 means asserted
fan<n>_smart_tach enable or disable smart tach mode
pwm<n>_auto_spinup_min minimum duty cycle during spin-up
pwm<n>_auto_spinup_time duration of spin-up
pwm_auto_prochot_ramp ramp time per step when #PROCHOT asserted
pwm_auto_vrdhot_ramp ramp time per step when #VRDHOT asserted
temp<n>_auto_base temperature channel base
temp<n>_auto_offsets temperature channel offsets
temp<n>_auto_offset_hyst
temperature channel offset hysteresis
temp<n>_auto_boost temperature channel boost (PWMs to 100%) limit
temp<n>_auto_boost_hyst temperature channel boost hysteresis
gpio input state of 8 GPIO pins; read-only
Sample Configuration File
-------------------------
Here is a sample LM93 chip config for sensors.conf:
---------- cut here ----------
chip "lm93-*"
# VOLTAGE INPUTS
# labels and scaling based on datasheet recommendations
label in1 "+12V1"
compute in1 @ * 12.945, @ / 12.945
set in1_min 12 * 0.90
set in1_max 12 * 1.10
label in2 "+12V2"
compute in2 @ * 12.945, @ / 12.945
set in2_min 12 * 0.90
set in2_max 12 * 1.10
label in3 "+12V3"
compute in3 @ * 12.945, @ / 12.945
set in3_min 12 * 0.90
set in3_max 12 * 1.10
label in4 "FSB_Vtt"
label in5 "3GIO"
label in6 "ICH_Core"
label in7 "Vccp1"
label in8 "Vccp2"
label in9 "+3.3V"
set in9_min 3.3 * 0.90
set in9_max 3.3 * 1.10
label in10 "+5V"
set in10_min 5.0 * 0.90
set in10_max 5.0 * 1.10
label in11 "SCSI_Core"
label in12 "Mem_Core"
label in13 "Mem_Vtt"
label in14 "Gbit_Core"
# Assuming R1/R2 = 4.1143, and 3.3V reference
# -12V = (4.1143 + 1) * (@ - 3.3) + 3.3
label in15 "-12V"
compute in15 @ * 5.1143 - 13.57719, (@ + 13.57719) / 5.1143
set in15_min -12 * 0.90
set in15_max -12 * 1.10
label in16 "+3.3VSB"
set in16_min 3.3 * 0.90
set in16_max 3.3 * 1.10
# TEMPERATURE INPUTS
label temp1 "CPU1"
label temp2 "CPU2"
label temp3 "LM93"
# TACHOMETER INPUTS
label fan1 "Fan1"
set fan1_min 3000
label fan2 "Fan2"
set fan2_min 3000
label fan3 "Fan3"
set fan3_min 3000
label fan4 "Fan4"
set fan4_min 3000
# PWM OUTPUTS
label pwm1 "CPU1"
label pwm2 "CPU2"
doc/chips/ltc1710
-67
View File
@@ -1,67 +0,0 @@
Kernel driver `ltc1710.o'
=========================
Status: Complete and well-tested
Supported chips:
* Linear Technologies LTC1710
Prefix: 'ltc1710'
Addresses scanned: I2C 0x58 - 0x5a
Datasheet: Publicly available at the Linear Technologies website
Author: Frodo Looijaard <frodol@dds.nl> and Philip Edelbrock
<phil@netroedge.com>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_ltc1710: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `ltc1710' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This is some documenation for the ltc1710 driver for the Linear
Technologies LTC1710.
The LTC1710 is a simple dual switch device with a SMBus interface. It can
switch a supply voltage to either of its two output pins independantly
from the built-in SMBus interface.
For each sensed LTC1710 there is a directory which looks something like:
ltc1710-i2c-1-59
For each directory there are the following files:
* switch1 (LTC1710_SYSCTL_SWITCH_1)
Simply contains either a 1 or 0 depending on whether the switch is
currently turned on or off.
* switch2 (LTC1710_SYSCTL_SWITCH_2)
Works the same way as switch1, but is for the second switch.
Some notes: The LTC1710 is a *very* simple I2C/SMBus device. It does not
support reads, so the status of the switches isn't polled, but rather
remembered. The LTC1710 has enough 'umph' to drive 300mA with only 0.4 Ohm
impedence (in an 'on' state). This works well for LEDs, or to drive other
devices (MOSFETs and such) which can multiply the switching effect. The
LTC1710 also contains an emergency over-temperature shut-off in the case
of too much current flow. Switch 2 switches the Vcc voltage on/off, but
Switch 1 switches the voltage present on pin 1 (0V to Vcc).
This driver was written and maintained by Philip Edelbrock
<phil@netroedge.com>. Please send comments/suggestions/corrections to him.
For more technical information on the LTC1710, please get the Acrobat PDF
from http://www.linear-tech.com/
doc/chips/matorb
-97
View File
@@ -1,97 +0,0 @@
Kernel driver `matorb.o'
=======================
Status: 'Beta', but it's so simple that it may be in its final state
Supported devices:
* Matrix-Orbital (www.matrix-orbital.com) displays. Developed and
tested on the LCD2041V, but should work with all their displays.
Prefix: 'matorb'
Addresses scanned: I2C 0x2E
Datasheet: Publicly available at the Matrix-Orbital web site
(www.matrix-orbital.com)
Author: Frodo Looijaard <frodol@dds.nl>, and Philip Edelbrock
<phil@netroege.com>
Main Contact: Philip Edelbrock <phil@netroedge.com>
Module Parameters
-----------------
(I'm not positive about these, so don't take this as granite)
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_matorb: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `bt869' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
This driver provides access to the Matrix-Orbital display devices. These
devices are usually in the form of a small LCD (20x4 is typical) screen
which is mounted in a carrier which is then mounted into a 5.25" drive bay
of a computer.
This driver allows the user to send any data to the display to control or
display anything which the display supports.
For more information on the displays or of particular features/command sets
go to:
http://www.matrix-orbital.com
Use
---
To use, just redirect the base-10 ordinal value of bytes (or chars) to the
display. For example, to clear the screen and write a simple message, you
could do this:
# To clear the screen, send byte 0xFE and the char 'X' (ordinal 88)
echo "254 88" > /proc/sys/dev/sensors/matorb*/disp
# To display "hi there"
echo "hi there" \
| perl -e '$_=<STDIN>; while (/(.)/gc) { print ord($1)," "; }' \
> /proc/sys/dev/sensors/matorb*/disp
I've written a simple sample program (in Perl) to display a full screen
of text (which is fed in on standard-input) to the display. It is in the
prog/matorb folder of this project.
I think the displays are very attractive and add a neat sort of 'status'
display to things like servers. It would be very simple to either
make a script daemon (or modify the healthd provided in this project)
to display a current status of health info (voltages, fans, temps, etc.)
on the display. Let's see Windoze do *THAT*! :')
Issues
------
Redirecting too long of a string (32 ordinals seem to be the max) to 'disp'
seems to cause problems. Keep things in small chunks (like lines).
Built in functions (screen clearing, etc.) were initially planned to be
added as other device files (other than just 'disp'), but these functions
are just as easily done by sending the command sequences to disp (as shown
above when clearing the screen). This also ensures that the driver will
be compatible with all the displays.
Detection is very poor (as of this writing, anyway). It looks for a device
at 0x2E and asumes it is a display. Unfortunately, the 'beta' firmware
the Matrix-Orbital people gave me doesn't have good detection abilities to
it (it ignores reads... it used to lock up the bus on reads, so at least
it doesn't do that any more! :'). If they provide an easy way to 'sense'
that it is a display (and what kind it is?) then I will add support for it.
Let me know if you have problems which you can't figure out
(phil@netroedge.com).
doc/chips/max1619
-73
View File
@@ -1,73 +0,0 @@
Kernel driver `max1619.o'
=========================
Status: New
Supported chips:
* Maxim MAX1619
Prefix: 'max1619'
Addresses scanned: I2C 0x18-0x1a, 0x29-0x2b, 0x4c-0x4e
Datasheet: Publicly available at the Maxim website
http://pdfserv.maxim-ic.com/en/ds/MAX1619.pdf
Author: Alexey Fisher <fishor@mail.ru>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_max1619: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `max1619' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
Description
-----------
The MAX1619 is a digital temperature sensor. It senses its own temperature as
well as the temperature of up to one external diode.
All temperature values are given in degrees Celsius. Resolution
is 1.0 degree for the local temperature and for the remote temperature.
Only the external sensor has high and low limits.
The max1619 driver will not update its values more frequently than every
other second; reading them more often will do no harm, but will return
'old' values.
Chip Features
-------------
Chips 'max1619'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp1 - - R- 0
temp2 - - R- 0
temp2_max temp2 temp2 RW 0
temp2_min temp2 temp2 RW 0
temp2_crit temp2 temp2 RW 0
temp2_hyst temp2 temp2 RW 0
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp1 SENSORS_MAX1619_LOCAL_TEMP temp1:1
temp2 SENSORS_MAX1619_REMOTE_TEMP temp2:3
temp2_max SENSORS_MAX1619_REMOTE_HIGH temp2:1
temp2_min SENSORS_MAX1619_REMOTE_LOW temp2:2
temp2_crit SENSORS_MAX1619_REMOTE_HYST temp2_crit:1
temp2_hyst SENSORS_MAX1619_REMOTE_MAX temp2_crit:2
alarms SENSORS_MAX1619_ALARMS alarms:1
doc/chips/max6650
-125
View File
@@ -1,125 +0,0 @@
Sensors chip driver for MAXIM MAX6650 / MAX6651 fan controllers
===============================================================
Chip notes
----------
The MAX6651 is a fan controller. It has two distinct functions:
1) Speed control, with feedback, for a single fan. The code can write
to a register requesting that the fan run at a certain speed, and the
chip will adjust the fan voltage until it reaches that speed. This
is called "closed loop" mode in the datasheet.
2) Speed measurement (tachometers) for up to four fans, including the
controlled one.
The MAX6650 is similar but only has one measurement tachometer.
Both chips have a few general purpose i/o pins, some of which can be
configured to have special functions. At the time of writing an overview
of the chip, with links to the datasheet, can be seen at:
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2296/ln/en
If that has moved searching for MAX6650 from Maxim's home page should
work.
Driver state
------------
Currently the driver provides the following entries in /proc/sys/
dev/sensors/max6650-xxx/:
fan1 through fan4 (read only): the current measured fan speeds, in
rpm.
speed (read/write): when written, sets the chip to closed loop mode and
sets the configured speed, in rpm, to the value written. When read returns
the configured speed, again in rpm.
xdump (read only): returns all of the chip register values, except the
tachometers. Used for debug, and should probably go away or be conditionally
compiled.
The MAX665x uses byte wide registers with various scaling factors and
some more or less complex equations (in the datasheet) relating register
values to real world values. The driver takes care of all of this.
Note that the measured speed ("fan1") never exactly matches the set speed
("speed") because of the coarse resolution of the underlying registers.
Assumptions
-----------
The driver assumes that:
o The MAX665x is running from its internal 254 kHz clock, not an
external clock.
o The monitored fans produce two pulses per rotation (This same
assumption is made by Maxim throughout the datasheet.)
o The tachometer count time (register 0x16) has been configured suitably
for the fans in use, perhaps by some boot code. The driver reads this
register to compute rpm, but never writes to it.
o The speed controller prescale (low three bits of register 0x04) has
been configured suitably for the fans in use, perhaps by some boot
code. The driver reads these bits to compute rpm, but never changes
them.
The driver currently never reads or writes any other configuration
(gpio config, alarms, 5V/12V setting).
Bugs
----
o The driver assumes too much: it should be possible to set more of the
configuration dynamically instead of assuming that some other code has
done it.
o It does not differentiate between a MAX6650 and a MAX6651, as I can
see no obvious way to do this. It has only been tested with a MAX6651
so if anyone gets a board with a MAX6650 to test with maybe something
will be revealed, such as the three missing tachometer registers
returning all ones or something. (OK, so maybe I should have called
this driver max6651, and ignored the max6650 totally...)
o The /proc names don't match the standards in doc/developers/proc,
as this chip doesn't map well to other fan controllers,
Detection notes
---------------
The module will autodetect the presence of a max6650 or max6651 at any
of the four possible I2C addresses for these devices. There is no ID
register, but there are several registers with all zero bits at the
high end. The driver checks that all of these are in fact zero before
declaring the chip to be a MAX6650/1.
sensors-detect
--------------
Support for MAX6650/1 has been added to sensors-detect. It has been
tested as correctly detecting a MAX6651 at I2C address 0x1B. Like the
driver, it cannot yet distinguish a MAX6650 and MAX6651.
prog/sensors
------------
Initial read-only support has been added to the "sensors" program.
Testing
-------
The driver and associated programs have been tested under Linux 2.4.18
running on an embedded Intel XScale processor (actually an IXP425 running
in big-endian mode) with a MAX6651 chip.
Author
------
John Morris (john.morris@spirentcom.com)
doc/chips/maxilife
-433
View File
@@ -1,433 +0,0 @@
Kernel driver `maxilife.o'
==========================
Status: Mostly done and tested
Supported chips:
* Hewlett Packard Maxilife Revision AS 00.01 for Single Pentium II Slot 1
Prefix: 'maxilife-as'
Addresses scanned: I2C 0x10 - 0x14
Datasheet: Only available under NDA
* Hewlett Packard Maxilife Revision CO 00.03 for Dual Xeon Slot 2
Prefix: 'maxilife-co'
Addresses scanned: I2C 0x10 - 0x14
Datasheet: Only available under NDA
* Hewlett Packard Maxilife Revision CG 00.04 for Dual Pentium II Slot 1
Prefix: 'maxilife-cg'
Addresses scanned: I2C 0x10 - 0x14
Datasheet: Only available under NDA
* Hewlett Packard NBA (New BIOS Architecture) for newer machines,
for example Kayak XU800 and XM600.
Prefix: 'maxilife-nba'
Addresses scanned: I2C 0x10 - 0x14
Datasheet: Only available under NDA
Author: Fons Rademakers <Fons.Rademakers@cern.ch>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_maxilife: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `maxilife' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* maxi_version: int
MaxiLife firmware version
Description
-----------
The is the driver for the HP MaxiLife Health monitoring system
as used in the line of HP Kayak Workstation PC's.
The driver supports the following MaxiLife firmware versions:
0) HP KAYAK XU/XAs (Dual Pentium II Slot 1, Deschutes/Klamath)
1) HP KAYAK XU (Dual Xeon [Slot 2] 400/450 Mhz)
2) HP KAYAK XA (Pentium II Slot 1, monoprocessor)
Currently firmware auto detection is not implemented. To use the
driver load it with the correct option for you Kayak. For example:
insmod maxilife.o maxi_version=0 | 1 | 2
maxi_version=0 is the default
The lm75's are indeed accessable in the regular way via the lm75 module.
They worked out of the box. However, I don't use the "raw" lm75 info.
MaxiLife takes care of reading out the lm75's and converts the values to
temperatures. Compared to some of the other monitoring controllers MaxiLife
is quite advanced. It takes care of a lot of issues, like setting ranges,
raising alarms, etc. Machines with MaxiLife also have a little LCD display
on their front (lcd is at address 0x54). The idea is that later versions
of the driver will write health info on the lcd (a bit like lcdproc).
Note
----
sensors-detect does not support recognition of the maxilife chips.
Chip Features
-------------
Chip 'maxilife-as'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
fan1 - - R- 0
fan2 - - R- 0
fan3 - - R- 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan3_min fan3 fan3 RW 0
fan1_div fan1 - R- 0
fan2_div fan2 - R- 0
fan3_div fan3 - R- 0
temp1 - - R- 1
temp2 - - R- 1
temp3 - - R- 1
temp4 - - R- 1
temp5 - - R- 1
temp1_max temp1 temp1 R- 1
temp2_max temp2 temp2 R- 1
temp3_max temp3 temp3 R- 1
temp4_max temp4 temp4 R- 1
temp5_max temp5 temp5 R- 1
temp1_hyst temp1 temp1 R- 1
temp2_hyst temp2 temp2 R- 1
temp3_hyst temp3 temp3 R- 1
temp4_hyst temp4 temp4 R- 1
temp5_hyst temp5 temp5 R- 1
pll - - R- 2
pll_min pll pll RW 2
pll_max pll pll RW 2
vid1 - - R- 4
vid2 - - R- 4
vid3 - - R- 4
vid4 - - R- 4
vid1_min vid1 vid1 RW 4
vid2_min vid2 vid2 RW 4
vid3_min vid3 vid3 RW 4
vid4_min vid4 vid4 RW 4
vid1_max vid1 vid1 RW 4
vid2_max vid2 vid2 RW 4
vid3_max vid3 vid3 RW 4
vid4_max vid4 vid4 RW 4
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
fan1 SENSORS_MAXI_AS_FAN1 fan1:3
fan2 SENSORS_MAXI_AS_FAN2 fan2:3
fan3 SENSORS_MAXI_AS_FAN3 fan3:3
fan1_min SENSORS_MAXI_AS_FAN1_MIN fan1:1
fan2_min SENSORS_MAXI_AS_FAN2_MIN fan2:1
fan3_min SENSORS_MAXI_AS_FAN3_MIN fan3:1
fan1_div SENSORS_MAXI_AS_FAN1_DIV fan1:2
fan2_div SENSORS_MAXI_AS_FAN2_DIV fan2:2
fan3_div SENSORS_MAXI_AS_FAN3_DIV fan3:2
temp1 SENSORS_MAXI_AS_TEMP1 temp1:3
temp2 SENSORS_MAXI_AS_TEMP2 temp2:3
temp3 SENSORS_MAXI_AS_TEMP3 temp3:3
temp4 SENSORS_MAXI_AS_TEMP4 temp4:3
temp5 SENSORS_MAXI_AS_TEMP5 temp5:3
temp1_max SENSORS_MAXI_AS_TEMP1_MAX temp1:1
temp2_max SENSORS_MAXI_AS_TEMP2_MAX temp2:1
temp3_max SENSORS_MAXI_AS_TEMP3_MAX temp3:1
temp4_max SENSORS_MAXI_AS_TEMP4_MAX temp4:1
temp5_max SENSORS_MAXI_AS_TEMP5_MAX temp5:1
temp1_hyst SENSORS_MAXI_AS_TEMP1_HYST temp1:2
temp2_hyst SENSORS_MAXI_AS_TEMP2_HYST temp2:2
temp3_hyst SENSORS_MAXI_AS_TEMP3_HYST temp3:2
temp4_hyst SENSORS_MAXI_AS_TEMP4_HYST temp4:2
temp5_hyst SENSORS_MAXI_AS_TEMP5_HYST temp5:2
pll SENSORS_MAXI_AS_PLL pll:3
pll_min SENSORS_MAXI_AS_PLL_MIN pll:1
pll_max SENSORS_MAXI_AS_PLL_MAX pll:2
vid1 SENSORS_MAXI_AS_VID1 vid1:3
vid2 SENSORS_MAXI_AS_VID2 vid2:3
vid3 SENSORS_MAXI_AS_VID3 vid3:3
vid4 SENSORS_MAXI_AS_VID4 vid4:3
vid1_min SENSORS_MAXI_AS_VID1_MIN vid1:1
vid2_min SENSORS_MAXI_AS_VID2_MIN vid2:1
vid3_min SENSORS_MAXI_AS_VID3_MIN vid3:1
vid4_min SENSORS_MAXI_AS_VID4_MIN vid4:1
vid1_max SENSORS_MAXI_AS_VID1_MAX vid1:2
vid2_max SENSORS_MAXI_AS_VID2_MAX vid2:2
vid3_max SENSORS_MAXI_AS_VID3_MAX vid3:2
vid4_max SENSORS_MAXI_AS_VID4_MAX vid4:2
alarms SENSORS_MAXI_AS_ALARMS alarms:1
Chip 'maxilife-cg'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
fan1 - - R- 0
fan2 - - R- 0
fan3 - - R- 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan3_min fan3 fan3 RW 0
fan1_div fan1 - R- 0
fan2_div fan2 - R- 0
fan3_div fan3 - R- 0
temp1 - - R- 1
temp2 - - R- 1
temp3 - - R- 1
temp4 - - R- 1
temp5 - - R- 1
temp1_max temp1 temp1 R- 1
temp2_max temp2 temp2 R- 1
temp3_max temp3 temp3 R- 1
temp4_max temp4 temp4 R- 1
temp5_max temp5 temp5 R- 1
temp1_hyst temp1 temp1 R- 1
temp2_hyst temp2 temp2 R- 1
temp3_hyst temp3 temp3 R- 1
temp4_hyst temp4 temp4 R- 1
temp5_hyst temp5 temp5 R- 1
pll - - R- 2
pll_min pll pll RW 2
pll_max pll pll RW 2
vid1 - - R- 4
vid2 - - R- 4
vid3 - - R- 4
vid4 - - R- 4
vid1_min vid1 vid1 RW 4
vid2_min vid2 vid2 RW 4
vid3_min vid3 vid3 RW 4
vid4_min vid4 vid4 RW 4
vid1_max vid1 vid1 RW 4
vid2_max vid2 vid2 RW 4
vid3_max vid3 vid3 RW 4
vid4_max vid4 vid4 RW 4
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
fan1 SENSORS_MAXI_CG_FAN1 fan1:3
fan2 SENSORS_MAXI_CG_FAN2 fan2:3
fan3 SENSORS_MAXI_CG_FAN3 fan3:3
fan1_min SENSORS_MAXI_CG_FAN1_MIN fan1:1
fan2_min SENSORS_MAXI_CG_FAN2_MIN fan2:1
fan3_min SENSORS_MAXI_CG_FAN3_MIN fan3:1
fan1_div SENSORS_MAXI_CG_FAN1_DIV fan1:2
fan2_div SENSORS_MAXI_CG_FAN2_DIV fan2:2
fan3_div SENSORS_MAXI_CG_FAN3_DIV fan3:2
temp1 SENSORS_MAXI_CG_TEMP1 temp1:3
temp2 SENSORS_MAXI_CG_TEMP2 temp2:3
temp3 SENSORS_MAXI_CG_TEMP3 temp3:3
temp4 SENSORS_MAXI_CG_TEMP4 temp4:3
temp5 SENSORS_MAXI_CG_TEMP5 temp5:3
temp1_max SENSORS_MAXI_CG_TEMP1_MAX temp1:1
temp2_max SENSORS_MAXI_CG_TEMP2_MAX temp2:1
temp3_max SENSORS_MAXI_CG_TEMP3_MAX temp3:1
temp4_max SENSORS_MAXI_CG_TEMP4_MAX temp4:1
temp5_max SENSORS_MAXI_CG_TEMP5_MAX temp5:1
temp1_hyst SENSORS_MAXI_CG_TEMP1_HYST temp1:2
temp2_hyst SENSORS_MAXI_CG_TEMP2_HYST temp2:2
temp3_hyst SENSORS_MAXI_CG_TEMP3_HYST temp3:2
temp4_hyst SENSORS_MAXI_CG_TEMP4_HYST temp4:2
temp5_hyst SENSORS_MAXI_CG_TEMP5_HYST temp5:2
pll SENSORS_MAXI_CG_PLL pll:3
pll_min SENSORS_MAXI_CG_PLL_MIN pll:1
pll_max SENSORS_MAXI_CG_PLL_MAX pll:2
vid1 SENSORS_MAXI_CG_VID1 vid1:3
vid2 SENSORS_MAXI_CG_VID2 vid2:3
vid3 SENSORS_MAXI_CG_VID3 vid3:3
vid4 SENSORS_MAXI_CG_VID4 vid4:3
vid1_min SENSORS_MAXI_CG_VID1_MIN vid1:1
vid2_min SENSORS_MAXI_CG_VID2_MIN vid2:1
vid3_min SENSORS_MAXI_CG_VID3_MIN vid3:1
vid4_min SENSORS_MAXI_CG_VID4_MIN vid4:1
vid1_max SENSORS_MAXI_CG_VID1_MAX vid1:2
vid2_max SENSORS_MAXI_CG_VID2_MAX vid2:2
vid3_max SENSORS_MAXI_CG_VID3_MAX vid3:2
vid4_max SENSORS_MAXI_CG_VID4_MAX vid4:2
alarms SENSORS_MAXI_CG_ALARMS alarms:1
Chip 'maxilife-co'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
fan1 - - R- 0
fan2 - - R- 0
fan3 - - R- 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan3_min fan3 fan3 RW 0
fan1_div fan1 - R- 0
fan2_div fan2 - R- 0
fan3_div fan3 - R- 0
temp1 - - R- 1
temp2 - - R- 1
temp3 - - R- 1
temp4 - - R- 1
temp5 - - R- 1
temp1_max temp1 temp1 R- 1
temp2_max temp2 temp2 R- 1
temp3_max temp3 temp3 R- 1
temp4_max temp4 temp4 R- 1
temp5_max temp5 temp5 R- 1
temp1_hyst temp1 temp1 R- 1
temp2_hyst temp2 temp2 R- 1
temp3_hyst temp3 temp3 R- 1
temp4_hyst temp4 temp4 R- 1
temp5_hyst temp5 temp5 R- 1
pll - - R- 2
pll_min pll pll RW 2
pll_max pll pll RW 2
vid1 - - R- 4
vid2 - - R- 4
vid3 - - R- 4
vid4 - - R- 4
vid1_min vid1 vid1 RW 4
vid2_min vid2 vid2 RW 4
vid3_min vid3 vid3 RW 4
vid4_min vid4 vid4 RW 4
vid1_max vid1 vid1 RW 4
vid2_max vid2 vid2 RW 4
vid3_max vid3 vid3 RW 4
vid4_max vid4 vid4 RW 4
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
fan1 SENSORS_MAXI_CO_FAN1 fan1:3
fan2 SENSORS_MAXI_CO_FAN2 fan2:3
fan3 SENSORS_MAXI_CO_FAN3 fan3:3
fan1_min SENSORS_MAXI_CO_FAN1_MIN fan1:1
fan2_min SENSORS_MAXI_CO_FAN2_MIN fan2:1
fan3_min SENSORS_MAXI_CO_FAN3_MIN fan3:1
fan1_div SENSORS_MAXI_CO_FAN1_DIV fan1:2
fan2_div SENSORS_MAXI_CO_FAN2_DIV fan2:2
fan3_div SENSORS_MAXI_CO_FAN3_DIV fan3:2
temp1 SENSORS_MAXI_CO_TEMP1 temp1:3
temp2 SENSORS_MAXI_CO_TEMP2 temp2:3
temp3 SENSORS_MAXI_CO_TEMP3 temp3:3
temp4 SENSORS_MAXI_CO_TEMP4 temp4:3
temp5 SENSORS_MAXI_CO_TEMP5 temp5:3
temp1_max SENSORS_MAXI_CO_TEMP1_MAX temp1:1
temp2_max SENSORS_MAXI_CO_TEMP2_MAX temp2:1
temp3_max SENSORS_MAXI_CO_TEMP3_MAX temp3:1
temp4_max SENSORS_MAXI_CO_TEMP4_MAX temp4:1
temp5_max SENSORS_MAXI_CO_TEMP5_MAX temp5:1
temp1_hyst SENSORS_MAXI_CO_TEMP1_HYST temp1:2
temp2_hyst SENSORS_MAXI_CO_TEMP2_HYST temp2:2
temp3_hyst SENSORS_MAXI_CO_TEMP3_HYST temp3:2
temp4_hyst SENSORS_MAXI_CO_TEMP4_HYST temp4:2
temp5_hyst SENSORS_MAXI_CO_TEMP5_HYST temp5:2
pll SENSORS_MAXI_CO_PLL pll:3
pll_min SENSORS_MAXI_CO_PLL_MIN pll:1
pll_max SENSORS_MAXI_CO_PLL_MAX pll:2
vid1 SENSORS_MAXI_CO_VID1 vid1:3
vid2 SENSORS_MAXI_CO_VID2 vid2:3
vid3 SENSORS_MAXI_CO_VID3 vid3:3
vid4 SENSORS_MAXI_CO_VID4 vid4:3
vid1_min SENSORS_MAXI_CO_VID1_MIN vid1:1
vid2_min SENSORS_MAXI_CO_VID2_MIN vid2:1
vid3_min SENSORS_MAXI_CO_VID3_MIN vid3:1
vid4_min SENSORS_MAXI_CO_VID4_MIN vid4:1
vid1_max SENSORS_MAXI_CO_VID1_MAX vid1:2
vid2_max SENSORS_MAXI_CO_VID2_MAX vid2:2
vid3_max SENSORS_MAXI_CG_VID3_MAX vid3:2
vid4_max SENSORS_MAXI_CO_VID4_MAX vid4:2
alarms SENSORS_MAXI_CO_ALARMS alarms:1
Chip 'maxilife-nba'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
fan1 - - R- 0
fan2 - - R- 0
fan3 - - R- 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
fan3_min fan3 fan3 RW 0
fan1_div fan1 - R- 0
fan2_div fan2 - R- 0
fan3_div fan3 - R- 0
temp1 - - R- 1
temp2 - - R- 1
temp3 - - R- 1
temp4 - - R- 1
temp5 - - R- 1
temp1_max temp1 temp1 R- 1
temp2_max temp2 temp2 R- 1
temp3_max temp3 temp3 R- 1
temp4_max temp4 temp4 R- 1
temp5_max temp5 temp5 R- 1
temp1_hyst temp1 temp1 R- 1
temp2_hyst temp2 temp2 R- 1
temp3_hyst temp3 temp3 R- 1
temp4_hyst temp4 temp4 R- 1
temp5_hyst temp5 temp5 R- 1
pll - - R- 2
pll_min pll pll RW 2
pll_max pll pll RW 2
vid1 - - R- 4
vid2 - - R- 4
vid3 - - R- 4
vid4 - - R- 4
vid1_min vid1 vid1 RW 4
vid2_min vid2 vid2 RW 4
vid3_min vid3 vid3 RW 4
vid4_min vid4 vid4 RW 4
vid1_max vid1 vid1 RW 4
vid2_max vid2 vid2 RW 4
vid3_max vid3 vid3 RW 4
vid4_max vid4 vid4 RW 4
alarms - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
fan1 SENSORS_MAXI_AS_FAN1 fan1:3
fan2 SENSORS_MAXI_AS_FAN2 fan2:3
fan3 SENSORS_MAXI_AS_FAN3 fan3:3
fan1_min SENSORS_MAXI_AS_FAN1_MIN fan1:1
fan2_min SENSORS_MAXI_AS_FAN2_MIN fan2:1
fan3_min SENSORS_MAXI_AS_FAN3_MIN fan3:1
fan1_div SENSORS_MAXI_AS_FAN1_DIV fan1:2
fan2_div SENSORS_MAXI_AS_FAN2_DIV fan2:2
fan3_div SENSORS_MAXI_AS_FAN3_DIV fan3:2
temp1 SENSORS_MAXI_AS_TEMP1 temp1:3
temp2 SENSORS_MAXI_AS_TEMP2 temp2:3
temp3 SENSORS_MAXI_AS_TEMP3 temp3:3
temp4 SENSORS_MAXI_AS_TEMP4 temp4:3
temp5 SENSORS_MAXI_AS_TEMP5 temp5:3
temp1_max SENSORS_MAXI_AS_TEMP1_MAX temp1:1
temp2_max SENSORS_MAXI_AS_TEMP2_MAX temp2:1
temp3_max SENSORS_MAXI_AS_TEMP3_MAX temp3:1
temp4_max SENSORS_MAXI_AS_TEMP4_MAX temp4:1
temp5_max SENSORS_MAXI_AS_TEMP5_MAX temp5:1
temp1_hyst SENSORS_MAXI_AS_TEMP1_HYST temp1:2
temp2_hyst SENSORS_MAXI_AS_TEMP2_HYST temp2:2
temp3_hyst SENSORS_MAXI_AS_TEMP3_HYST temp3:2
temp4_hyst SENSORS_MAXI_AS_TEMP4_HYST temp4:2
temp5_hyst SENSORS_MAXI_AS_TEMP5_HYST temp5:2
pll SENSORS_MAXI_AS_PLL pll:3
pll_min SENSORS_MAXI_AS_PLL_MIN pll:1
pll_max SENSORS_MAXI_AS_PLL_MAX pll:2
vid1 SENSORS_MAXI_AS_VID1 vid1:3
vid2 SENSORS_MAXI_AS_VID2 vid2:3
vid3 SENSORS_MAXI_AS_VID3 vid3:3
vid4 SENSORS_MAXI_AS_VID4 vid4:3
vid1_min SENSORS_MAXI_AS_VID1_MIN vid1:1
vid2_min SENSORS_MAXI_AS_VID2_MIN vid2:1
vid3_min SENSORS_MAXI_AS_VID3_MIN vid3:1
vid4_min SENSORS_MAXI_AS_VID4_MIN vid4:1
vid1_max SENSORS_MAXI_AS_VID1_MAX vid1:2
vid2_max SENSORS_MAXI_AS_VID2_MAX vid2:2
vid3_max SENSORS_MAXI_AS_VID3_MAX vid3:2
vid4_max SENSORS_MAXI_AS_VID4_MAX vid4:2
alarms SENSORS_MAXI_AS_ALARMS alarms:1
doc/chips/mic74
-57
View File
@@ -1,57 +0,0 @@
Kernel driver `mic74.o'
=========================
Status: Beta
Supported chips:
* Micrel MIC74
Prefix: 'mic74'
Addresses scanned: I2C 0x20 - 0x27
Datasheet: Publicly available at the Micrel website
http://www.micrel.com/
Authors: zebo25
mds (cleanups and this doc)
Module Parameters
-----------------
Description
-----------
The MIC74 is an 8-bit I/O expander for the I2C bus.
Semiconductors. It is designed to provide a byte I2C interface to up to 8
separate devices.
This device consists of a quasi-bidirectionnal port. Each of the eight I/Os
can be independently used as an input or output.
The driver does not initialize the ports, they will be at their
power-up defaults, or however the BIOS programmed them.
For more information see the datasheet.
Accessing MIC74 via /proc interface
-------------------------------------
! Be careful !
The chip is plainly impossible to detect ! Stupid chip.
So every chip with adress in the interval [20..27] could be
detected as an MIC74 or a PCF8574. Don't load both drivers.
If you have other chips in this address
range, the workaround is to load this module after the one
for your others chips.
On detection, directories are created for each detected chip:
/proc/sys/dev/sensors/mic74-<0>-<1>/
where <0> is the bus the chip was detected on (e. g. i2c-0)
and <1> the chip address [20..27]:
./mic74-i2c-0-27/
Inside these directories, there are seven files each,
one for each of the seven registers in the device.
At this point you really need the datasheet.
It should be self-explanatory which file is for which register.
doc/chips/mtp008
-73
View File
@@ -1,73 +0,0 @@
Kernel driver `mtp008.o'
=========================
Status: Complete; Beta.
This chip is quite configurable and many settings cannot
be done through the driver. Hopefully the BIOS settings will
be correct for most motherboards.
Supported chips:
* Myson MTP008
Prefix: 'mtp008'
Addresses scanned: I2C 0x2c - 0x2e
Datasheet: Publicly available at the Myson website
Author: Kris Van Hees <aedil@alchar.org>
Description
-----------
The Myson MTP008 is similar in function to the Winbond W83781D and the
National Semi LM78. See documentation for those chips for an overview.
The MTP008 chip has several pins that are configurable.
The three temperature sensors are configurable via the driver
using either the /proc entries or 'set sensorx y' statements in
/etc/sensors.conf.
One temperature input is always temp1, and the sensor type is configured
with the sensor1 entry in /proc.
One input is either in4 or temp2, and is configured with the sensor2 entry.
One input is either in5 or temp3, and is configured with the sensor3 entry.
For example, on the Tyan S1824D motherboard,
AIN4 is configured as PII temp sensor 2 and
AIN5 is hooked up to the -12V sensing circuit.
Other Tyan motherboards (the 2510 Thunder and the Tiger 200) appear to
have different configurations.
For the 2510, which has two MTP008 chips, each with a different
configuration, follow the instructions in the mtp008 section of
etc/sensors.conf.eg to configure 'sensors' correctly.
The PWM outputs are configurable via the driver.
PWM values are from 0 to 255. The first value in the /proc entry is
the pwm value; the second is the enable (0 or 1).
The fan3 and pwm1 functions share a pin.
If pwm1 is enabled than fan3 will read as 0.
The Fan input types (2 wire or 3 wire) are configurable but
not via the driver.
The driver now preserves pin settings that the BIOS configures.
If your BIOS did it right then the driver should work great.
The MTP008 has sensor type selection in /proc like the Winbond W83782D.
However, the appropriate values used to make the selection are different.
To select a sensor type, echo the value to the /proc entry, for example:
echo 1 > /proc/sys/dev/sensors/mtp008-i2c-0-2d/sensor1
Or, use /etc/sensors.conf and add a line 'set sensor1 1', for example.
Hopefully the BIOS has set these already.
Sensor selection is as follows:
Value Function Valid on sensors
----- -------- ----------------
1 Analog input (not for temperature sensing) 2,3
2 Thermistor 1,2,3
3 Pentium diode 1,2
doc/chips/pc87360
-179
View File
@@ -1,179 +0,0 @@
Kernel driver `pc87360.o'
=========================
Status: Beta, PC87366 well tested, other chips untested.
Supported chips:
* National Semiconductor PC87360, PC87363, PC87364, PC87365 and PC87366
Addresses scanned: none, address read from Super I/O config space
Prefixes: 'pc87360', 'pc87363', 'pc87364', 'pc87365', 'pc87366'
Datasheets: No longer available
Authors: Jean Delvare <khali@linux-fr.org>
Thanks to Sandeep Mehta, Tonko de Rooy and Daniel Ceregatti for testing.
Thanks to Rudolf Marek for helping me investigate conversion issues.
Module Parameters
-----------------
init (int):
Chip initialization level:
0: None
*1: Forcibly enable internal voltage and temperature channels, except in9
2: Forcibly enable all voltage and temperature channels, except in9
3: Forcibly enable all voltage and temperature channels, including in9
Note that this parameter has no effect for the PC87360, PC87363 and PC87364
chips.
Also note that for the PC87366, initialization levels 2 and 3 don't enable
all temperature channels, because some of them share pins with each other,
so they can't be used at the same time.
Description
-----------
The National Semiconductor PC87360 Super I/O chip contains monitoring and
PWM control circuitry for two fans. The PC87363 chip is similar, and the
PC87364 chip has monitoring and PWM control for a third fan.
The National Semiconductor PC87365 and PC87366 Super I/O chips are complete
hardware monitoring chipsets, not only controling and monitoring three fans,
but also monitoring eleven voltage inputs and two (PC87365) or up to four
(PC87366) temperatures.
The driver assumes that no more than one chip is present, and one of the
standard Super I/O addresses is used (0x2E/0x2F or 0x4E/0x4F).
Fan Monitoring
--------------
Fan rotation speeds are reported in RPM (revolutions per minute). An alarm
is triggered if the rotation speed has dropped below a programmable limit.
A different alarm is triggered if the fan speed is too low to be measured.
Fan readings are affected by a programmable clock divider, giving the
readings more range or accuracy. Usually, users have to learn how it works,
but this driver implements dynamic clock divider selection, so you don't
have to care no more.
For reference, here are a few values about clock dividers:
slowest accuracy highest
measurable around 3000 accurate
divider speed (RPM) RPM (RPM) speed (RPM)
1 1882 18 6928
2 941 37 4898
4 470 74 3464
8 235 150 2449
For the curious, here is how the values above were computed:
* slowest measurable speed: clock/(255*divider)
* accuracy around 3000 RPM: 3000^2/clock
* highest accurate speed: sqrt(clock*100)
The clock speed for the PC87360 family is 480 kHz. I arbitrarily chose 100
RPM as the lowest acceptable accuracy.
As mentioned above, you don't have to care about this no more.
Note that not all RPM values can be represented, even when the best clock
divider is selected. This is not only true for the measured speeds, but
also for the programmable low limits, so don't be surprised if you try to
set, say, fan1_min to 2900 and it finaly reads 2909.
Fan Control
-----------
PWM (pulse width modulation) values range from 0 to 255, with 0 meaning
that the fan is stopped, and 255 meaning that the fan goes at full speed.
Be extremely careful when changing PWM values. Low PWM values, even
non-zero, can stop the fan, which may cause irreversible damage to your
hardware if temperature increases too much. When changing PWM values, go
step by step and keep an eye on temperatures.
One user reported problems with PWM. Changing PWM values would break fan
speed readings. No explanation nor fix could be found.
Temperature Monitoring
----------------------
Temperatures are reported in degrees Celsius. Each temperature measured has
associated low, high and overtemperature limits, each of which triggers an
alarm when crossed.
The first two temperature channels are external. The third one (PC87366
only) is internal.
The PC87366 has three additional temperature channels, based on
thermistors (as opposed to thermal diodes for the first three temperature
channels). For technical reasons, these channels are held by the VLM
(voltage level monitor) logical device, not the TMS (temperature
measurement) one. As a consequence, these temperatures are exported as
voltages, and converted into temperatures in user-space.
Note that these three additional channels share their pins with the
external thermal diode channels, so you (physically) can't use them all at
the same time. Although it should be possible to mix the two sensor types,
the documents from National Semiconductor suggest that motherboard
manufacturers should choose one type and stick to it. So you will more
likely have either channels 1 to 3 (thermal diodes) or 3 to 6 (internal
thermal diode, and thermistors).
Voltage Monitoring
------------------
Voltages are reported relatively to a reference voltage, either internal or
external. Some of them (in7:Vsb, in8:Vdd and in10:AVdd) are divided by two
internally, you will have to compensate in sensors.conf. Others (in0 to in6)
are likely to be divided externally. The meaning of each of these inputs as
well as the values of the resistors used for division is left to the
motherboard manufacturers, so you will have to document yourself and edit
sensors.conf accordingly. National Semiconductor has a document with
recommended resistor values for some voltages, but this still leaves much
room for per motherboard specificities, unfortunately. Even worse,
motherboard manufacturers don't seem to care about National Semiconductor's
recommendations.
Each voltage measured has associated low and high limits, each of which
triggers an alarm when crossed.
When available, VID inputs are used to provide the nominal CPU Core voltage.
The driver will default to VRM 9.0, but this can be changed from user-space.
The chipsets can handle two sets of VID inputs (on dual-CPU systems), but
the driver will only export one for now. This may change later if there is
a need.
General Remarks
---------------
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 all hardware registers are read whenever any
data is read (unless it is less than 2 seconds since the last update, in
which case cached values are returned instead). As a consequence, when
a once-only alarm triggers, it may take 2 seconds for it to show, and 2
more seconds for it to disappear.
Monitoring of in9 isn't enabled at lower init levels (<3) because that
channel measures the battery voltage (Vbat). It is a known fact that
repeatedly sampling the battery voltage reduces its lifetime. National
Semiconductor smartly designed their chipset so that in9 is sampled only
once every 1024 sampling cycles (that is every 34 minutes at the default
sampling rate), so the effect is attenuated, but still present.
Limitations
-----------
The datasheets suggests that some values (fan mins, fan dividers)
shouldn't be changed once the monitoring has started, but we ignore that
recommendation. We'll reconsider if it actually causes trouble.
doc/chips/pca9540
-76
View File
@@ -1,76 +0,0 @@
Kernel driver `pca9540.o'
=========================
Status: Complete but untested
Supported chips:
* Philips PCA9540
Prefix: 'pca9540'
Addresses scanned: I2C 0x70
Datasheet: Publicly available at the Philips Semiconductors website
http://www.semiconductors.philips.com/pip/PCA9540.html
Authors: Jean Delvare <khali@linux-fr.org>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_pca9540: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to
contain a `pca9540' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Note that the force and force_pca9540 parameters are equivalent here.
Description (from the Philips web site)
---------------------------------------
The PCA9540 is a 1-of-2 bi-directional translating multiplexer, controlled
via the I2C bus. The SCL/SDA upstream pair fans out to two SCL/SDA downstream
pairs, or channels. Only one SCL/SDA channel is selected at a time,
determined by the contents of the programmable control register.
Accessing the PCA9540
---------------------
The PCA9540 is almost impossible to detect. We are lucky that no other
known chip lives at address 0x70.
Beware that the PCA9540 has a single internal register. It does work with
READ BYTE and WRITE BYTE commands, contrary to regular chips which use
READ BYTE DATA and WRITE BYTE DATA. Using i2cdump on the PCA9540 will
actually *write* to it and leave its internal register to value 0x07 (i.e.
no downstream channel selected).
/proc Interface
---------------
There is a single read/write file, named "channel".
0 = no downstream channel selected
1 = first downstream channel selected
2 = second downstream channel selected
Chip Features
-------------
Chip `pca9540'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
channel NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
channel SENSORS_PCA9540_CHANNEL channel:1
doc/chips/pcf8574
-100
View File
@@ -1,100 +0,0 @@
Kernel driver `pcf8574.o'
=========================
Status: Complete
Supported chips:
* Philips PCF8574
Prefix: 'pcf8574'
Addresses scanned: I2C 0x20 - 0x27
Datasheet: Publicly available at the Philips Semiconductors website
http://www.semiconductors.philips.com/pip/PCF8574P.html
* Philips PCF8574A
Prefix: 'pcf8574a'
Addresses scanned: I2C 0x38 - 0x3f
Datasheet: Publicly available at the Philips Semiconductors website
http://www.semiconductors.philips.com/pip/PCF8574P.html
Authors: Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
and Dan Eaton <dan.eaton@rocketlogix.com>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_pcf8574: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to
contain a `pcf8574' chip
* force_pcf8574a: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to
contain a `pcf8574a' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
The PCF8574(A) is an 8-bit I/O expander for the I2C bus produced by Philips
Semiconductors. It is designed to provide a byte I2C interface to up to 16
separate devices (8 x PCF8574 and 8 x PCF8574A).
This device consists of a quasi-bidirectionnal port. Each of the eight I/Os
can be independently used as an input or output. To setup an I/O as an
input, you have to write a 1 to the corresponding output.
For more informations see the datasheet.
Accessing PCF8574(A) via /proc interface
-------------------------------------
! Be careful !
The PCF8574(A) is plainly impossible to detect ! Stupid chip.
So every chip with adress in the interval [20..27] and [38..3f] is
detected as PCF8574(A). If you have other chips in this address
range, the workaround is to load this module after the one
for your others chips.
On detection (i.e. insmod, modprobe et al.), directories are being
created for each detected PCF8574(A):
/proc/sys/dev/sensors/pcf8574-<0>-<1>/
where <0> is the bus the chip was detected on (e. g. i2c-0)
and <1> the chip address ([20..27] or [38..3f]):
./pcf8574-i2c-0-27/
Inside these directories, there are two files each:
read and write.
The read file is read-only. Reading gives you the current I/O input
if the corresponding output is set as 1, otherwise the current output
value, that is to say 0.
The write file is read/write. Writing a value outputs it on the I/O
port. Reading return the last written value.
On module initialization the chip is configured as eight inputs (all
outputs to 1), so you can connect any circuit to the PCF8574(A) without
being afraid of short-circuit.
Chip Features
-------------
Chip `pcf8574'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
read NONE NONE R 0
write NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
read SENSORS_PCF8591_READ read:1
write SENSORS_PCF8591_WRITE write:1
doc/chips/pcf8591
-127
View File
@@ -1,127 +0,0 @@
Kernel driver `pcf8591.o'
========================
Status: Status: Complete; Beta.
Supported chips:
* Philips PCF8591
Prefix: 'pcf8591'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Philips Semiconductors website
http://www.semiconductors.philips.com/pip/PCF8591P.html
Author: Aurelien Jarno <aurelien@aurel32.net>
valuable contributions by Jan M. Sendler <sendler@sendler.de>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_pcf8591: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to
contain a `pcf8591' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
The PCF8591 is an 8-bit A/D and D/A converter (4 analog inputs and one
analog ouput) for the I2C bus produced by Philips Semiconductors. It
is designed to provide a byte I2C interface to up to 4 separate devices.
The PCF8591 has 4 analog inputs programmable as single-ended or
differential inputs :
- mode 0 : four single ended inputs
Pins AIN0 to AIN3 are single ended inputs for channels 0 to 3
- mode 1 : three differential inputs
Pins AIN3 is the common negative differential input
Pins AIN0 to AIN2 are positive differential inputs for channels 0 to 2
- mode 2 : single ended and differential mixed
Pins AIN0 and AIN1 are single ended inputs for channels 0 and 1
Pins AIN2 is the positive differential input for channel 3
Pins AIN3 is the negative differential input for channel 3
- mode 3 : two differential inputs
Pins AIN0 is the positive differential input for channel 0
Pins AIN1 is the negative differential input for channel 0
Pins AIN2 is the positive differential input for channel 1
Pins AIN3 is the negative differential input for channel 1
For more informations see the datasheet.
Accessing PCF8591 via /proc interface
-------------------------------------
! Be careful !
The PCF8591 is plainly impossible to detect ! Stupid chip.
So every chip with adress in the interval [48..4f] is
detected as PCF8591. If you have other chips in this address
range, the workaround is to load this module after the one
for your others chips.
On detection (i.e. insmod, modprobe et al.), directories are being
created for each detected PCF8591:
/proc/sys/dev/sensors/pcf8591-<0>-<1>/
where <0> is the bus the chip was detected on (e. g. i2c-0)
and <1> the chip address ([48..4f]): ./pcf8591-i2c-0-48/
Inside these directories, there are five files each:
ain_conf, ch0, ch1, ch2, ch3, aout_enable, aout.
The ain_conf file is rw. Reading gives you the current analog inputs
configuration, and writing configure the analog inputs. It must be
a number between 0 and 3., other values are ignored. For the different
modes, see above in the description.
The ch0, ch1, ch2 and ch3 files are ro. Reading gives the value
of the corresponding channel. Depending on the current analog inputs
configuration, channel ch2 and/or ch3 may are not used by the chip
and so read as 0. Values range are from 0 to 255 for single
ended inputs and -128 to +127 for differential inputs (8-bit ADC).
The aout_enable is rw. Reading gives "1" for analog output enabled and
"0" for analog output disabled. Writing accepts "0" and "1" accordingly.
The aout is rw. Writing a number between 0 and 255 (8-bit DAC), send
the value to the digital-to-analog converter. Note that a voltage will
only appears on AOUT pin if aout_enable equals 1. Reading returns the last
value written.
On module initialization the chip is configured as followed :
- four single ended differential inputs
- analog output set to 0 and enabled
Chip Features
-------------
Chip `pcf8591'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
ain_conf NONE NONE RW 0
ch0 NONE NONE R 0
ch1 NONE NONE R 0
ch2 NONE NONE R 0
ch3 NONE NONE R 0
aout_enable NONE NONE RW 0
aout NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:OFFSET
ain_conf SENSORS_PCF8591_AIN_CONF ain_conf:1
ch0 SENSORS_PCF8591_CH0 ain_ch0:1
ch1 SENSORS_PCF8591_CH1 ain_ch1:1
ch2 SENSORS_PCF8591_CH2 ain_ch2:1
ch3 SENSORS_PCF8591_CH3 ain_ch3:1
aout_enable SENSORS_PCF8591_AOUT_ENABLE aout_enable:1
aout SENSORS_PCF8591_AOUT aout:1
doc/chips/saa1064
-81
View File
@@ -1,81 +0,0 @@
Kernel driver `saa1064.o'
========================
Status: Testing;
Supported chips:
* Philips SAA1064
Prefix: 'saa1064'
Addresses scanned: I2C 0x38 - 0x3b
Datasheet: Publicly available at the Philips Semiconductors website
http://www.semiconductors.philips.com/
http://www.philipslogic.com/products/i2c/pdf/saa1064.pdf
Author: Sascha Volkenandt <sascha@akv-soft.de>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_saa1064: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to
contain a `saa1064' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
The SAA1064 is a 4-digit LED driver chip for the I2C bus produced by Philips
Semiconductors. It is designed to provide a byte I2C interface to up to 4
separate 4-digit displays (16 digits).
This device has eight write-only registers, five are used for a control byte
and the four digit values.
For more informations see the datasheet.
Accessing SAA1064 via /proc interface
-------------------------------------
On detection (i.e. insmod, modprobe et al.), directories are being
created for each detected SAA1064:
/proc/sys/dev/sensors/saa1064-<0>-<1>/
where <0> is the bus the chip was detected on (e. g. i2c-0)
and <1> the chip address ([38..3b]):
./saa1064-i2c-0-38/
Inside these directories, there are four files each:
bright, test, disp and refresh
The bright, test and disp files are read-write.
Writing bright sets the output current to the LEDs connected to the
chip and thus the brightness. Range is from 0 to 7. Reading
gives you the last known value.
Writing test sets the segment test mode (all LEDs lit regardless of
the digit values) on/off (values 0/1). Reading gives you the last
known value.
Writing up to four values to disp sets the digits. Each value represents
one segment, while each bit represents one LED of the segment (seven bars
and one dot usually). Reading gives you the last known value.
The refresh file is read-only. You can't read anything from it, but
reading it will trigger a refresh in case a power-loss has occurred since
the last refresh.
On module initialization the chip is configured for segment test (test=1),
full brightness (bright=7), all digit values zeroed.
doc/chips/sis5595
-165
View File
@@ -1,165 +0,0 @@
Kernel driver `sis5595.o'
=========================
Status: Complete and tested
Supported chips:
* Silicon Integrated Systems Corp. SiS5595 Southbridge Hardware Monitor
Prefix: sis5595
Addresses scanned: ISA in PCI-space encoded address
Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.
Supports following revisions:
Version PCI ID PCI Revision
1 1039/0008 01
2 1039/0008 C0
Author: Kyösti Mälkki <kmalkki@cc.hut.fi>
Note: The chips below contain a 0008 device which is incompatible with the
5595. We recognize these by the presence of the listed
"blacklist" PCI ID and refuse to load.
NOT SUPPORTED PCI ID BLACKLIST PCI ID
540 0008 0540
550 0008 0550
5513 0008 5511
5581 0008 5597
5582 0008 5597
5597 0008 5597
5598 0008 5597/5598
630 0008 0630
645 0008 0645
730 0008 0730
735 0008 0735
Module Parameters
-----------------
force_addr=0xaddr Set the I/O base address. Useful for boards
that don't set the address in the BIOS. Does not do a
PCI force; the device must still be present in lspci.
Don't use this unless the driver complains that the
base address is not set.
Example: 'modprobe sis5595 force_addr=0x290'
Description
-----------
The Sis5595 southbridge has integrated hardware monitor functions.
It also has an I2C bus, but this driver only supports the hardware monitor.
For the I2C bus driver see i2c-sis5595.
The SiS5595 implements zero or one temperature sensor, two fan speed
sensors, four or five voltage sensors, and alarms.
On the first version of the chip, there are four voltage
sensors and one temperature sensor.
On the second version of the chip,
the temperature sensor (temp) and the fifth voltage sensor (in4) share a pin
which is configurable, but not through the driver. Sorry.
The driver senses the configuration of the pin, which was hopefully
set by the BIOS.
If the temperature function is enabled, in4 will return 0.
If the in4 function is enabled, temp will return 0.
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the max is crossed; it is also triggered
when it drops below the min value.
Measurements are guaranteed
between -55 and +125 degrees, with a resolution of 1 degree.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts.
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. All voltage
inputs can measure voltages between 0 and 4.08 volts, with a resolution
of 0.016 volt.
In addition to the alarms described above, there is a BTI alarm, which gets
triggered when an external chip has crossed its limits. Usually, this is
connected to some LM75-like chip; if at least one crosses its limits, this
bit gets set.
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 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
The Sis5595 only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
Problems
--------
Some chips refuse to be enabled. We don't know why.
The driver will recognize this and print a message in dmesg.
Chip Features
-------------
Chip `sis5595'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 2
in1 NONE NONE R 2
in2 NONE NONE R 2
in3 NONE NONE R 2
in4 NONE NONE R 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
alarms NONE NONE R 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
in0 SENSORS_SIS5595_IN0 in0:3
in1 SENSORS_SIS5595_IN1 in1:3
in2 SENSORS_SIS5595_IN2 in2:3
in3 SENSORS_SIS5595_IN3 in3:3
in4 SENSORS_SIS5595_IN4 in3:3
in0_min SENSORS_SIS5595_IN0_MIN in0:1
in1_min SENSORS_SIS5595_IN1_MIN in1:1
in2_min SENSORS_SIS5595_IN2_MIN in2:1
in3_min SENSORS_SIS5595_IN3_MIN in3:1
in4_min SENSORS_SIS5595_IN4_MIN in4:1
in0_max SENSORS_SIS5595_IN0_MAX in0:2
in1_max SENSORS_SIS5595_IN1_MAX in1:2
in2_max SENSORS_SIS5595_IN2_MAX in2:2
in3_max SENSORS_SIS5595_IN3_MAX in3:2
in4_max SENSORS_SIS5595_IN4_MAX in4:2
fan1 SENSORS_SIS5595_FAN1 fan1:2
fan2 SENSORS_SIS5595_FAN2 fan2:2
fan1_min SENSORS_SIS5595_FAN1_MIN fan1:1
fan2_min SENSORS_SIS5595_FAN2_MIN fan2:1
temp SENSORS_SIS5595_TEMP temp:3
temp_hyst SENSORS_SIS5595_TEMP_HYST temp:2
temp_over SENSORS_SIS5595_TEMP_OVER temp:1
fan1_div SENSORS_SIS5595_FAN1_DIV fan_div:1
fan2_div SENSORS_SIS5595_FAN2_DIV fan_div:2
alarms SENSORS_SIS5595_ALARMS alarms:1
doc/chips/smartbatt
-66
View File
@@ -1,66 +0,0 @@
Kernel driver `smartbatt.o'
==========================
Status: Alpha
Supported chips:
* Smart batteries
Prefix: 'smartbatt'
Address scanned: 0x0b
Datasheet: Smart Battery Data Specification Revision 1.1
http://www.sbs-forum.org/
Author: M. Studebaker <mdsxyz123@yahoo.com>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_smartbatt: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `smartbatt' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
Detection
---------
Very poor. Just looks for the presence of some registers.
Uses
----
Provides read-only access to battery voltage, current, temperature,
charge status, time remaining, and alarms.
/proc entries
-------------
Average readings are one minute rolling averages.
alarms bitmask
charge relative charge, absolute charge (%)
i average current, instantaneous current (A)
temp temperature (deg. C)
time avg. time to empty, avg. time to full,
instantaneous time to full (min)
v max voltage, current voltage (V)
To do
-----
More features.
doc/chips/smbus-arp
-66
View File
@@ -1,66 +0,0 @@
SMBUS_ARP Driver
-------------
This is a demonstration driver which provides SMBus 2.0
ARP services. It isn't much use except for testing SMBus 2.0
ARP and PEC support in the i2c layer.
It is NOT a normal 'chip' driver for a particular sensor device.
If you don't know what SMBus ARP is you don't need this driver.
Stability
---------
Beta.
DETECTION
-------------
This driver requires SMBus 2.0 support in i2c-2.6.4 or higher.
If your kernel does not have i2c-2.6.4 or higher the module
will refuse to load.
This driver will register itself on each i2c bus which
supports SMBus Block Data transactions.
USES
----
The module ARPs each supported bus when it is inserted
(or after that when a i2c bus driver is inserted).
It does not periodically re-ARP, and the i2c stack does not
currently support SMBus Host Notify, so it will not detect
hot-plugged devices.
The smbus-arp module should be inserted before any chip modules
so that it has an opportunity to assign addresses.
/PROC ENTRIES
-------------
There are 8 entries in /proc, 0-7. Each is a 'slot'.
If a chip has responded to ARP, it will appear in a 'slot'
as follows. See the SMBus 2.0 Specification for details.
value function
1 SMBus address
2 UDID Device Capabilities
3 UDID Version / Revision
4 UDID Vendor ID
5 UDID Device ID
6 UDID Interface
7 UDID Subsystem Vendor ID
8 UDID Subsystem Device ID
9 UDID Vendor Specific ID
To reassign a device to a different address, write
that address to the slot. For example, 'echo 13 > 0'
to reassign the device in slot 0 to address 13 (0x0d).
TO DO
-----
lots
Author/Maintainer
-----------------
Mark D. Studebaker (mdsxyz123@yahoo.com)
doc/chips/smsc47m1
-75
View File
@@ -1,75 +0,0 @@
Kernel driver `smsc47m1.o'
==========================
Status: Beta.
Supported chips:
* SMSC LPC47B27x, LPC47M112, LPC47M10x, LPC47M13x, LPC47M14x,
LPC47M15x and LPC47M192
Prefix: 'smsc47m1'
Addresses scanned: none, address read from Super I/O config space
Datasheets:
http://www.smsc.com/main/datasheets/47b27x.pdf
http://www.smsc.com/main/datasheets/47m10x.pdf
http://www.smsc.com/main/datasheets/47m112.pdf
http://www.smsc.com/main/tools/discontinued/47m13x.pdf
http://www.smsc.com/main/datasheets/47m14x.pdf
http://www.smsc.com/main/tools/discontinued/47m15x.pdf
http://www.smsc.com/main/datasheets/47m192.pdf
* SMSC LPC47M292
Prefix: 'smsc47m2'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Not public
* SMSC LPC47M997
Addresses scanned: none, address read from Super I/O config space
Prefix: 'smsc47m1'
Datasheet: none
Authors: Mark D. Studebaker <mdsxyz123@yahoo.com>
With assistance from Bruce Allen <ballen@uwm.edu> and his
fan.c program: http://www.lsc-group.phys.uwm.edu/%7Eballen/driver/
Module Parameters
-----------------
force_addr=0xaddr Set the I/O base address. Useful for boards
that don't set the address in the BIOS.
Don't use this unless the driver complains that the
base address is not set.
Example: 'modprobe smsc47m1 force_addr=0x680'
Description
-----------
The Standard Microsystems Corporation (SMSC) 47M1xx Super I/O chips
contain monitoring and PWM control circuitry for two fans.
The LPC47M15x, LPC47M192 and LPC47M292 chips contain a full 'hardware
monitoring block' in addition to the fan monitoring and control. The
hardware monitoring block is not supported by the driver.
No documentation is available for the 47M997, but it has the same device
ID as the 47M15x and 47M192 chips and seems to be compatible therewith.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
PWM values are from 0 to 255. The first value in the /proc entry is
the pwm value; the second is the enable (0 or 1).
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 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
**********************
The lm_sensors project gratefully acknowledges the support of
Intel in the development of this driver.
doc/chips/thmc50
-96
View File
@@ -1,96 +0,0 @@
Kernel driver `thmc50.o'
=====================
Status: Complete and some-what tested
Supported chips:
* Analog Devices ADM1022
Prefix: 'adm1022'
Addresses scanned: I2C 0x2C - 0x2E
Datasheet: http://www.analog.com/en/prod/0,2877,ADM1022,00.html
* Texas Instruments THMC50
Prefix: 'thmc50'
Addresses scanned: I2C 0x2C - 0x2E
Datasheet: http://focus.ti.com/docs/prod/folders/print/thmc50.html
Authors: Frodo Looijaard <frodol@dds.nl> and
Philip Edelbrock <phil@netroedge.com>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_thmc50: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `thmc50' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Description
-----------
The THMC50 implements: an internal temperature sensor, support for an
external diode-type temperature sensor (compatible w/ the diode sensor inside
many processors), and a controllable fan/analog_out DAC. For the temperature
sensors, limits can be set through the appropriate Overtemperature Shutdown
register and Hysteresis register. Each value can be set and read to half-degree
accuracy. An alarm is issued (usually to a connected LM78) when the
temperature gets higher then the Overtemperature Shutdown value; it stays on
until the temperature falls below the Hysteresis value. All temperatures are in
degrees Celsius, and are guaranteed within a range of -55 to +125 degrees.
The THMC50 only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
The THMC50 is usually used in combination with LM78-like chips, to measure
the temperature of the processor(s).
Driver Features
---------------
These are the files which are provided by the driver (ro=read-only,
rw=read and writeable):
temp1 (internal) -- Three fields: [temp-os,rw] [temp-hyst,rw] [temp,ro]
temp2 (remote) -- Three fields: [temp-os,rw] [temp-hyst,rw] [temp,ro]
temp-os, temp-hyst, and temp are whole degree integers representing degrees
Celsius.
analog_out -- One field: [output-value,rw]
output-value is a number from 0 to 255 representing the voltage output
provided by the DAC from 0 to 2.5, respectively. Note: the max *current*
supplied is actually quite low. Some type of current amplification is needed
in order to control a fan or other current demanding device (see the
datasheet for more info).
die_code -- One field: [die-code,ro]
die-code is an integer representation of the die_code byte register.
According to the docs, the high nibble is the die version, and the lower
nibble is the stepping. (Don't ask me why or what this means! ;')
inter -- One field: [interrupts,rw]
interrupts is an integer representation of the interrupts byte. See the data
sheet for what bits mean what.
inter_mask -- One field: [inter-mask,rw]
inter-mask is an integer repressentation of the interrupt mask which is a
determination of which conditions can cause the /INT pin on the chip to
become asserted.
doc/chips/via686a
-155
View File
@@ -1,155 +0,0 @@
Kernel driver `via686a.o'
=========================
Status: Stable.
Supported chips:
* Via VT82C686A, VT82C686B Southbridge Integrated Hardware Monitor
Prefix: 'via686a'
Addresses scanned: ISA in PCI-space encoded address
Datasheet: On request through web form
(http://www.via.com.tw/en/support/datasheets/)
Authors: Kyösti Mälkki <kmalkki@cc.hut.fi>,
Mark D. Studebaker <mdsxyz123@yahoo.com>
Bob Dougherty <bobd@stanford.edu>
(Some conversion-factor data were contributed by
Jonathan Teh Soon Yew <j.teh@iname.com>
and Alex van Kaam <darkside@chello.nl>.)
Module Parameters
-----------------
force_addr=0xaddr Set the I/O base address. Useful for boards that
don't set the address in the BIOS. Look for a BIOS
upgrade before resorting to this. Does not do a
PCI force; the via686a must still be present in lspci.
Don't use this unless the driver complains that the
base address is not set.
Example: 'modprobe via686a force_addr=0x6000'
Description
-----------
The driver does not distinguish between the chips and reports
all as a 686A.
The Via 686a southbridge has integrated hardware monitor functionality.
It also has an I2C bus, but this driver only supports the hardware monitor.
For the I2C bus driver, see ../busses/i2c-viapro.
The Via 686a implements three temperature sensors, two fan rotation speed
sensors, five voltage sensors and alarms.
Temperatures are measured in degrees Celsius. An alarm is triggered once
when the Overtemperature Shutdown limit is crossed; it is triggered again
as soon as it drops below the hysteresis value.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts.
An alarm is triggered if the voltage has crossed a programmable minimum
or maximum limit. Voltages are internally scalled, so each voltage channel
has a different resolution and range.
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 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
The driver only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.
Known Issues
------------
This driver handles sensors integrated in some VIA south bridges. It is
possible that a motherboard maker used a VT82C686A/B chip as part of a
product design but was not interested in its hardware monitoring features,
in which case the sensor inputs will not be wired. This is the case of
the Asus K7V, A7V and A7V133 motherboards, to name only a few of them.
So, if you need the force_addr parameter, and end up with values which
don't seem to make any sense, don't look any further: your chip is simply
not wired for hardware monitoring.
Chip Features
-------------
Chip `via686a'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 2
in1 NONE NONE R 2
in2 NONE NONE R 2
in3 NONE NONE R 2
in4 NONE NONE R 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in3 in3 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in3 in3 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
temp NONE NONE R 1
temp_hyst temp temp RW 1
temp_over temp temp RW 1
temp2 NONE NONE R 1
temp2_hyst temp temp RW 1
temp2_over temp temp RW 1
temp3 NONE NONE R 1
temp3_hyst temp temp RW 1
temp3_over temp temp RW 1
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
alarms NONE NONE R 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
in0 SENSORS_VIA686A_IN0 in0:3
in1 SENSORS_VIA686A_IN1 in1:3
in2 SENSORS_VIA686A_IN2 in2:3
in3 SENSORS_VIA686A_IN3 in3:3
in4 SENSORS_VIA686A_IN4 in4:3
in0_min SENSORS_VIA686A_IN0_MIN in0:1
in1_min SENSORS_VIA686A_IN1_MIN in1:1
in2_min SENSORS_VIA686A_IN2_MIN in2:1
in3_min SENSORS_VIA686A_IN3_MIN in3:1
in4_min SENSORS_VIA686A_IN4_MIN in4:1
in0_max SENSORS_VIA686A_IN0_MAX in0:2
in1_max SENSORS_VIA686A_IN1_MAX in1:2
in2_max SENSORS_VIA686A_IN2_MAX in2:2
in3_max SENSORS_VIA686A_IN3_MAX in3:2
in4_max SENSORS_VIA686A_IN4_MAX in4:2
fan1 SENSORS_VIA686A_FAN1 fan1:2
fan2 SENSORS_VIA686A_FAN2 fan2:2
fan1_min SENSORS_VIA686A_FAN1_MIN fan1:1
fan2_min SENSORS_VIA686A_FAN2_MIN fan2:1
temp SENSORS_VIA686A_TEMP temp:3
temp_hyst SENSORS_VIA686A_TEMP_HYST temp:2
temp_over SENSORS_VIA686A_TEMP_OVER temp:1
temp2 SENSORS_VIA686A_TEMP2 temp2:3
temp2_hyst SENSORS_VIA686A_TEMP2_HYST temp2:2
temp2_over SENSORS_VIA686A_TEMP2_OVER temp2:1
temp3 SENSORS_VIA686A_TEMP3 temp3:3
temp3_hyst SENSORS_VIA686A_TEMP3_HYST temp3:2
temp3_over SENSORS_VIA686A_TEMP3_OVER temp3:1
fan1_div SENSORS_VIA686A_FAN1_DIV fan_div:1
fan2_div SENSORS_VIA686A_FAN2_DIV fan_div:2
alarms SENSORS_VIA686A_ALARMS alarms:1
doc/chips/vt1211
-70
View File
@@ -1,70 +0,0 @@
Kernel driver `vt1211.o'
=========================
Status: Beta.
Supported chips:
* Via VT1211 Super I/O Controller
Addresses scanned: none, address read from Super I/O config space
Authors: Mark D. Studebaker <mdsxyz123@yahoo.com>
Module Parameters
-----------------
force_addr=0xaddr Set the I/O base address. Useful for boards
that don't set the address in the BIOS.
Don't use this unless the driver complains that the
base address is not set.
Example: 'modprobe vt1211 force_addr=0x680'
Description
-----------
The Via VT1211 Super I/O chip
contains voltage/temperature monitoring and
PWM control circuitry for two fans.
We define the sensors as follows. Somewhat convoluted to minimize
changes from via686a.
Sensor Voltage Mode Temp Mode uch_config bit
-------- ------------ --------- --------------
Reading 1 temp3
Reading 3 temp1
UCH1/Reading2 in0 temp2 0x04 (4)
UCH2 in1 temp4 0x08 (8)
UCH3 in2 temp5 0x10 (16)
UCH4 in3 temp6 0x20 (32)
UCH5 in4 temp7 0x40 (64)
3.3V in5
As noted above, 5 of the sensors are "universal channels" and can
be set for either voltage or temperature.
Set the uch_config bit (in /proc) to 0 for voltage and 1 for temperature.
Voltages will read 0 if set for temperature.
Temperatures will read a really low number if set for voltage.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
PWM values are from 0 to 255. The first value in the /proc entry is
the pwm value; the second is the enable (0 or 1).
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 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
**********************
The lm_sensors project gratefully acknowledges the support of
Via in the development of this driver.
doc/chips/vt8231
-184
View File
@@ -1,184 +0,0 @@
Kernel driver `vt8231.o'
========================
Status: Beta
Supported chips:
* VIA VT8231 South Bridge
Prefix: 'vt8231'
Addresses scanned: none, address read from PCI space
Author: Mark D. Studebaker <mdsxyz123@yahoo.com>
License: GPL
Module Parameters
-----------------
* force_addr: int
Initialize the base address of the sensors
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_vt8231: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `vt8231' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
Description
-----------
The VIA VT8231 South Bridge contains voltage/temperature monitoring and
PWM control circuitry for two fans.
We define the sensors as follows.
Sensor Voltage Mode Temp Mode uch_config bit
------ ------------ --------- --------------
Reading 1 temp1
UCH1 in0 temp2 0x04 (4)
UCH2 in1 temp3 0x08 (8)
UCH3 in2 temp4 0x10 (16)
UCH4 in3 temp5 0x20 (32)
UCH5 in4 temp6 0x40 (64)
3.3V in5
As noted above, 5 of the sensors are "universal channels" and can
be set for either voltage or temperature.
Set the uch_config bit (in /proc) to 0 for voltage and 1 for temperature.
Voltages will read 0 if set for temperature.
Temperatures will read a really low number if set for voltage.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
PWM values are from 0 to 255. The first value in the /proc entry is
the pwm value; the second is the enable (0 or 1).
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 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
Chip Features
-------------
Chip 'vt8231'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
in0 - - R- 2
in1 - - R- 2
in2 - - R- 2
in3 - - R- 2
in4 - - R- 2
in5 - - R- 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in5_min in5 in5 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
in5_max in5 in5 RW 2
fan1 - - R- 0
fan2 - - R- 0
fan1_min fan1 fan1 RW 0
fan2_min fan2 fan2 RW 0
temp1 - - R- 1
temp1_hyst temp1 temp1 RW 1
temp1_over temp1 temp1 RW 1
temp2 - - R- 2
temp2_hyst temp2 temp2 RW 2
temp2_over temp2 temp2 RW 2
temp3 - - R- 2
temp3_hyst temp3 temp3 RW 2
temp3_over temp3 temp3 RW 2
temp4 - - R- 2
temp4_hyst temp4 temp4 RW 2
temp4_over temp4 temp4 RW 2
temp5 - - R- 2
temp5_hyst temp5 temp5 RW 2
temp5_over temp5 temp5 RW 2
temp6 - - R- 2
temp6_hyst temp6 temp6 RW 2
temp6_over temp6 temp6 RW 2
fan1_div fan1 - RW 0
fan2_div fan2 - RW 0
alarms - - R- 0
vid - - R- 3
vrm - - RW 1
config - - R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
in0 SENSORS_VT8231_IN0 in0:3
in1 SENSORS_VT8231_IN1 in1:3
in2 SENSORS_VT8231_IN2 in2:3
in3 SENSORS_VT8231_IN3 in3:3
in4 SENSORS_VT8231_IN4 in4:3
in5 SENSORS_VT8231_IN5 in5:3
in0_min SENSORS_VT8231_IN0_MIN in0:1
in1_min SENSORS_VT8231_IN1_MIN in1:1
in2_min SENSORS_VT8231_IN2_MIN in2:1
in3_min SENSORS_VT8231_IN3_MIN in3:1
in4_min SENSORS_VT8231_IN4_MIN in4:1
in5_min SENSORS_VT8231_IN5_MIN in5:1
in0_max SENSORS_VT8231_IN0_MAX in0:2
in1_max SENSORS_VT8231_IN1_MAX in1:2
in2_max SENSORS_VT8231_IN2_MAX in2:2
in3_max SENSORS_VT8231_IN3_MAX in3:2
in4_max SENSORS_VT8231_IN4_MAX in4:2
in5_max SENSORS_VT8231_IN5_MAX in5:2
fan1 SENSORS_VT8231_FAN1 fan1:2
fan2 SENSORS_VT8231_FAN2 fan2:2
fan1_min SENSORS_VT8231_FAN1_MIN fan1:1
fan2_min SENSORS_VT8231_FAN2_MIN fan2:1
temp1 SENSORS_VT8231_TEMP temp1:3
temp1_hyst SENSORS_VT8231_TEMP_HYST temp1:2
temp1_over SENSORS_VT8231_TEMP_OVER temp1:1
temp2 SENSORS_VT8231_TEMP2 temp2:3
temp2_hyst SENSORS_VT8231_TEMP2_HYST temp2:2
temp2_over SENSORS_VT8231_TEMP2_OVER temp2:1
temp3 SENSORS_VT8231_TEMP3 temp3:3
temp3_hyst SENSORS_VT8231_TEMP3_HYST temp3:2
temp3_over SENSORS_VT8231_TEMP3_OVER temp3:1
temp4 SENSORS_VT8231_TEMP4 temp4:3
temp4_hyst SENSORS_VT8231_TEMP4_HYST temp4:2
temp4_over SENSORS_VT8231_TEMP4_OVER temp4:1
temp5 SENSORS_VT8231_TEMP5 temp5:3
temp5_hyst SENSORS_VT8231_TEMP5_HYST temp5:2
temp5_over SENSORS_VT8231_TEMP5_OVER temp5:1
temp6 SENSORS_VT8231_TEMP6 temp6:3
temp6_hyst SENSORS_VT8231_TEMP6_HYST temp6:2
temp6_over SENSORS_VT8231_TEMP6_OVER temp6:1
fan1_div SENSORS_VT8231_FAN1_DIV fan_div:1
fan2_div SENSORS_VT8231_FAN2_DIV fan_div:2
alarms SENSORS_VT8231_ALARMS alarms:1
vid SENSORS_VT8231_VID vid:1
vrm SENSORS_VT8231_VRM vrm:1
config SENSORS_VT8231_UCH uch_config:1
Notes
-----
The lm_sensors project gratefully acknowledges the support of VIA in the
development of this driver.
doc/chips/w83627ehf
-67
View File
@@ -1,67 +0,0 @@
Kernel driver `w83627ehf.o'
===========================
Status: Stable; some missing features.
Supported chips:
* Winbond W83627EHF/EHG (ISA access ONLY)
Prefix: 'w83627ehf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf
Authors:
Jean Delvare <khali@linux-fr.org>
Yuan Mu (Winbond)
Rudolf Marek <r.marek@assembler.cz>
David Hubbard <david.c.hubbard@gmail.com>
Thanks to Observit and Bernardo Motta for providing a motherboard, CPU
and memory that made it possible to backport the w83627ehf driver from
Linux 2.6 to Linux 2.4.
Description
-----------
This driver implements support for the Winbond W83627EHF and W83627EHG
super I/O chips. Support for the W83627DHG isn't included, but could be
easily added if needed.
The chips implement three temperature sensors, five fan rotation speed
sensors, ten analog voltage sensors, alarms with beep warnings (control
unimplemented), some automatic fan regulation strategies (unimplemented)
and manual fan speed control.
Temperatures are measured in degrees Celsius and measurement resolution is
1 degree Celsius for temp1 and 0.5 degee Celsius for temp2 and temp3. An
alarm is triggered when the temperature gets higher than high limit; it
stays on until the temperature falls below the hysteresis value.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 or
128) to give the readings more range or accuracy. The driver sets the most
suitable fan divisor itself. Some fans might not be present because they
share pins with other functions.
Voltage sensors (also known as IN sensors) report their values in Volts.
An alarm is triggered if the voltage has crossed a programmable minimum
or maximum limit.
Fan speed control
-----------------
The chips support 4 different fan speed control modes. The currently
selected mode can be read from (and written to) the second value of
files pwm[1-4]. Modes are:
1: Manual mode. The desired fan speed can be written to the first
value of the pwm[1-4] file, from 0 (stop) to 255 (full speed).
2: Thermal cruise mode (unimplemented).
3: Fan speed cuise mode (unimplemented).
4: Smart Fan III mode (pwm2 and pwm4 only, unimplemented).
While the automatic modes are not implemented by this driver, they can
still be selected, so they will work if (and only if) the BIOS has
programmed the chip with sensible register values.
doc/chips/w83627hf
-103
View File
@@ -1,103 +0,0 @@
Kernel driver `w83627hf.o'
=========================
Status: Beta.
Supported chips:
* Winbond W83627HF (ISA accesses ONLY)
Prefix: 'w83627hf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: http://www.winbond.com/PDF/sheet/w83627hf.pdf
* Winbond W83627THF
Prefix: 'w83627thf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: http://www.winbond.com/PDF/sheet/w83627thf.pdf
* Winbond W83697HF
Prefix: 'w83697hf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: http://www.winbond.com/PDF/sheet/w83697hf.pdf
* Winbond W83637HF
Prefix: 'w83637hf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: http://www.winbond.com/PDF/sheet/w83637hf.pdf
* Winbond W83687THF
Prefix: 'w83687thf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Provided by Winbond on request
Authors: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock <phil@netroedge.com>,
and Mark Studebaker <mdsxyz123@yahoo.com>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_addr: int
Initialize the ISA address of the sensors
* force_i2c: int
Initialize the I2C address of the sensors
* force_w83627hf: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `w83627hf' chip
* force_w83627thf: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `w83627thf' chip
* force_w83697hf: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `w83697hf' chip
* force_w83637hf: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `w83637hf' chip
* force_w83687thf: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `w83687thf' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* init=[0,1] (default 1)
Use 'init=0' to bypass initializing the chip.
Try this if your computer crashes when you load the module.
Description
-----------
This driver implements support for ISA accesses *only* for
the Winbond W83627HF, W83627THF, W83697HF, W83637HF and W83687THF
Super I/O chips. We will refer to them collectively as Winbond chips.
This driver supports ISA accesses, which should be more reliable
than i2c accesses. Also, for Tyan boards which contain both a
Super I/O chip and a second i2c-only Winbond chip (often a W83782D),
using this driver will avoid i2c address conflicts and complex
initialization that were required in the w83781d driver
(lm_sensors releases 2.7.0 and earlier).
If you really want i2c accesses for these Super I/O chips,
use the w83781d driver. However this is not the preferred method
now that this ISA driver has been developed.
The w83627_HF_ uses pins 110-106 as VID0-VID4. The w83627_THF_ uses the
same pins as GPIO[0:4]. Technically, the w83627_THF_ does not support a
VID reading. However the two chips have the identical 128 pin package. So,
it is possible or even likely for a w83627thf to have the VID signals routed
to these pins despite their not being labeled for that purpose. Therefore,
the w83627thf driver interprets these as VID. If the VID on your board
doesn't work, first see doc/vid. If that still doesn't help, you may just
ignore the bogus VID reading with no harm done.
For further information on this driver, /proc values, etc.
see the w83781d driver documentation.
Author/Maintainer
-----------------
Mark D. Studebaker (mdsxyz123@yahoo.com).
Derived from the w83781d driver.
doc/chips/w83781d
-833
View File
@@ -1,833 +0,0 @@
Kernel driver `w83781d.o'
=========================
Status: W83781D support is complete and well-tested.
W83782D support is complete and well-tested.
W83783S support is complete but has not been well-tested.
W83791D support is BETA.
W83627HF support is complete but has not been well-tested.
AS99127F support is BETA and has known problems due to lack of a
chip datasheet. SEE BELOW.
Supported chips:
* Winbond W83781D
Prefix: 'w83781d'
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/w83781d.pdf
* Winbond W83782D
Prefix: 'w83782d'
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
Datasheet: http://www.winbond.com/PDF/sheet/w83782d.pdf
* Winbond W83783S
Prefix: 'w83783s'
Addresses scanned: I2C 0x2d
Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/w83783s.pdf
* Winbond W83791D
Prefix: 'w83791d'
Addresses scanned: I2C 0x2c - 0x2f
Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/w83791d.pdf
* Winbond W83627HF
Prefix: 'w83627hf'
Addresses scanned: I2C 0x20 - 0x2f, ISA 0x290 (8 I/O ports)
Datasheet: http://www.winbond.com/PDF/sheet/w83627hf.pdf
* Asus AS99127F
Prefix: 'as99127f'
Addresses scanned: I2C 0x28 - 0x2f
Datasheet: Unavailable from Asus
Authors: Frodo Looijaard <frodol@dds.nl>, Philip Edelbrock <phil@netroedge.com>,
and Mark Studebaker <mdsxyz123@yahoo.com>
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_w83781d: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `w83781d' chip
* force_w83782d:
Ditto
* force_w83783s:
Ditto
* force_w83791d:
Ditto
* force_w83627hf:
Ditto
* force_as99127f:
Ditto
* force_subclients=bus,caddr,saddr,saddr
This is used to force the i2c addresses for subclients of
a certain chip. Typical usage is `force_subclients=0,0x2d,0x4a,0x4b'
to force the subclients of chip 0x2d on bus 0 to i2c addresses
0x4a and 0x4b.
This parameter is useful for certain Tyan boards.
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* init=[0,1] (default 1)
Use 'init=0' to bypass initializing the chip.
Try this if your computer crashes when you load the module.
Description
-----------
This driver implements support for the Winbond W83781D, W83782D,
W83783S, W83791D, W83627HF and W83698HF chips, and the Asus AS99127F chips.
We will refer to them collectively as W8378* chips.
There is quite some difference between these chips, but they are similar
enough that it was sensible to put them together in one driver.
The W83627HF chip is assumed to be identical to the ISA W83782D.
The Asus chips are similar to an I2C-only W83782D.
Detection of these chips can sometimes be foiled because they can be in
an internal state that allows no clean access. If you know the address
of the chip, use a 'force' parameter; this will put them into a more
well-behaved state first.
The W8378* implements temperature sensors (three on the W83781D and W83782D,
two on the W83783S), three fan rotation speed sensors, voltage sensors
(seven on the W83781D, nine on the W83782D and six on the W83783S), VID
lines, alarms with beep warnings, and some miscellaneous stuff.
Temperatures are measured in degrees Celsius. There is always one main
temperature sensor, and one (W83783S) or two (W83781D and W83782D) other
sensors. An alarm is triggered for the main sensor once when the
Overtemperature Shutdown limit is crossed; it is triggered again as soon as
it drops below the Hysteresis value. A more useful behaviour
can be found by setting the Hysteresis value to +127 degrees Celsius; in
this case, alarms are issued during all the time when the actual temperature
is above the Overtemperature Shutdown value. The driver sets the
hysteresis value for temp1 to 127 at initialization.
For the other temperature sensor(s), an
alarm is triggered when the temperature gets higher then the Overtemperature
Shutdown value; it stays on until the temperature falls below the Hysteresis
value. But on the W83781D, there is only one alarm that functions for both
other sensors! Temperatures are guaranteed within a range of -55 to +125
degrees. The main temperature sensors has a resolution of 1 degree; the other
sensor(s) of 0.5 degree.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8 for the
W83781D; 1, 2, 4, 8, 16, 32, 64 or 128 for the others) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 2, the lowest
representable value is around 2600 RPM.
Voltage sensors (also known as IN sensors) report their values in volts.
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. All voltage
inputs can measure voltages between 0 and 4.08 volts, with a resolution
of 0.016 volt.
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. When it is unconnected, you will often find the
value 3.50 V here.
The W83782D and W83783S temperature conversion machine understands about
several kinds of temperature probes. You can program the so-called
beta value in the sensor files. '1' is the PII/Celeron diode, '2' is the
TN3904 transistor, and 3435 the default thermistor value. Other values
are (not yet) supported. You can program your own values through the
rt interface, but this is not very useful, because these tables are
under NDA.
In addition to the alarms described above, there is a CHAS alarm on the
chips which triggers if your computer case is open.
When an alarm goes off, you can be warned by a beeping signal through
your computer speaker. It is possible to enable all beeping globally,
or only the beeping for some alarms.
Individual alarm and beep bits:
0x000001: in0
0x000002: in1
0x000004: in2
0x000008: in3
0x000010: temp1
0x000020: temp2 (+temp3 on W83781D)
0x000040: fan1
0x000080: fan2
0x000100: in4
0x000200: in5
0x000400: in6
0x000800: fan3
0x001000: chassis
0x002000: temp3 (W83782D and W83627HF only)
0x010000: in7 (W83782D and W83627HF only)
0x020000: in8 (W83782D and W83627HF only)
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 1.5 seconds since the last update). This means that you can easily
miss once-only alarms.
The chips only update values each 1.5 seconds; reading them more often
will do no harm, but will return 'old' values.
AS99127F PROBLEMS
-----------------
The as99127f support was developed without the benefit of a datasheet.
In most cases it is treated as a w83781d (although revision 2 of the
AS9917F looks more like a w83782d).
This support will be BETA until a datasheet is released.
One user has reported problems with fans stopping
occasionally.
Note that the individual beep bits are inverted from the other chips.
The driver now takes care of this so that user-space applications
don't have to know about it.
Known problems:
- Problems with diode/thermistor settings (supported?)
- One user reports fans stopping under high server load.
- Revision 2 seems to have 2 PWM registers but we don't know
how to handle them. More details below.
These will not be fixed unless we get a datasheet.
If you have problems, please lobby Asus to release a datasheet.
Unfortunately several others have without success.
Please do not send mail to us asking for better as99127f support.
We have done the best we can without a datasheet.
Please do not send mail to the author or the sensors group asking for
a datasheet or ideas on how to convince Asus. We can't help.
Chip Features
-------------
Chip `w83781d'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 2
in1 NONE NONE R 2
in2 NONE NONE R 2
in3 NONE NONE R 2
in4 NONE NONE R 2
in5 NONE NONE R 2
in6 NONE NONE R 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in5_min in5 in5 RW 2
in6_min in6 in6 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
in5_max in5 in5 RW 2
in6_max in6 in6 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan3 NONE NONE R 0
fan1_min fan1 NONE RW 0
fan2_min fan2 NONE RW 0
fan3_min fan3 NONE RW 0
temp1 NONE NONE R 1
temp1_hyst temp1 temp1 RW 1
temp1_over temp1 temp1 RW 1
temp2 NONE NONE R 1
temp2_hyst temp2 temp2 RW 1
temp2_over temp2 temp2 RW 1
temp3 NONE NONE R 1
temp3_hyst temp3 temp3 RW 1
temp3_over temp3 temp3 RW 1
vid NONE NONE R 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
fan3_div fan3 NONE R 0
alarms NONE NONE R 0
beep_enable alarms NONE RW 0
beeps alarms alarms RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
in0 SENSORS_W83781D_IN0 in0:3
in1 SENSORS_W83781D_IN1 in1:3
in2 SENSORS_W83781D_IN2 in2:3
in3 SENSORS_W83781D_IN3 in3:3
in4 SENSORS_W83781D_IN4 in4:3
in5 SENSORS_W83781D_IN5 in5:3
in6 SENSORS_W83781D_IN6 in6:3
in0_min SENSORS_W83781D_IN0_MIN in0:1
in1_min SENSORS_W83781D_IN1_MIN in1:1
in2_min SENSORS_W83781D_IN2_MIN in2:1
in3_min SENSORS_W83781D_IN3_MIN in3:1
in4_min SENSORS_W83781D_IN4_MIN in4:1
in5_min SENSORS_W83781D_IN5_MIN in5:1
in6_min SENSORS_W83781D_IN6_MIN in6:1
in0_max SENSORS_W83781D_IN0_MAX in0:2
in1_max SENSORS_W83781D_IN1_MAX in1:2
in2_max SENSORS_W83781D_IN2_MAX in2:2
in3_max SENSORS_W83781D_IN3_MAX in3:2
in4_max SENSORS_W83781D_IN4_MAX in4:2
in5_max SENSORS_W83781D_IN5_MAX in5:2
in6_max SENSORS_W83781D_IN6_MAX in6:2
fan1 SENSORS_W83781D_FAN1 fan1:2
fan2 SENSORS_W83781D_FAN2 fan2:2
fan3 SENSORS_W83781D_FAN3 fan3:2
fan1_min SENSORS_W83781D_FAN1_MIN fan1:1
fan2_min SENSORS_W83781D_FAN2_MIN fan2:1
fan3_min SENSORS_W83781D_FAN3_MIN fan3:1
temp1 SENSORS_W83781D_TEMP1 temp1:3
temp1_hyst SENSORS_W83781D_TEMP1_HYST temp1:2
temp1_over SENSORS_W83781D_TEMP1_OVER temp1:1
temp2 SENSORS_W83781D_TEMP2 temp2:3
temp2_hyst SENSORS_W83781D_TEMP2_HYST temp2:2
temp2_over SENSORS_W83781D_TEMP2_OVER temp2:1
temp3 SENSORS_W83781D_TEMP3 temp3:3
temp3_hyst SENSORS_W83781D_TEMP3_HYST temp3:2
temp3_over SENSORS_W83781D_TEMP3_OVER temp3:1
vid SENSORS_W83781D_VID vid:1
fan1_div SENSORS_W83781D_FAN1_DIV fan_div:1
fan2_div SENSORS_W83781D_FAN2_DIV fan_div:2
fan3_div SENSORS_W83781D_FAN3_DIV fan_div:3
alarms SENSORS_W83781D_ALARMS alarms:1
beep_enable SENSORS_W83781D_BEEP_ENABLE beep:1
beeps SENSORS_W83781D_BEEPS beep:2
Chip `w83782d'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 2
in1 NONE NONE R 2
in2 NONE NONE R 2
in3 NONE NONE R 2
in4 NONE NONE R 2
in5 NONE NONE R 2
in6 NONE NONE R 2
in7 NONE NONE R 2
in8 NONE NONE R 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in5_min in5 in5 RW 2
in6_min in6 in6 RW 2
in7_min in7 in7 RW 2
in8_min in8 in8 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
in5_max in5 in5 RW 2
in6_max in6 in6 RW 2
in7_max in7 in7 RW 2
in8_max in8 in8 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan3 NONE NONE R 0
fan1_min fan1 NONE RW 0
fan2_min fan2 NONE RW 0
fan3_min fan3 NONE RW 0
temp1 NONE NONE R 1
temp1_hyst temp1 temp1 RW 1
temp1_over temp1 temp1 RW 1
temp2 NONE NONE R 1
temp2_hyst temp2 temp2 RW 1
temp2_over temp2 temp2 RW 1
temp3 NONE NONE R 1
temp3_hyst temp3 temp3 RW 1
temp3_over temp3 temp3 RW 1
vid NONE NONE R 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
fan3_div fan3 NONE R 0
alarms NONE NONE R 0
beep_enable alarms NONE RW 0
beeps alarms alarms RW 0
sensor1 NONE NONE RW 0
sensor2 NONE NONE RW 0
sensor3 NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
in0 SENSORS_W83782D_IN0 in0:3
in1 SENSORS_W83782D_IN1 in1:3
in2 SENSORS_W83782D_IN2 in2:3
in3 SENSORS_W83782D_IN3 in3:3
in4 SENSORS_W83782D_IN4 in4:3
in5 SENSORS_W83782D_IN5 in5:3
in6 SENSORS_W83782D_IN6 in6:3
in7 SENSORS_W83782D_IN7 in7:3
in8 SENSORS_W83782D_IN8 in8:3
in0_min SENSORS_W83782D_IN0_MIN in0:1
in1_min SENSORS_W83782D_IN1_MIN in1:1
in2_min SENSORS_W83782D_IN2_MIN in2:1
in3_min SENSORS_W83782D_IN3_MIN in3:1
in4_min SENSORS_W83782D_IN4_MIN in4:1
in5_min SENSORS_W83782D_IN5_MIN in5:1
in6_min SENSORS_W83782D_IN6_MIN in6:1
in7_min SENSORS_W83782D_IN7_MIN in7:1
in8_min SENSORS_W83782D_IN8_MIN in8:1
in0_max SENSORS_W83782D_IN0_MAX in0:2
in1_max SENSORS_W83782D_IN1_MAX in1:2
in2_max SENSORS_W83782D_IN2_MAX in2:2
in3_max SENSORS_W83782D_IN3_MAX in3:2
in4_max SENSORS_W83782D_IN4_MAX in4:2
in5_max SENSORS_W83782D_IN5_MAX in5:2
in6_max SENSORS_W83782D_IN6_MAX in6:2
in7_max SENSORS_W83782D_IN7_MAX in7:2
in8_max SENSORS_W83782D_IN8_MAX in8:2
fan1 SENSORS_W83782D_FAN1 fan1:2
fan2 SENSORS_W83782D_FAN2 fan2:2
fan3 SENSORS_W83781D_FAN3 fan3:2
fan1_min SENSORS_W83782D_FAN1_MIN fan1:1
fan2_min SENSORS_W83782D_FAN2_MIN fan2:1
fan3_min SENSORS_W83781D_FAN3_MIN fan3:1
temp1 SENSORS_W83782D_TEMP1 temp1:3
temp1_hyst SENSORS_W83782D_TEMP1_HYST temp1:2
temp1_over SENSORS_W83782D_TEMP1_OVER temp1:1
temp2 SENSORS_W83782D_TEMP2 temp2:3
temp2_hyst SENSORS_W83782D_TEMP2_HYST temp2:2
temp2_over SENSORS_W83782D_TEMP2_OVER temp2:1
temp3 SENSORS_W83782D_TEMP3 temp3:3
temp3_hyst SENSORS_W83782D_TEMP3_HYST temp3:2
temp3_over SENSORS_W83782D_TEMP3_OVER temp3:1
vid SENSORS_W83782D_VID vid:1
fan1_div SENSORS_W83782D_FAN1_DIV fan_div:1
fan2_div SENSORS_W83782D_FAN2_DIV fan_div:2
fan3_div SENSORS_W83781D_FAN3_DIV fan_div:3
alarms SENSORS_W83782D_ALARMS alarms:1
beep_enable SENSORS_W83782D_BEEP_ENABLE beep:1
beeps SENSORS_W83782D_BEEPS beep:2
sensor1 SENSORS_W83782D_SENS1 sensor1:1
sensor2 SENSORS_W83782D_SENS2 sensor2:1
sensor3 SENSORS_W83782D_SENS3 sensor3:1
Chip `w83783s'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 2
in1 NONE NONE R 2
in2 NONE NONE R 2
in3 NONE NONE R 2
in4 NONE NONE R 2
in5 NONE NONE R 2
in6 NONE NONE R 2
in0_min in0 in0 RW 2
in1_min in1 in1 RW 2
in2_min in2 in2 RW 2
in3_min in3 in3 RW 2
in4_min in4 in4 RW 2
in5_min in5 in5 RW 2
in6_min in6 in6 RW 2
in0_max in0 in0 RW 2
in1_max in1 in1 RW 2
in2_max in2 in2 RW 2
in3_max in3 in3 RW 2
in4_max in4 in4 RW 2
in5_max in5 in5 RW 2
in6_max in6 in6 RW 2
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan3 NONE NONE R 0
fan1_min fan1 NONE RW 0
fan2_min fan2 NONE RW 0
fan3_min fan3 NONE RW 0
temp1 NONE NONE R 1
temp1_hyst temp1 temp1 RW 1
temp1_over temp1 temp1 RW 1
temp2 NONE NONE R 1
temp2_hyst temp2 temp2 RW 1
temp2_over temp2 temp2 RW 1
vid NONE NONE R 2
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
fan3_div fan3 NONE R 0
alarms NONE NONE R 0
beep_enable alarms NONE RW 0
beeps alarms alarms RW 0
sensor1 NONE NONE RW 0
sensor2 NONE NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
in0 SENSORS_W83783S_IN0 in0:3
in1 SENSORS_W83783S_IN1 in1:3
in2 SENSORS_W83783S_IN2 in2:3
in3 SENSORS_W83783S_IN3 in3:3
in4 SENSORS_W83783S_IN4 in4:3
in5 SENSORS_W83783S_IN5 in5:3
in6 SENSORS_W83783S_IN6 in6:3
in0_min SENSORS_W83783S_IN0_MIN in0:1
in1_min SENSORS_W83783S_IN1_MIN in1:1
in2_min SENSORS_W83783S_IN2_MIN in2:1
in3_min SENSORS_W83783S_IN3_MIN in3:1
in4_min SENSORS_W83783S_IN4_MIN in4:1
in5_min SENSORS_W83783S_IN5_MIN in5:1
in6_min SENSORS_W83783S_IN6_MIN in6:1
in0_max SENSORS_W83783S_IN0_MAX in0:2
in1_max SENSORS_W83783S_IN1_MAX in1:2
in2_max SENSORS_W83783S_IN2_MAX in2:2
in3_max SENSORS_W83783S_IN3_MAX in3:2
in4_max SENSORS_W83783S_IN4_MAX in4:2
in5_max SENSORS_W83783S_IN5_MAX in5:2
in6_max SENSORS_W83783S_IN6_MAX in6:2
fan1 SENSORS_W83783S_FAN1 fan1:2
fan2 SENSORS_W83783S_FAN2 fan2:2
fan3 SENSORS_W83783S_FAN3 fan3:2
fan1_min SENSORS_W83783S_FAN1_MIN fan1:1
fan2_min SENSORS_W83783S_FAN2_MIN fan2:1
fan3_min SENSORS_W83783S_FAN3_MIN fan3:1
temp1 SENSORS_W83783S_TEMP1 temp1:3
temp1_hyst SENSORS_W83783S_TEMP1_HYST temp1:2
temp1_over SENSORS_W83783S_TEMP1_OVER temp1:1
temp2 SENSORS_W83783S_TEMP2 temp2:3
temp2_hyst SENSORS_W83783S_TEMP2_HYST temp2:2
temp2_over SENSORS_W83783S_TEMP2_OVER temp2:1
vid SENSORS_W83783S_VID vid:1
fan1_div SENSORS_W83783S_FAN1_DIV fan_div:1
fan2_div SENSORS_W83783S_FAN2_DIV fan_div:2
fan3_div SENSORS_W83783S_FAN3_DIV fan_div:3
alarms SENSORS_W83783S_ALARMS alarms:1
beep_enable SENSORS_W83783S_BEEP_ENABLE beep:1
beeps SENSORS_W83783S_BEEPS beep:2
sensor1 SENSORS_W83783S_SENS1 sensor1:1
sensor2 SENSORS_W83783S_SENS2 sensor2:1
Miscellaneous documentation
===========================
/PROC ENTRIES
-------------
Varies depending on chip type. Most are identical to the lm78 entries.
See the lm78 documentation for details.
Additional entries not in the lm78:
pwm[1-4]: (not on w83781d nor as99127f)
Controls the speed of the fans with PWM (Pulse Width Modulation)
Valid values:
0 - 255. 255 = max speed.
Second value is PWM enable 0/1.
sensor[1-3]: (not on w83781d nor as99127f)
Controls the sensor type. To change to a different
sensor type, for example, do 'echo 2 > sensor1'.
Valid values:
1: Pentium II / Celeron diode
2: 2N3904 Transistor in a diode configuration
3435: Thermistor with Beta = 3435. Beta is a measure
of sensitivity to temperature.
Thermistors with other Betas could in theory be supported
after correspondence with Winbond. See below.
rt[1-3]: (w83781d only)
32-byte tables controlling the conversion from
resistance to temperature for thermistors.
For the curious only. Writing to these entries will
probably render temperature sensing insane.
Only set at initialization; not updated every 1.5 seconds.
TO DO:
-----
782d programmable pins
NOTES:
-----
783s has no in1 so that in[2-6] are compatible with the 781d/782d.
783s pin is programmable for -5V or temp1; defaults to -5V,
no control in driver so temp1 doesn't work.
782d and 783s datasheets differ on which is pwm1 and which is pwm2.
We chose to follow 782d.
782d and 783s pin is programmable for fan3 input or pwm2 output;
defaults to fan3 input.
If pwm2 is enabled (with echo 255 1 > pwm2), then
fan3 will report 0.
782d has pwm1-2 for isa, pwm1-4 for i2c. (pwm3-4 share pins with
the isa pins)
Data sheet updates:
------------------
- PWM clock registers:
000: master / 512
001: master / 1024
010: master / 2048
011: master / 4096
100: master / 8192
Answers from Winbond tech support
---------------------------------
>
> 1) In the W83781D data sheet section 7.2 last paragraph, it talks about
> reprogramming the R-T table if the Beta of the thermistor is not
> 3435K. The R-T table is described briefly in section 8.20.
> What formulas do I use to program a new R-T table for a given Beta?
>
We are sorry that the calculation for R-T table value is
confidential. If you have another Beta value of thermistor, we can help
to calculate the R-T table for you. But you should give us real R-T
Table which can be gotten by thermistor vendor. Therefore we will calculate
them and obtain 32-byte data, and you can fill the 32-byte data to the
register in Bank0.CR51 of W83781D.
> 2) In the W83782D data sheet, it mentions that pins 38, 39, and 40 are
> programmable to be either thermistor or Pentium II diode inputs.
> How do I program them for diode inputs? I can't find any register
> to program these to be diode inputs.
--> You may program Bank0 CR[5Dh] and CR[59h] registers.
CR[5Dh] bit 1(VTIN1) bit 2(VTIN2) bit 3(VTIN3)
thermistor 0 0 0
diode 1 1 1
(error) CR[59h] bit 4(VTIN1) bit 2(VTIN2) bit 3(VTIN3)
(right) CR[59h] bit 4(VTIN1) bit 5(VTIN2) bit 6(VTIN3)
PII thermal diode 1 1 1
2N3904 diode 0 0 0
Author/Maintainer
-----------------
Original 781D support: Frodo and Phil
782D/783S support added by: Mark D. Studebaker (mdsxyz123@yahoo.com)
Asus Clones
-----------
We have no datasheets for the Asus clones (AS99127F and ASB100 Bach).
Here are some very useful information that were given to us by Alex Van
Kaam about how to detect these chips, and how to read their values. He
also gives advice for another Asus chipset, the Mozart-2 (which we
don't support yet). Thanks Alex!
I reworded some parts and added personal comments.
# Detection:
AS99127F rev.1, AS99127F rev.2 and ASB100:
- I2C address range: 0x29 - 0x2F
- If register 0x58 holds 0x31 then we have an Asus (either ASB100 or
AS99127F)
- Which one depends on register 0x4F (manufacturer ID):
0x06 or 0x94: ASB100
0x12 or 0xC3: AS99127F rev.1
0x5C or 0xA3: AS99127F rev.2
Note that 0x5CA3 is Winbond's ID (WEC), which let us think Asus get their
AS99127F rev.2 direct from Winbond. The other codes mean ATT and DVC,
respectively. ATT could stand for Asustek something (although it would be
very badly chosen IMHO), I don't know what DVC could stand for. Maybe
these codes simply aren't meant to be decoded that way.
Mozart-2:
- I2C address: 0x77
- If register 0x58 holds 0x56 or 0x10 then we have a Mozart-2
- Of the mozart there are 3 types:
0x58=0x56, 0x4E=0x94, 0x4F=0x36: Asus ASM58 Mozart-2
0x58=0x56, 0x4E=0x94, 0x4F=0x06: Asus AS2K129R Mozart-2
0x58=0x10, 0x4E=0x5C, 0x4F=0xA3: Asus ??? Mozart-2
You can handle all 3 the exact same way :)
# Temperature sensors:
ASB100:
- sensor 1: register 0x27
- sensor 2 & 3 are the 2 LM75's on the SMBus
- sensor 4: register 0x17
Remark: I noticed that on Intel boards sensor 2 is used for the CPU
and 4 is ignored/stuck, on AMD boards sensor 4 is the CPU and sensor 2 is
either ignored or a socket temperature.
AS99127F (rev.1 and 2 alike):
- sensor 1: register 0x27
- sensor 2 & 3 are the 2 LM75's on the SMBus
Remark: Register 0x5b is suspected to be temperature type selector. Bit 1
would control temp1, bit 3 temp2 and bit 5 temp3.
Mozart-2:
- sensor 1: register 0x27
- sensor 2: register 0x13
# Fan sensors:
ASB100, AS99127F (rev.1 and 2 alike):
- 3 fans, identical to the W83781D
Mozart-2:
- 2 fans only, 1350000/rpm/div
- fan 1: register 0x28, divisor on register 0xA1 (bits 4-5)
- fan 2: register 0x29, divisor on register 0xA1 (bits 6-7)
# Voltages:
This is where there is a difference between AS99127F rev.1 and 2.
Remark: The difference is similar to the difference between
W83781D and W83782D.
ASB100:
in0=r(0x20)*0.016
in1=r(0x21)*0.016
in2=r(0x22)*0.016
in3=r(0x23)*0.016*1.68
in4=r(0x24)*0.016*3.8
in5=r(0x25)*(-0.016)*3.97
in6=r(0x26)*(-0.016)*1.666
AS99127F rev.1:
in0=r(0x20)*0.016
in1=r(0x21)*0.016
in2=r(0x22)*0.016
in3=r(0x23)*0.016*1.68
in4=r(0x24)*0.016*3.8
in5=r(0x25)*(-0.016)*3.97
in6=r(0x26)*(-0.016)*1.503
AS99127F rev.2:
in0=r(0x20)*0.016
in1=r(0x21)*0.016
in2=r(0x22)*0.016
in3=r(0x23)*0.016*1.68
in4=r(0x24)*0.016*3.8
in5=(r(0x25)*0.016-3.6)*5.14+3.6
in6=(r(0x26)*0.016-3.6)*3.14+3.6
Mozart-2:
in0=r(0x20)*0.016
in1=255
in2=r(0x22)*0.016
in3=r(0x23)*0.016*1.68
in4=r(0x24)*0.016*4
in5=255
in6=255
# PWM
* Additional info about PWM on the AS99127F (may apply to other Asus
chips as well) by Jean Delvare as of 2004-04-09:
AS99127F revision 2 seems to have two PWM registers at 0x59 and 0x5A,
and a temperature sensor type selector at 0x5B (which basically means
that they swapped registers 0x59 and 0x5B when you compare with Winbond
chips).
Revision 1 of the chip also has the temperature sensor type selector at
0x5B, but PWM registers have no effect.
We don't know exactly how the temperature sensor type selection works.
Looks like bits 1-0 are for temp1, bits 3-2 for temp2 and bits 5-4 for
temp3, although it is possible that only the most significant bit matters
each time. So far, values other than 0 always broke the readings.
PWM registers seem to be split in two parts: bit 7 is a mode selector,
while the other bits seem to define a value or threshold.
When bit 7 is clear, bits 6-0 seem to hold a threshold value. If the value
is below a given limit, the fan runs at low speed. If the value is above
the limit, the fan runs at full speed. We have no clue as to what the limit
represents. Note that there seem to be some inertia in this mode, speed
changes may need some time to trigger. Also, an hysteresis mechanism is
suspected since walking through all the values increasingly and then
decreasingly led to slightly different limits.
When bit 7 is set, bits 3-0 seem to hold a threshold value, while bits 6-4
would not be significant. If the value is below a given limit, the fan runs
at full speed, while if it is above the limit it runs at low speed (so this
is the contrary of the other mode, in a way). Here again, we don't know
what the limit is supposed to represent.
One remarkable thing is that the fans would only have two or three
different speeds (transitional states left apart), not a whole range as
you usually get with PWM.
As a conclusion, you can write 0x00 or 0x8F to the PWM registers to make
fans run at low speed, and 0x7F or 0x80 to make them run at full speed.
Please contact us if you can figure out how it is supposed to work. As
long as we don't know more, the w83781d driver doesn't handle PWM on
AS99127F chips at all.
* Additional info about PWM on the AS99127F rev.1 by Hector Martin:
I've been fiddling around with the (in)famous 0x59 register and
found out the following values do work as a form of coarse pwm:
0x80 - seems to turn fans off after some time(1-2 minutes)... might be
some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an
old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attempt at Qfan
that was dropped at the BIOS)
0x81 - off
0x82 - slightly "on-ner" than off, but my fans do not get to move. I can
hear the high-pitched PWM sound that motors give off at too-low-pwm.
0x83 - now they do move. Estimate about 70% speed or so.
0x84-0x8f - full on
Changing the high nibble doesn't seem to do much except the high bit
(0x80) must be set for PWM to work, else the current pwm doesn't seem to
change.
My mobo is an ASUS A7V266-E. This behaviour is similar to what I got
with speedfan under Windows, where 0-15% would be off, 15-2x% (can't
remember the exact value) would be 70% and higher would be full on.
* Additional info about PWM on the AS99127F rev.1 from lm-sensors
ticket #2350:
I conducted some experiment on Asus P3B-F motherboard with AS99127F
(Ver. 1).
I confirm that 0x59 register control the CPU_Fan Header on this
motherboard, and 0x5a register control PWR_Fan.
In order to reduce the dependency of specific fan, the measurement is
conducted with a digital scope without fan connected. I found out that
P3B-F actually output variable DC voltage on fan header center pin,
looks like PWM is filtered on this motherboard.
Here are some of measurements:
0x80 20 mV
0x81 20 mV
0x82 232 mV
0x83 1.2 V
0x84 2.31 V
0x85 3.44 V
0x86 4.62 V
0x87 5.81 V
0x88 7.01 V
9x89 8.22 V
0x8a 9.42 V
0x8b 10.6 V
0x8c 11.9 V
0x8d 12.4 V
0x8e 12.4 V
0x8f 12.4 V
doc/chips/w83792d
-298
View File
@@ -1,298 +0,0 @@
Kernel driver `w83792d.o'
=========================
Status: W83792D support is complete and well-tested.
Supported chips:
* Winbond W83792D
Prefix: 'w83792d'
Addresses scanned: I2C 0x2c - 0x2f
Datasheet: http://www.winbond.com.tw/E-WINBONDHTM/partner/PDFresult.asp?Pname=1035
Author: Chunhao Huang
Contact: DZShen <DZShen@Winbond.com.tw>
Module Parameters
-----------------
* init int
(default 1)
Use 'init=0' to bypass initializing the chip.
Try this if your computer crashes when you load the module.
* force_subclients=bus,caddr,saddr,saddr
This is used to force the i2c addresses for subclients of
a certain chip. Example usage is `force_subclients=0,0x2f,0x4a,0x4b'
to force the subclients of chip 0x2f on bus 0 to i2c addresses
0x4a and 0x4b.
Description
-----------
This driver implements support for the Winbond W83792AD/D.
Detection of the chip can sometimes be foiled because it can be in an
internal state that allows no clean access (Bank with ID register is not
currently selected). If you know the address of the chip, use a 'force'
parameter; this will put it into a more well-behaved state first.
The driver implements three temperature sensors, seven fan rotation speed
sensors, nine voltage sensors, and two automatic fan regulation
strategies called: Smart Fan I (Thermal Cruise mode) and Smart Fan II.
Automatic fan control mode is possible only for fan1-fan3. Fan4-fan7 can run
synchronized with selected fan (fan1-fan3). This functionality and manual PWM
control for fan4-fan7 is not yet implemented.
Temperatures are measured in degrees Celsius and measurement resolution is 1
degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
the temperature gets higher than the Overtemperature Shutdown value; it stays
on until the temperature falls below the Hysteresis value.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 or
128) to give the readings more range or accuracy. This driver modifies the
fan divisor automatically to get the reasonable RPM rotation range.
Voltage sensors (also known as IN sensors) report their values in volts.
An alarm is triggered if the voltage has crossed a programmable minimum
or maximum limit.
Alarms are provided as output from "realtime status register". Following bits
are defined:
bit - alarm on:
0 - in0
1 - in1
2 - temp1
3 - temp2
4 - temp3
5 - fan1
6 - fan2
7 - fan3
8 - in2
9 - in3
10 - in4
11 - in5
12 - in6
13 - VID change
14 - chassis
15 - fan7
16 - tart1
17 - tart2
18 - tart3
19 - in7
20 - in8
21 - fan4
22 - fan5
23 - fan6
Tart will be asserted while target temperature cannot be achieved after 3 minutes
of full speed rotation of corresponding fan.
In addition to the alarms described above, there is a CHAS alarm on the chips
which triggers if your computer case is open (This one is latched, contrary
to realtime alarms).
The chips only update values each 3 seconds; reading them more often will
do no harm, but will return 'old' values.
W83792D PROBLEMS
----------------
Known problems:
- This driver is only for Winbond W83792D C version device, there
are also some motherboards with B version W83792D device. The
calculation method to in6-in7(measured value, limits) is a little
different between C and B version. C or B version can be identified
by CR[0x49h].
- The function of vid and vrm has not been finished, because I'm NOT
very familiar with them. Adding support is welcome.
- The function of chassis open detection needs more tests.
- If you have ASUS server board and chip was not found: Then you will
need to upgrade to latest (or beta) BIOS. If it does not help please
contact us.
Chip Features
-------------
Chip `w83792d'
LABEL LABEL CLASS COMPUTE CLASS ACCESS MAGNITUDE
in0 NONE NONE R 3
in1 NONE NONE R 3
in2 NONE NONE R 3
in3 NONE NONE R 3
in4 NONE NONE R 3
in5 NONE NONE R 3
in6 NONE NONE R 3
in7 NONE NONE R 3
in8 NONE NONE R 3
in0_min in0 in0 RW 3
in1_min in1 in1 RW 3
in2_min in2 in2 RW 3
in3_min in3 in3 RW 3
in4_min in4 in4 RW 3
in5_min in5 in5 RW 3
in6_min in6 in6 RW 3
in7_min in7 in7 RW 3
in8_min in8 in8 RW 3
in0_max in0 in0 RW 3
in1_max in1 in1 RW 3
in2_max in2 in2 RW 3
in3_max in3 in3 RW 3
in4_max in4 in4 RW 3
in5_max in5 in5 RW 3
in6_max in6 in6 RW 3
in7_max in7 in7 RW 3
in8_max in8 in8 RW 3
fan1 NONE NONE R 0
fan2 NONE NONE R 0
fan3 NONE NONE R 0
fan4 NONE NONE R 0
fan5 NONE NONE R 0
fan6 NONE NONE R 0
fan7 NONE NONE R 0
fan1_min fan1 NONE RW 0
fan2_min fan2 NONE RW 0
fan3_min fan3 NONE RW 0
fan4_min fan4 NONE RW 0
fan5_min fan5 NONE RW 0
fan6_min fan6 NONE RW 0
fan7_min fan7 NONE RW 0
temp1 NONE NONE R 1
temp1_hyst temp1 temp1 RW 1
temp1_over temp1 temp1 RW 1
temp2 NONE NONE R 1
temp2_hyst temp2 temp2 RW 1
temp2_over temp2 temp2 RW 1
temp3 NONE NONE R 1
temp3_hyst temp3 temp3 RW 1
temp3_over temp3 temp3 RW 1
fan1_div fan1 NONE RW 0
fan2_div fan2 NONE RW 0
fan3_div fan3 NONE RW 0
fan4_div fan4 NONE RW 0
fan5_div fan5 NONE RW 0
fan6_div fan6 NONE RW 0
fan7_div fan7 NONE RW 0
LABEL FEATURE SYMBOL SYSCTL FILE:NR
in0 SENSORS_W83792D_IN0 in0:3
in1 SENSORS_W83792D_IN1 in1:3
in2 SENSORS_W83792D_IN2 in2:3
in3 SENSORS_W83792D_IN3 in3:3
in4 SENSORS_W83792D_IN4 in4:3
in5 SENSORS_W83792D_IN5 in5:3
in6 SENSORS_W83792D_IN6 in6:3
in7 SENSORS_W83792D_IN7 in7:3
in8 SENSORS_W83792D_IN8 in8:3
in0_min SENSORS_W83792D_IN0_MIN in0:1
in1_min SENSORS_W83792D_IN1_MIN in1:1
in2_min SENSORS_W83792D_IN2_MIN in2:1
in3_min SENSORS_W83792D_IN3_MIN in3:1
in4_min SENSORS_W83792D_IN4_MIN in4:1
in5_min SENSORS_W83792D_IN5_MIN in5:1
in6_min SENSORS_W83792D_IN6_MIN in6:1
in7_min SENSORS_W83792D_IN7_MIN in7:1
in8_min SENSORS_W83792D_IN8_MIN in8:1
in0_max SENSORS_W83792D_IN0_MAX in0:2
in1_max SENSORS_W83792D_IN1_MAX in1:2
in2_max SENSORS_W83792D_IN2_MAX in2:2
in3_max SENSORS_W83792D_IN3_MAX in3:2
in4_max SENSORS_W83792D_IN4_MAX in4:2
in5_max SENSORS_W83792D_IN5_MAX in5:2
in6_max SENSORS_W83792D_IN6_MAX in6:2
in7_max SENSORS_W83792D_IN7_MAX in7:2
in8_max SENSORS_W83792D_IN8_MAX in8:2
fan1 SENSORS_W83792D_FAN1 fan1:2
fan2 SENSORS_W83792D_FAN2 fan2:2
fan3 SENSORS_W83792D_FAN3 fan3:2
fan4 SENSORS_W83792D_FAN4 fan4:2
fan5 SENSORS_W83792D_FAN5 fan5:2
fan6 SENSORS_W83792D_FAN6 fan6:2
fan7 SENSORS_W83792D_FAN7 fan7:2
fan1_min SENSORS_W83792D_FAN1_MIN fan1:1
fan2_min SENSORS_W83792D_FAN2_MIN fan2:1
fan3_min SENSORS_W83792D_FAN3_MIN fan3:1
fan4_min SENSORS_W83792D_FAN4_MIN fan4:1
fan5_min SENSORS_W83792D_FAN5_MIN fan5:1
fan6_min SENSORS_W83792D_FAN6_MIN fan6:1
fan7_min SENSORS_W83792D_FAN7_MIN fan7:1
temp1 SENSORS_W83792D_TEMP1 temp1:3
temp1_hyst SENSORS_W83792D_TEMP1_HYST temp1:2
temp1_over SENSORS_W83792D_TEMP1_OVER temp1:1
temp2 SENSORS_W83792D_TEMP2 temp2:3
temp2_hyst SENSORS_W83792D_TEMP2_HYST temp2:2
temp2_over SENSORS_W83792D_TEMP2_OVER temp2:1
temp3 SENSORS_W83792D_TEMP3 temp3:3
temp3_hyst SENSORS_W83792D_TEMP3_HYST temp3:2
temp3_over SENSORS_W83792D_TEMP3_OVER temp3:1
fan1_div SENSORS_W83792D_FAN1_DIV fan_div:1
fan2_div SENSORS_W83792D_FAN2_DIV fan_div:2
fan3_div SENSORS_W83792D_FAN3_DIV fan_div:3
fan4_div SENSORS_W83792D_FAN4_DIV fan_div:4
fan5_div SENSORS_W83792D_FAN5_DIV fan_div:5
fan6_div SENSORS_W83792D_FAN6_DIV fan_div:6
fan7_div SENSORS_W83792D_FAN7_DIV fan_div:7
/PROC ENTRIES
-------------
Most are identical to the w83781d entries. See the w83781d documentation for
details.
Most of the additional entries not in the w83781d are Winbond Smart Fan I/II:
Please read "7.7 FAN Speed Count and FAN Speed Control" of W83792AD/D datasheet
before you read the explanation to the /proc entries below.
fan_cfg: indicates the fan speed control mode: 0 means PWM/DC mode,
1 means Smart Fan I(Thermal Cruise) mode, 2 or 3 means Smart Fan II
mode. There are three items in this entry, the first one is the
configuration of Fan1, the rest may be deduced by analogy.
pwm_flag: valid under PWM/DC mode, 1 means PWM mode, 0 means DC mode.
There are three items in this entry, the first one is PWM/DC mode
of Fan1, the rest may be deduced by analogy.
thermal_cruise: valid under Smart Fan I mode, indicates the wanted
temperature. There are three items in this entry, the first one
is setting temperature of Fan1, the rest may be deduced by analogy.
fan_tolerance: valid under Smart Fan I or Smart Fan II mode, indicates
the interval temperature. There are also three items in this entry.
sf2_points_fan1: valid under Smart Fan II mode, there are four items in
this entry, indicates the Temp.[1-4] in "Figure 8. Smart Fan II
behavior" to Fan1.
sf2_points_fan2: almost same as the above one, except that this entry
is for Fan2.
sf2_points_fan3: almost same as the above one, except that this entry
is for Fan3.
sf2_levels_fan1: valid under Smart Fan II mode, there are four items in
this entry, indicates the "Non-Stop Duty Cycle" and "Fan Duty Cycle
Level [1-3]" in "Figure 8. Smart Fan II behavior" to Fan1. The
first item "Non-Stop Duty Cycle" is read only in this driver, while
the other three items can be modified.
sf2_levels_fan2: almost same as the above one, except that this entry
is for Fan2.
sf2_levels_fan3: almost same as the above one, except that this entry
is for Fan3.
additional entries for chassis intrusion detection:
chassis: There are two items in this entry, the first one indicats the
chassis status, 1 means chassis intrusion detected, while 1 means
normal. The second item in this entry is used to clear the
detected chassis intrusion interrupt and reset the chassis status
to normal.
doc/chips/w83l785ts
-77
View File
@@ -1,77 +0,0 @@
Kernel driver `w83l785ts.o'
===========================
Status: Beta, slightly tested
Supported chips:
* Winbond W83L785TS-S
Prefix: 'w83l785ts'
Addresses scanned: I2C 0x2e
Datasheet: Publicly available at the Winbond USA website
http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83L785TS-S.pdf
Author: Jean Delvare <khali@linux-fr.org>
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_w83l785ts: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `w83l785ts' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
Description
-----------
The W83L785TS-S is a digital temperature sensor. It senses the
temperature of a single external diode. The high limit is
theoretically defined as 85 or 100 degrees C through a combination
of external resistors, so the user cannot change it. Values seen so
far suggest that the two possible limits are actually 95 and 110
degrees C. The datasheet is rather poor and obviously inaccurate
on several points including this one.
All temperature values are given in degrees Celsius. Resolution
is 1.0 degree. See the datasheet for details.
The w83l785ts driver will not update its values more frequently than
every other second; reading them more often will do no harm, but will
return 'old' values.
Known Issues
------------
On some systems (Asus), the BIOS is known to interfere with the driver
and cause read errors. The driver will retry a given number of times
(5 by default) and then give up, returning the old value (or 0 if
there is no old value). It seems to work well enough so that you should
not notice anything. Thanks to James Bolt for helping test this feature.
Chip Features
-------------
Chip 'w83l785ts'
LABEL LABEL CLASS COMPUTE CLASS MODE MAGN
temp - - R- 0
temp_high temp temp R- 0
LABEL FEATURE SYMBOL SYSCTL FILE:N
temp SENSORS_W83L785TS_TEMP temp:2
temp_high SENSORS_W83L785TS_TEMP_OVER temp:1
doc/chips/xeontemp
-108
View File
@@ -1,108 +0,0 @@
Kernel driver `xeontemp.o'
=========================
Status: Complete; tested for most devices except Xeon.
Supported chips:
* Intel Xeon and other processors
Prefix: 'xeontemp'
Addresses scanned: I2C 0x18, 0x1a, 0x29, 0x2b, 0x4c, 0x4e
Datasheets: Publicly available at the Intel website
See the adm1021 document for additional references
Authors: Frodo Looijaard <frodol@dds.nl>,Philip Edelbrock
<phil@netroedge.com>, and Mark D. Studebaker (mdsxyz123@yahoo.com)
License: GPL
Module Parameters
-----------------
* force: short array (min = 1, max = 48)
List of adapter,address pairs to boldly assume to be present
* force_xeontemp: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a `xeontemp' chip
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* read_only: int
Don't set any values, read only mode
Description
-----------
Many Xeons and other Intel processors have an embedded i2c temperature
sensor that look very similar to an adm1021 or max1617.
Some Xeons have honest to goodness, real live, actual MAX1617 chips on
them. Others Xeons made around the same time have other ADM1021
compatible chips on them. They are mounted on the CPU substrate along
with the processor information EEPROM that is part of that generation of
Xeon CPU's.
So it's basically impossible to tell a Xeon TEMP sensor from a MAX1617
since they are in fact the same chip. The Xeon Temperature sensors spec
is just a stripped down register spec for the ADM1021 that says the
"on-board" or "built-in" sensor registers are "reserved". That way
Intel could substitute whatever ADM1021 compatible chip was cheapest at
the time when they built the CPU's.
One reason to use the xeontemp driver is if, when Intel built your
particular Xeon's, they didn't use any of the ADM1021 compatible chips
that the ADM1021 driver recognizes. In that case, using the xeontemp
driver will get you the temperatures you want without potentially
messing up something in the sensor.
Another reason is to avoid having 'sensors' report the second
temperature.
Unfortunately, the 533MHz FSB Xeon's, dropped the on-board sensor chip.
So these new Xeons require a sensor on the motherboard to be connected
to the thermal diode to read the temperature. But these 533MHz capable
motherboards can also accept 400MHz CPU's with the on-board sensor so it
gets confusing in a hurry for motherboard vendors and users.
If you have 400MHz FSB P4 Xeon CPU's, you should have an on-CPU ADM1021
compatible sensor at 0x18 or 0x19. In that case, use the ADM1021 driver
if it detects a chip at that address. The CPU DIE temperature (Tj) will
be the "REMOTE" temperature from this sensor. The "Board" or "built-in"
temperature from the ADM1021 will be the temperature of the ADM1021
compatible itself which is one of the chips you see on the side of the CPU.
If you have sensors at 0x18 and 0x19 that are not detected by the
ADM1021, and you have 400MHz Xeons, then you may want to try the
xeontemp driver.
If you have 533MHZ FSB Xeons, then you do *not* have an on-board thermal
sensor and you should look for CPU temperatures from the other sensors
on your motherboard. (Winbond chip for example).
If you have an Intel Xeon processor, and sensors-detect recommended
the adm1021 driver, and the address is one of
0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e, and when using the
adm1021 driver, temp1 is invalid but temp2 looks correct, then
it is likely you should use the xeontemp driver instead.
If you have dual Xeons you may have appear to have two separate
adm1021-compatible chips, or two single-temperature sensors,
at distinct addresses.
In summary, the xeontemp module supports one temperature and the
adm1021 module supports two. Use the module that works best for you.
See the adm1021 documentation for more information.
Author/Maintainer
-----------------
Mark D. Studebaker (mdsxyz123@yahoo.com).
Derived from the adm1021 driver.
Thanks to Philip Pokorny for help with this document.
doc/developers/applications
+35 -124
View File
@@ -1,146 +1,53 @@
How to write applications which use our drivers
-----------------------------------------------
How to write applications which use the hwmon drivers
=====================================================
You have several choices in accessing sensor devices using the
drivers in our package. This document will briefly
describe these methods, their advantages and disadvantages,
and provide examples.
You have several choices in accessing sensor devices using the hwmon drivers.
This document will briefly describe these methods, their advantages and
disadvantages, and provide examples.
From lowest-level to the highest-level, the access methods are:
1) Character device access to the i2c bus driver
via /dev/i2c-x
2) I2C bus access functions as defined in kernel/include/i2c-dev.h
3A) /proc access to the chip device driver
3B) sysfs access to the chip device driver
4) libsensors library
5) sensors program
1. sysfs access
2. libsensors library
3. sensors program
Details:
1. Direct /dev access using ioctls
----------------------------------
Character device access to the i2c bus driver via ioctls on a /dev
device. This device could be i2cx, i2c-x, or i2c/x, where x is an
integer. The ioctls are defined in doc/dev-interface in the
i2c package or Documentation/i2c/dev-interface in the linux kernel
sources.
This method does not use a chip device driver at all.
However it does require the i2c-dev module.
The driver must set an individual chip address on the bus via
an ioctl, so it must use locking if multiple devices on the
bus are being accessed. No access is provided for non-i2c
busses such as ISA.
For good examples, see prog/detect/i2cdetect.c and
prog/detect/sensors-detect.
2. Direct /dev access using inline functions
--------------------------------------------
I2C bus access inline functions as defined in kernel/include/i2c-dev.h,
and in doc/dev-interface in the i2c package or
Documentation/i2c/dev-interface in the linux kernel sources.
Note that these used to be defined in <linux/i2c-dev.h> in the kernel
source tree. However, userspace applications are not supposed to
include kernel headers, so the inline functions were removed from
the kernel file in recent kernels. Use the header file in this package
instead.
This method does not use a chip device driver at all.
However it does require the i2c-dev module.
The driver must set an individual chip address on the bus via
an ioctl, so it must use locking if multiple devices on the
bus are being accessed. No access is provided for non-i2c
busses such as ISA.
For good examples, see prog/detect/i2cdetect.c,
prog/dump/i2cdump.c, and prog/dump/i2cset.c.
3A. /proc access (2.4 kernels)
-----------------------------
Chip drivers using the i2c-proc module create subdirectories in
/proc/sys/dev/sensors which can be accessed directly by applications.
1. sysfs access
---------------
Hwmon drivers create subdirectories in the sysfs filesystem (usually /sys)
which can be accessed directly by applications.
Naming and content standards for the entries in these subdirectories
is documented in the file doc/developers/proc. Note that these
standards may not be strictly followed.
If a new driver adheres to these standards then an application may
be able to support new devices on-the-fly.
/proc access provides a method to read and write sensor values
for any driver using i2c-proc, including ISA chip drivers.
This method also works well for shell and perl scripts
written to access a specific device. Note that i2c-proc is
standard in the kernel as of kernel 2.4.13.
Note that most drivers provide only raw sensor readings via /proc;
many readings must be scaled or adjusted, and these adjustments
must often be changed by the user. An application using /proc must
generally provide adjustment facilities and the requirements
of the adjustments can be quite complex. If you need adjustment
facilities, consider the libsensors library, below.
For examples of programs using /proc accesses, see
prog/eeprom/decode-dimms.pl, prog/matorb/displayit.pl,
prog/maxilife/writelcd.sh, prog/rrd/sens_update_rrd,
prog/pwm/fancontrol, and prog/pwm/pwmconfig.
Also search freshmeat for sensors applications.
3B. sysfs access (2.6 kernels)
------------------------------
Chip drivers using the hwmon module create subdirectories in
the sysfs filesystem (usually /sys) which can be accessed
directly by applications.
Naming and content standards for the entries in these subdirectories
is documented in the file Documentation/hwmon/sysfs-interface in the
2.6 kernel source tree. Note that these standards may not be
strictly followed.
If a new driver adheres to these standards then an application may
be able to support new devices on-the-fly.
sysfs access provides a method to read and write sensor values
for any driver, including ISA chip drivers.
This method may also work well for shell and perl scripts
written to access a specific device. Note that sysfs is
standard in 2.6 kernels.
are documented in the file Documentation/hwmon/sysfs-interface in the 2.6
kernel source tree. sysfs is the lowest-level access to sensor values.
Note that most drivers provide only raw sensor readings via /sys;
many readings must be scaled or adjusted, and these adjustments
must often be changed by the user. An application using /sys must
generally provide adjustment facilities and the requirements
of the adjustments can be quite complex. If you need adjustment
facilities, consider the libsensors library, below.
of the adjustments can be quite complex. For this reason, this
approach isn't recommended. Instead, consider the libsensors library,
which offers a higher-level interface on top of sysfs (see below.)
For an example of a program using /sys accesses, see gkrellm.
See also lib/proc.c and prog/dump/i2cbusses.c for examples.
The sysfsutils package may also be helpful.
Also search freshmeat for sensors and sysfs applications.
Still, this method may work well for shell and perl scripts written to
access a specific device.
For an example of a program using /sys accesses, see gkrellm (though
recent versions use libsensors instead.) See also lib/sysfs.c.
4. libsensors library
2. libsensors library
---------------------
The libsensors library provides standardized access to all chip drivers.
It also provides a translation layer with settings in /etc/sensors.conf
so that your application sees adjusted (scaled) values using settings
provided by the user. Other facilities are sensor renaming, limit setting,
and ignoring individual sensors.
The libsensors library supports both 2.4 and 2.6 kernels.
provided by the user. Other facilities are sensor labelling, limit setting,
and ignoring individual sensors. This is the recommended way to access
the sensor chips.
Unfortunately there is little documentation for libsensors. See the
'sensors' application in prog/sensors for an example. The source
for libsensors is in the lib/ directory. Another example
is in prog/sensord. Also search freshmeat for sensors applications.
One other limitation of libsensors is that it is relatively
cumbersome to add support for new devices.
The library API is documented in the libsensors(3) manual page. The
configuration file format is documented in the sensors.conf(5) manual
page.
Note that libsensors falls under the GPL, not the LGPL.
In more human language, that means it is FORBIDDEN to link any application
@@ -148,12 +55,16 @@ Details:
does not fall under the GPL. This may or may not be changed in the future.
Contact us if you wish to discuss your application.
For an example of a program using libsensors accesses, see
prog/sensors/sensors. Also search freshmeat for sensors applications.
For examples of programs using libsensors accesses, see prog/sensors and
prog/sensord.
5. sensors program
3. sensors program
------------------
The 'sensors' program is a text-based application that uses libsensors.
The output is fairly standardized; therefore this output could be
used by other applications.
One simple method is 'sensors|grep ALARM'.
Note though that there is no guarantee that the output format won't change
in the future, so be careful. We might improve the command-line interface
of 'sensors' someday to make it more convenient for external programs to
use it as a back-end.
doc/developers/design
-550
View File
@@ -1,550 +0,0 @@
This is a design for version 2 of our smbus and lm_sensors module. This
document is Copyright (c) 1998, 1999 by Frodo Looijaard. You may freely copy and
distribute it, as long as you recognize me as the author, and mark any
changes you make as being your own, and distribute this notice with it.
Document version 1.0, 19981101.
1.1, 19981111.
1.2, 19981118.
1.3, 19981126.
NOTE: THIS IS BY NOW SOMEWHAT OUTDATED. SORRY.
Object oriented approach
========================
The i2c module structs contain callback functions and data fields. In the
i2c module, these structures are only referenced by pointers. This makes
it easy to extend these structs to contain additional information or
callback functions. For those familiar with object oriented languages,
you can see the smbus and isa structures as an object extension of the i2c
structures.
To make this clearer, I will show in an example how this is done. Note
that I have simplified some things here, so this example does not
correspond to an actual struct found in one of the modules.
In the i2c module, you can find a struct somewhat like this:
struct i2c_adapter {
char name[32];
int (*detach_client) (struct i2c_client *);
struct i2c_adapter *next;
}
We have a plain data field (name), a call-back function which needs one
parameter (a pointer to a i2c_client struct), and a data field which is
a pointer to the next adapter.
Now we want to extend this structure. We need another data field,
containing a number of flags. We will call this new structure smbus_adapter.
A few other things change too:
struct smbus_adapter {
char name[32];
int (*detach_client) (struct smbus_client *);
struct smbus_adapter *next;
unsigned int flags;
}
So we copy all existing fields. The next field still points to the next
adapter - but it is now of type smbus_adapter, not i2c_adapter. And the
call-back function takes now a parameter of type pointer to smbus_client.
And there is a new data field, called flags.
Now examine this function definition:
int fully_detach_i2c_client (struct i2c_client * client)
{
res = 0;
struct i2c_adapter *current_adapter = first_adapter; /* a global var. */
while (current_adapter) {
res |= (current_adapter -> detach_client) (client);
current_adapter = current_adapter -> next;
}
return res;
}
This function detaches a client from all adapters. Nice. But now comes the
Big Trick(tm): we can still use this function for smbus_adapters!
int fully_detach_smbus_client (struct smbus_client * client)
{
return fully_detach_i2c_client( (struct i2c_client *) client);
}
All we needed here was a simple typecast. Datapointers remain datapointers,
so this can safely be done. And because we use call-back functions, the
actual function called to detach a client from a single adapter might
be the same, or different, depending on what function was put in
client->detach_client!
It gets even better. The i2c module stores internally all registered
adapters. But it stores pointers to the i2c_adapter struct, not the
structs themselves! So there is an array:
#define I2C_ADAPTER_MAX 32
struct i2c_adapter *adapters[I2C_ADAPTER_MAX];
/* this is an array of pointers to structs, not vice versa! */
So, an element of this array might in fact point to a smbus_adapter, instead
of an i2c_adapter! If you know this for sure, you might use a typecast and
access the additional fields. In the meantime, the i2c internal
administration remains valid.
We have to thank Simon Vogl and Gerd Knorr for the way they implemented
their i2c module. Any other way would have made this approach impossible,
and basing anything upon their module much more difficult.
Limitations
-----------
Extending the adapter and algorithm structures in this way is quite safe.
They are only allocated on places where the code knows that they are
'special'. Extending the driver or client structures depending on a
specific adapter/algorithm type is *very* *dangerous*. A driver/client
module would need to be aware of every special adapter/algorithm in
order to allocate itself! For the ISA bus, it has to be aware of this
anyway, so it is safe to do; on other places, think twice first!
Module overview
===============
All in all, lots of modules will be stacked on each other. Too bad, but
that is the only way to cleanly implement everything. Note that in a
specific situation, only a few modules may need to be loaded. isa.o,
for example, does not depend on smbus.o (in the sense that you can load
sensor.o without loading smbus.o). A specific bus driver, though, will
depend on many of them.
Generally:
isa.o depends on nothing (actually, on i2c.o, to keep the code small)
smbus.o depends on nothing (actually, on i2c.o, to keep the code small)
i2c.o depends on nothing.
A non-i2c SMBus bus driver depends only on smbus.o
A i2c bus driver depends only on i2c.o
A sensor chip driver depends either on isa.o or smbus.o, or both.
A SMBus chip driver depends only on smbus.o
A I2C chip driver depends only on i2c.o
We may need a sensor.o module, to act as a central point for sensor
modules. At this moment, it seems not really necessary, but this may
change.
We will need an enhanced i2c-dev.o module, to add SMBus access to I2C
/dev entries.
isa.o
ISA bus handling.
Encapsulates ISA bus access within the i2c structures.
Unites I2C adapters and the ISA bus.
Defines variables isa_algorithm and isa_adapter.
smbus.o
Main SMBus handling.
Encapsulates SMBus access within the smbus structures.
Unites I2C adapters and SMBus hosts (like the PIIX4).
Emulates SMBus access on pure I2C adapters.
Defines variable smbus_algorithm.
piix4.o
SMBus adapter driver for the PIIX4 SMBus host.
Defines variable piix4_adapter (based on smbus_algorithm).
FOO.o
Adapter driver for FOO SMBus host
Defines variable FOO_adapter (based on smbus_algorithm).
i2c-core.o (From Simon Vogl)
Main i2c handling.
????.o
I2C adapter driver
Implementing a class of I2C busses
A chip driver (typically defined in its own module) can be hooked on all
these levels:
* If it is a sensor chip, it should be hooked to isa.o or smbus.o
* A pure ISA chip should be hooked to isa.o
* A pure SMBus chip should be hooked to smbus.o
* An I2C chip should be hooked to i2c.o
It can be difficult to decide whether a specific chip should be hooked to
smbus.o or i2c.o. A good deciding question is, 'could it be connected to
a PIIX4?'
Module i2c.o
============
This is Simon Vogl's i2c module (this one is different from the i2c module
included in kernels around 2.1.120!).
A driver
--------
struct i2c_driver {
char name[32];
int id;
unsigned int flags;
int (* attach_adapter) (struct i2c_adapter *);
int (* detach_client) (struct i2c_client *);
int (* command) (struct i2c_client *, unsigned int cmd, void *arg);
void (* inc_use) (struct i2c_client *);
void (* dec_use) (struct i2c_client *);
}
A driver tells us how we should handle a specific type of i2c chip. An
instance of such a chip is called a 'client'. An example would be the LM75
module: it would contain only one driver, which tells us how to handle the
LM75; but each detected LM75 would be a separate client (which would be
dynamically allocated).
A description of the above struct:
name: The name of this driver
id: A unique driver identifier
flags: Flags to set certain kinds of behaviour. Most notably, DF_NOTIFY
will notify the driver when a new i2c bus is detected, so it can
try to detect chips on it.
attach_adapter: A call-back function which is called if a new adapter (bus)
is found. This allows us to do our detection stuff on the new adapter,
and register new clients.
detach_client: A call-back function which is called if a specific client
which uses this driver should be disallocated. If a specific sensor module
is removed, for instance, this function would be called for each registered
client.
command: A generic call-back function to communicate in a driver-dependent
way with a specific client. This should only be seldom needed.
inc_use: Can be called to add one to an internal 'use' counter. This can be
used to control when it is safe to remove this module, for example.
A client
--------
struct i2c_client {
char name[32];
int id;
unsigned int flags;
unsigned char addr;
struct i2c_adapter *adapter;
struct i2c_driver *driver;
void *data;
}
A client is a specific sensor chip. Its operation is controlled by a driver
(which describes a type of sensor chip), and it is connected to an adapter
(a bus).
A description of the above struct:
name: The name of this client
id: A unique client id
flags: Flags to set certain kinds of behaviour (not very important)
addr: The client address. 10-bit addresses are a bit of a kludge right now.
adapter: A pointer to the adapter this client is on.
driver: A pointer to the driver this client uses.
data: Additional, client-dependent data
An algorithm
------------
struct i2c_algorithm {
char name[32];
unsigned int id;
int (* master_xfer) (struct i2c_adapter *adap, struct i2c_msg msgs[],
int num);
int (* slave_send) (struct i2c_adapter *,char *, int);
int (* slave_recv) (struct i2c_adapter *,char *, int);
int (* algo_control) (struct i2c_adapter *, unsigned int, unsigned long);
int (* client_register) (struct i2c_client *);
int (* client_unregister) (struct i2c_client *);
}
An algorithm describes how a certain class of i2c busses can be accessed.
A description of the above struct:
name: The name of this algorithm
id: A unique algorithm id
master_xfer: Transfer a bunch of messages through a specific i2c bus.
slave_send: Send a message as if we are a slave device
slave_recv: Receive a message as if we are a slave device
client_register: Register a new client
client_unregister: Unregister a client
An adapter
----------
struct i2c_adapter {
char name[32];
unsigned int id;
struct i2c_algorithm *algo;
void *data;
#ifdef SPINLOCK
spinlock_t lock;
unsigned long lockflags;
#else
struct semaphore lock;
#endif
unsigned int flags;
struct i2c_client *clients[I2C_CLIENT_MAX];
int client_count;
int timeout;
int retries;
}
An adapter is a specific i2c bus. How to access it is defined in the
algorithm associated with it.
A description of the above struct:
name: The name of this adapter
id: A unique adapter id
algo: The algorithm through which this bus must be accessed
data: Adapter specific data
lock, lockflags: To lock out simultaneous adapter access
flags: Modifiers for adapter operation
clients: All currently connected clients
client_count: The number of currently connected clients
timeout, retries: Internal variables (unimportant here).
Access functions
----------------
All these functions are defined extern.
int i2c_master_send(struct i2c_client *,const char *, int);
int i2c_master_recv(struct i2c_client *,char *, int);
int i2c_transfer(struct i2c_adapter *,struct i2c_msg [], int num);
These function respectively send one message to a client, receive one message
from a client, or transmit a bunch of messages. struct i2c_msg contains
an i2c address to communicate with, and can both read from and write to this
address.
int i2c_slave_send(struct i2c_client *, char *, int);
int i2c_slave_recv(struct i2c_client *, char *, int);
Communicate with another master as if the normal master is a common slave
device.
Administration functions
------------------------
int i2c_add_algorithm(struct i2c_algorithm *);
int i2c_del_algorithm(struct i2c_algorithm *);
The i2c_{add,del}_algorithm functions must be called whenever a new module
is inserted with this driver in it, by the module initialization function.
int i2c_add_adapter(struct i2c_adapter *);
int i2c_del_adapter(struct i2c_adapter *);
The i2c_{add,del}_adapter functions must be called if you have detected
a specific bus. It triggers driver->attach_adapter (add, for each driver
present) or driver->detach_client (del, for each registered client on
this adapter).
int i2c_add_driver(struct i2c_driver *);
int i2c_del_driver(struct i2c_driver *);
The i2c_{add,del}_driver functions must be called whenever a new module is
inserted with a chip driver in it, by the module initialization function.
int i2c_attach_client(struct i2c_client *);
int i2c_detach_client(struct i2c_client *);
The i2c_{attach,detach}_client functions must be called if you have detected
a single chip.
Module smbus.o
==============
This module offers support for SMBus operation. An SMBus adapter can either
accept SMBus commands (like the PIIX4), or be in fact an I2C driver. In
the last case, all SMBus commands will be expressed through I2C primitives.
This means that any I2C adapter driver will automatically be a SMBus
driver.
At this point, it should be noted that there can only be one System
Management Bus in a given system (is this really true, by the way?). This
means there must be some way of selecting which of the many possible adapters
is in fact *the* SMBus. For now, I will ignore this problem. Later on,
we can add a hook somewhere in the i2c module to help us decide this.
This module consists in fact of three separate parts: first of all, it extends
all i2c structs to accomodate the new smbus fields. Second, it defines a
new algorithm (smbus_algorithm), that will be used by all non-i2c adapters.
Finally, it implements a new access function that sends or receives SMBus
commands; these are either translated into I2C commands or sent to the
SMBus driver.
A driver, client and algorithm
------------------------------
We will not need to extend i2c_driver, i2c_client or i2c_adapter. This means
that struct smbus_driver is exactly the same as struct i2c_driver, and
struct smbus_client is the same as struct i2c_client, and smbus_adapter is
the same as struct i2c_adapter. We *will* define the smbus_* variants, and
use them within this module, so it should be easy to extend them after all.
Note that at this moment, 10 bit SMBus addresses seem to be only
partially supported by the i2c module. We will ignore this issue for
now.
An adapter
------------
struct smbus_adapter {
char name[32];
unsigned int id;
struct smbus_algorithm *algo;
void *data;
#ifdef SPINLOCK
spinlock_t lock;
unsigned long lockflags;
#else
struct semaphore lock;
#endif
unsigned int flags;
struct smbus_client *clients[I2C_CLIENT_MAX];
int client_count;
int timeout;
int retries;
/* Here ended i2c_adapter */
s32 (* smbus_access) (__u8 addr, char read_write,
__u8 command, int size, union smbus_data * data);
}
A description of the above struct:
smbus_access: A function to access the SMBus. It is only used for non-i2c
smbus adapters.
Access functions
----------------
All these functions are defined extern.
The i2c access function should not be used within SMBus chip drivers, as
they might not be defined (for the PIIX4, for example). Instead, use the
following general access function, or one of the easier functions based
on it:
int smbus_access (struct i2c_adapter *, __u8 addr, char read_write,
__u8 command, int size, union smbus_data * data);
There are specific SMBus registration functions too, like the i2c ones.
They are fully compatiable with each other; just substitute 'smbus' for
'i2c' everywhere in the i2c description.
int i2c_is_smbus_client(struct i2c_client *);
int i2c_is_smbus_adapter(struct i2c_adapter *);
Decide whether this client, or adapter, is (on) a non-I2C SMBus. Usually
not needed, but it is nice anyway to be able to decide this.
Module isa.o
============
This module implements a new algorithm and a specific adapter for the
(single) ISA bus in your computer. This makes writing drivers for chips
that can be both on ISA and SMBus much easier.
Note that this module does *not* in any way depend on smbus.o (previous
versions of this document still assumed it would be build upon it; this
is no longer true).
A driver, adapter or algorithm
------------------------------
We will not need to extend i2c_driver, i2c_adapter or i2c_algorithm. This
means that struct isa_driver is exactly the same as struct i2c_driver,
struct isa_adapter is the same as struct i2c_adapter and struct isa_algorithm
is the same as struct isa_driver. We *will* define the isa_* variants, and
use them within this module, so it should be easy to extend them after all.
A client
--------
struct isa_client {
char name[32];
int id;
unsigned int flags;
unsigned char addr;
struct isa_adapter *adapter;
struct isa_driver *driver;
void *data;
unsigned int isa_addr;
}
A client is a specific sensor chip. Its operation is controlled by a driver
(which describes a type of sensor chip), and it is connected to an adapter
(a bus, the (single) ISA bus here).
A description of the above struct:
isa_addr: ISA addresses do not fit in the i2c-compatible addr field, so
we needed a new field.
Access functions
----------------
All these functions are defined extern.
In case of the ISA bus, the master_xfer, slave_send and slave_recv hooks
will be NULL, because these functions make no sense. It is regrettably
not easy to create an access abstraction in which both ISA bus access
and SMBus access are united. See below for examples how you can solve
this problem.
The most imporant additional access function:
int i2c_is_isa_client(struct i2c_client *);
int i2c_is_isa_adapter(struct i2c_adapter *);
Decide whether this client, or adapter, is (on) the ISA bus. This is
important, because it determines whether we can use the SMBus access
routines.
As an example, I will here implement our old LM78 access function:
/* The SMBus locks itself, but ISA access must be locked explicitly!
We ignore the LM78 BUSY flag at this moment - it could lead to deadlocks,
would slow down the LM78 access and should not be necessary.
There are some ugly typecasts here, but the good new is - they should
nowhere else be necessary! */
int lm78_read_value(struct i2c_client *client, u8 reg)
{
int res;
if (i2c_is_isa_client(client)) {
down((struct semaphore *) (client->data));
outb_p(reg,(((struct isa_client *) client)->isa_addr) +
LM78_ADDR_REG_OFFSET);
res = inb_p((((struct isa_client *) client)->isa_addr) +
LM78_DATA_REG_OFFSET);
up((struct semaphore *) (client->data));
return res;
} else
return smbus_read_byte_data(client->adapter,client->addr, reg);
}
doc/developers/lm_sensors.lsm
+18
View File
@@ -0,0 +1,18 @@
Begin4
Title: lm_sensors
Version: 3.0.3
Entered-date: 2008-09-28
Description: Hardware health monitoring package for Linux. It consists of
a library to allow applications to read sensors data more
easily, and of an example program to pretty print this data.
Also included is a fan speed control script.
http://www.lm-sensors.org/
Keywords: sensors health hardware-monitoring fan-speed
Author: khali@linux-fr.org (Jean Delvare)
Maintained-by: khali@linux-fr.org (Jean Delvare)
Primary-site: http://dl.lm-sensors.org /lm-sensors/releases/
lm_sensors-3.0.3.tar.bz2
lm_sensors-3.0.3.tar.bz2.sig
Alternate-site: ftp.netroedge.com /pub/lm-sensors/
Copying-policy: GPL
End
doc/developers/makefiles
+5 -18
View File
@@ -9,24 +9,15 @@ included files are called 'Module.mk'.
There are several interesting targets defined through this Makefile:
* all
Create everything in all directories.
* user
Build only user-space tools.
* install
Install everything from all directories.
* user_install
Install only user-space tools.
* user_uninstall
Uninstall user-space tools.
* uninstall
Uninstall everything.
* clean
Remove anything which can be regenerated from all directories. A call
of 'make clean' (without any other targets) will ignore any .d files;
this is useful when they are out of date (and prevent the calling of
any other target).
* version
Regenerate version.h, using the current date for the date-stamp, and
a user-supplied version number.
* package
Create a .tar.gz file containing everything except the SVN directories.
The best way to understand the Module.mk subfiles is to examine one of them,
for example lib/Module.mk. They are not too difficult to understand.
@@ -43,25 +34,21 @@ ones for developers:
only output more information, and never make the code mis-behave.
Several files are generated by Makefiles:
* .d
Dependency files for modules. Automatically generated.
* .rd
Dependency files for executables. Automatically generated.
* .ad
Dependency files for static libraries. Automatically generated.
* .ld
Dependency files for shared libraries. Automatically generated.
* .o
Generated modules
* .ro
Object files for executables. They will be linked together to create
the executable. This extension is used to distinguish them from
modules (which end on .o). Also, using a different extensions makes
the Makefile fragments much simpler.
the executable.
* .ao
Object files for static libraries
* .lo
Object files for shared libraries
The reason for using different extensions is to make the Makefile much
simpler.
There are lots of comments within the main Makefile. Please read them if
you want to know more.
doc/developers/new_drivers
-191
View File
@@ -1,191 +0,0 @@
These are the steps you should follow to write a new driver and
submit it to us so that it will be applied cleanly to our package.
See at the bottom for adding new chip support to an existing driver.
Don't be intimidated by the list, it's just here so we don't
forget anything.
We are more than happy to help you with any part of the process.
There are two types of drivers, chip and bus.
Steps which apply to only one type of driver are noted.
These instructions are for 2.4-kernel-compatible drivers.
If you wish to write a driver for 2.6 only, not all of the following
steps apply.
---------------------------------------------------------------------
* Check our "New Drivers" page for status!!
* Contact us.
You are of course free to write your own drivers, but it is smart to
check first nobody else is already working on it, in case the
New Drivers page is out of date.
Tell us it's OK to put your name on the "New Drivers" page.
* Consider subscribing to the mailing list.
* Check out our latest code from SVN.
You should use this as a base for your development.
See instructions on our download page.
* Write the new driver.
If you write a driver for a device that is similar to one we already
support, use the other device driver as a template. If you don't know
which one to use, either ask us or use the following defaults.
For a chip driver, use lm78.c as template. For an SMBus-only adapter,
use i2c-piix4.c. Use i2c-via.c for an I2C-level adapter ('bit banger').
Usually, we make all prefixes start with the driver name. This is not
really necessary, as these symbols will not be exported anyway. But by
doing this, you are sure you do not shadow any global kernel names.
* A quick note about conversions. The conversions which are specified
in the sensor chip datasheet and which *cannot* vary from one board to
the next are performed by the driver. If other conversions are
necessary, they are performed in user-space.
* Meet Kernel coding standards.
See Documentation/CodingStyle in the kernel source.
Be sure and use 8 column tabs.
Also, please do not use // comments.
Also, please do not go past column 80.
Also, please use C99 struct initializers {.foo = blat}
Please do this _before_ you check in your driver.
* Meet /proc naming standards in the ctl_table (for chip drivers only).
See doc/developers/proc for information. Please do not deviate from
this without discussion.
* Add the driver to the Module.mk (the makefile).
Usually, you can just add it to KERNEL{CHIPS,DRIVERS}TARGETS in the
Module.mk file in the directory itself. Put it at the beginning,
where the comment says to put drivers NOT included in mkpatch.
* Make sure it compiles cleanly.
Check compilation with 'make DEBUG=1' if you use debugging
information. Remember, things put between #ifdef DEBUG #endif may never
stop the driver from functioning; they should just output additional
information.
* Check for external symbols.
'nm --extern --defined' should only output symbols starting with __module,
cleanup_module, init_module and some kernel versioning symbols. Mark all
other symbols as static in your source file.
* Test the module.
Test with a recent 2.4 kernel.
For bus drivers, use i2cdetect and i2cdump. For i2cdump, test all supported
bus access modes (see i2cdump man page).
For chip drivers, cat all files in applicable /proc or /sys directory
and check for problems. Write all supported settings.
Check ALARM indications.
* Add detection information to prog/detect/sensors-detect.
This is a perl script that automatically detects what chips and adapters
are present. Contact us if you need help.
* Add chip information to lib/chips.{c,h} (for chip drivers only).
Until you have done this, the chip will be invisible for user-level
programs which use libsensors. Use standard names in lib/chips.c;
see also the comments in etc/sensors.conf.eg for help.
Contact us if you need more assistance.
* Be sure that SYSCTL and ALARM definitions in the driver are bracketed
by the special comments so that the kernel/include/sensors.h
file, which is generated automatically, contains your definitions.
(for chip drivers only)
* Add a procedure to prog/sensors/chips.[ch] (for chip drivers only).
This is a function specific for your driver that
makes the included 'sensors' program pretty-print your chip information.
* Add an line for the procedure in the matches[] table in
prog/sensors/main.c (for chip drivers only).
This tells sensors to call your new procedure when the chip name matches.
* Add entries to etc/sensors.conf.eg (for chip drivers only).
If needed, you can set defaults here.
* Test the userspace apps (sensors-detect and sensors).
Test setting limits with sensors -s.
* Add the name of the device to the README file.
* Add your name to the CONTRIBUTORS file.
* Add entries to the CHANGES file. Please keep in alphabetical order.
* Write a doc/chips/xxx or doc/busses/xxx file.
* Add entry to doc/chips/SUMMARY (for chip drivers only).
* Clearly specify licensing and copyright.
Make sure the GPL boilerplate and your name
(or if applicable your company's name) is at the top of the
new driver so we know you are giving it to us under the GPL.
* Submit the changes to us.
Do a 'svn update' to get in sync (things will have changed since
you started), then submit the changes to us as a patch against SVN.
* If you want to have your driver integrated to Linux 2.6, you have to
port your driver to the new sysfs interface. Once done and preferably
after testing, submit a patch to our mailing list: see
http://www.lm-sensors.org/wiki/AuthorsAndContributors
Make sure to check the current status for your driver first:
http://www.lm-sensors.org/wiki/Kernel2.6
http://www.lm-sensors.org/wiki/Devices
---------------------------------------------------------------------
Checklist for us to do on the webpage:
* Add entry to 'supported drivers' page
* Update entry on 'new drivers' page
---------------------------------------------------------------------
Checklist for mkpatch support, after the driver is tested and stable:
* Add .c file to mkpatch/FILES.
* Add makefile entry in mkpatch/mkpatch.pl (2 places - old and new formats).
(don't bother with old format, obsolete)
* Add config help to mkpatch/mkpatch.pl.
* Add config entry to mkpatch/Config.in (chip drivers only)
* Add config entry in mkpatch/mkpatch.pl (bus drivers only)
* Move .o reference in kernel/[chips,busses]/Module.mk
from first to second section.
---------------------------------------------------------------------
Checklist for _adding_ support for a chip to an _existing_ driver:
* Make the changes to the driver itself.
* Add detection information to prog/detect/sensors-detect.
* Add a strncmp() call for the new prefix in prog/sensors/main.c
(chip drivers only).
* Add entries for the new prefix to etc/sensors.conf.eg (chip drivers only).
* Update config help in mkpatch/mkpatch.pl.
* Update config entry in mkpatch/Config.in (chip drivers only)
* Update config entry in mkpatch/mkpatch.pl (bus drivers only)
* Update doc/[chips,busses]/xxx file
* Update doc/chips/SUMMARY file (chip drivers only)
* Update list in README
* Submit the changes as a patch or check them in
* Update entry on 'new drivers' page
doc/developers/proc
-145
View File
@@ -1,145 +0,0 @@
Naming and data format standards under /proc
--------------------------------------------
The libsensors library offers an interface to the raw sensors data
through the sysctl interface. See the doc/developers/sysctl
and the libsensors source for further information.
An alternative method that some programs use is to access the /proc
files directly. This document briefly describes the standards that
the drivers follow, so that an application program can scan for
entries and access this data in a simple and consistent way.
Note that not all chip drivers adhere to this standard.
We will attempt to migrate older drivers to this standard,
and ensure that new drivers follow this standard wherever possible.
If you are developing a userspace application please send us
feedback on this standard.
Note that motherboards vary widely in the connections to sensor chips.
There is no standard that ensures, for example, that the second
temperature sensor is connected to the CPU, or that the second
fan is on the CPU. Therefore, programs must provide a facility
for the user to label or bind /proc entries for display.
Sensor chips often have unused inputs that should be ignored
by user programs.
Each chip gets its own directory under /proc/sys/dev/sensors.
The format is either chip-i2c-bus-hexaddress or chip-isa-hexaddress.
(Exception - chip lm78-j has a '-' in it - should this be changed??)
New dummy drivers may present chips as chip-busname-hexaddress.
All /proc values are integers or floating point numbers.
There is no facility in the lm_sensors package for drivers
to output general strings via /proc. This facility may be added
in the future.
Alarms are direct indications read from the chips. The drivers do NOT make
comparisons of readings to thresholds. This allows violations
between readings to be caught and alarmed. The exact definition of
an alarm (for example, whether a threshold must be met or must be
exceeded to cause an alarm) is chip-dependent.
Guidelines for new entries:
- If there are multiple values, some r/w and some r/o,
put the r/w ones first.
- Additional non-standard values should be after the standard values.
-------------------------------------------------------------------------
/proc entries are as follows:
Entry Values Function
----- ------ --------
alarms 1 Alarm bitmask.
Read only.
Integer representation of one to four bytes.
A '1' bit means an alarm.
Chips should be programmed for 'comparator' mode so that
the alarm will 'come back' after you read the register
if it is still valid.
Generally a direct representation of a chip's internal
alarm registers; there is no standard for the position
of individual bits.
Bits are defined in kernel/include/sensors.h.
beep 2 Beep/interrupt enable and bitmask.
The first value is 0 or 1 to globally disable
or enable the beeps.
The second value is a bitmask, with the
same format as 'alarms' with same bit locations.
curr[1-n] 3 Current max, min or hysteresis, and input value.
Floating point values XX.X or XX.XX in Amps.
The second value is preferably a hysteresis value,
reported as a absolute current, NOT a delta from
the max value.
First two values are read/write and third is read only.
fan[1-3] 2 Fan minimum and input value.
Two integers indicating RPM.
First value is read/write and second is read only.
fan_div 3 Fan divisor.
Integers in powers of two (1,2,4,8,16,32,64,128).
Some chips only support values 1,2,4,8.
Entries correspond to the fans[1-3].
See doc/fan-divisors for details.
in[0-8] 3 Voltage min, max, and input value.
Floating point values X.XX in volts from 0 to 4.01 volts.
Actual voltage depends on the scaling resistors on the
motherboard, as recommended in the chip datasheet.
This varies by chip and by motherboard.
Because of this variation, values are generally NOT scaled
by the chip driver, and must be done by the application.
However, some drivers (notably lm87 and via686a)
do scale, with various degrees of success.
These drivers will output the actual voltage.
First two values are read/write and third is read only.
Typical usage:
in0 CPU #1 voltage (not scaled)
in1 CPU #1 voltage (not scaled)
in2 3.3V nominal (not scaled)
in3 5.0V nominal (scaled)
in4 12.0V nominal (scaled)
in5 -12.0V nominal (scaled)
in6 -5.0V nominal (scaled)
in7 varies
in8 varies
pwm[1-3] 1-2 Pulse width modulation fan control.
Integer 0 - 255, read/write.
255 is max or 100%.
Corresponds to the fans 1-3.
Second value, if present, is an enable (0 or 1)
sensor[1-3] 1 Sensor type selection.
Integers 1,2,3, or thermistor Beta value (3435); read/write.
temp,
temp[1-4] 3 Temperature max, min or hysteresis, and input value.
Floating point values XXX.X or XXX.XX in degrees Celsius.
'temp' is used if there is only one temperature sensor on the
chip; for multiple temps. start with 'temp1'.
Temp1 is generally the sensor inside the chip itself,
generally reported as "motherboard temperature".
Temp2 to temp4 are generally sensors external to the chip
itself, for example the thermal diode inside the CPU or a
termistor nearby. The second value is preferably a hysteresis
value, reported as a absolute temperature, NOT a delta from
the max value.
First two values are read/write and third is read only.
vid 1 CPU core voltage.
Read only.
Floating point X.XX or X.XXX corresponding to CPU core voltage
as told to the sensor chip. Not always correct.
vrm 1 Voltage Regulator Module version number.
"Floating point" X.X. Default 8.2.
Affects the way the driver calculates the core voltage from
the vid pins. See doc/vid for details.
doc/developers/release_checklist
+29 -18
View File
@@ -2,35 +2,46 @@ CHECKLIST FOR NEW RELEASES
==========================
Release steps:
- Check out i2c and lm-sensors
- Check out lm-sensors
- Update if necessary, the version number of libsensors
(edit lib/Module.mk and change LIBMAINVER and/or LIBMINORVER)
Remember: update main number when interface changes, minor if new
functionality is added, and patch if only bugs are fixed.
`svn diff -r Vx-y-z lib' is your friend.
- Update both CHANGES files (add the release date)
- Verify i2c dependency instructions in README, QUICKSTART, and INSTALL,
update if necessary
- Update lm_sensors2/version.h and i2c/kernel/i2c.h
- Update the CHANGES file (set version and release date)
- Update lm_sensors.lsm (Version, Entered-date and Primary-site)
- Update libsensors-API.txt
- Update version.h
- Commit
- Tag the release using SVN:
svn copy http://lm-sensors.org/svn/lm-sensors/trunk \
http://lm-sensors.org/svn/lm-sensors/tags/V2-x-x \
-m "Create tag 'V2-x-x'."
- Remove 'SVN' related files/directories (e.g. rm -fR `find . -name .svn`)
- Rename i2c and lm_sensors2 to i2c-#.#.# and lm_sensors-#.#.#
- Tar it up and post it (sign it)
- Make sure the file permissions on both the archives and the signatures
are correct (664)
svn copy http://lm-sensors.org/svn/lm-sensors/branches/lm-sensors-3.0.0 \
http://lm-sensors.org/svn/lm-sensors/tags/V3-x-x \
-m "3.x.x release"
- Move to a temporary directory and get a copy of the freshly tagged code:
svn export http://lm-sensors.org/svn/lm-sensors/tags/V3-x-x lm_sensors-3.x.x
- Tar it up:
tar jcf lm_sensors-3.x.x.tar.bz2 lm_sensors-3.x.x
- Sign it:
gpg -b lm_sensors-3.x.x.tar.bz2
- Post it:
scp lm_sensors-3.x.x.tar.bz2* \
devel.atrpms.net:/srv/lm-sensors.org/dl/lm-sensors/releases
- Set correct permissions:
ssh devel.atrpms.net chmod 664 \
'/srv/lm-sensors.org/dl/lm-sensors/releases/lm_sensors-3.x.x.tar.bz2*'
After release, remember to:
- Copy to mirrors
- Update the Download page on lm-sensors.org, then add a news item
- Announce on the lm-sensors mailing list
- Announce on Freshmeat
- Put back ???? for dates
- Prep CHANGES files for next release
- Add "+SVN" to version.h and commit
- Mark the corresponding release milestone as complete using trac-admin
e.g. 'trac-admin /srv/lm-sensors.org/trac milestone completed 2.10.2 2006-12-31'
e.g. 'trac-admin /srv/lm-sensors.org/trac milestone completed 3.0.0 now'
- Create a new version for the bug tracking system using trac-admin
e.g. 'trac-admin /srv/lm-sensors.org/trac version add 2.10.2 2006-12-31'
e.g. 'trac-admin /srv/lm-sensors.org/trac version add 3.0.0 now'
- Create a new release milestone using trac-admin
e.g. 'trac-admin /srv/lm-sensors.org/trac milestone add 2.10.3 2007-03-31'
e.g. 'trac-admin /srv/lm-sensors.org/trac milestone add 3.0.1 2008-02-15'
- Send lm_sensors.lsm to the LSM by mailing it to lsm@qqx.org with the
subject `add' (no quotes)
doc/developers/sysctl
-16
View File
@@ -1,16 +0,0 @@
You can access everything under /proc/sys through the sysctl interface. This
is mostly useful for C programs, which can use the sysctl function. Try
'man 2 sysctl' for more information.
As each chip gets its own directory under /proc/sys/dev/sensors, you must
somehow know the sysctl id of these directories to access the sensor data.
This is done through the file /proc/sys/dev/sensors/chips (see sensors.h
for the corresponding SYSCTL ids). You can only read this file; it
returns an array of struct sensors_chips_data, as defined in sensors.h.
Each chip will have its own entry here, with both its sysctl id and
the corresponding /proc name.
Generally, it is a better idea to use the new libsensors to access this
data. If you feel you need more than the library offers, please mail us,
so we can either add the new functionality to the library, or explain how
you can work around it.
doc/developers/sysfs-interface
-10
View File
@@ -1,10 +0,0 @@
sysfs access (2.6 kernels)
--------------------------
In the 2.6 kernel, sensor chip drivers create subdirectories in
the sysfs filesystem (usually /sys) which can be accessed
directly by applications, or through libsensors as before.
Naming and content standards for the entries in these subdirectories
is documented in the file Documentation/hwmon/sysfs-interface in the
2.6 kernel source tree.
Loaded 100 of 330 files, more files were not shown because too many files have changed in this diff. Show more