The old documentation of Phil is still present at the bottom of the file.
Phil may decide to remove it.
In the driver, file 'status' is renamed to 'alarms' and masked to display
only the alarm bits. This fits more closely with other drivers, and the
remaining bit was not interesting anyway.
I fixed a problem that made insertion of the module impossible (I made a
typo when I introduced the insmod parameters) *** Someone else seems to
have changed this at almost the same moment?!? Now it is correct. ***
The MAX1617 and MAX1617A are now also supported by the library.
Once more, some slight formatting changes are made in the documentation
generators (some columns were made wider).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@395 7894878c-1315-0410-8ee3-d5d059ff63e0
Like the LM78 before, all chips now handle strange values written to /proc/...
with grace - that is, they convert them to the most sane value considering
the circumstances, instead of reacting with strange resulting values
(note that they were already crash-free).
I also removed a factor '2' in the computation of the fan speeds in the
gl518sm module. This is conforming with the sheet; if your fan gives two
'ticks' for each rotation, just modify sensors.conf.
I tried to introduce rounding and limit checking to the maxilife module.
The VID computation is not yet rounded - I need the real formula for that.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@382 7894878c-1315-0410-8ee3-d5d059ff63e0
die_code is only relevant for true ADM1021 chips; for the MAX1617, this
is simply undefined, and for the MAX1617A, it is the chip device ID
register. So the die_code file is only created for ADM1021 chips.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@376 7894878c-1315-0410-8ee3-d5d059ff63e0
This one was easy. A MAX1617 is just a MAX1617A with better detection.
Life is beautiful!
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@375 7894878c-1315-0410-8ee3-d5d059ff63e0
As always, I also synchronised the detection with sensors-detect. Its
detection is now much better; it used to scan at many addresses on which
these chips could never exist
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@367 7894878c-1315-0410-8ee3-d5d059ff63e0
basically an expanded LM75. It can have an external temp probe (in
addition to the internal one), customizable conversion rate (in # of times
per second, depending on power consumption requirements), and
actually has a device-id register for easier/more-certain detecting!
The only strange property is the low-limit. The low-limit doesn't act
as a Hystersis value like the LM75. I.e., if the temp falls below it,
it triggers an alarm instead of clearing it. Strange, ey? This makes
using the chip for a thermostat control (like for a fan) much harder.
But it *could* be used to turn on a heater to prevent your computer from
freezing. :')
Here's what my output looks like (without a remote sensor. temp's
are the same format as the LM75 [high-limit, low-limit, value]):
[root@penn adm1021-i2c-0-18]# ls -l
total 0
-r--r--r-- 1 root root 0 Jan 9 23:42 die_code
-rw-r--r-- 1 root root 0 Jan 9 23:42 remote_temp
-r--r--r-- 1 root root 0 Jan 9 23:42 status
-rw-r--r-- 1 root root 0 Jan 9 23:42 temp
[root@penn adm1021-i2c-0-18]# cat *
3
60 20 0
76
60 20 24
PS- all temp values in the ADM1021 (limits and readings) are signed
(2's comp) bytes. So, all readings go from -128 to 127 C (actually,
the docs say it can only reliable sense down to -65), and only
in whole degree increments.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@153 7894878c-1315-0410-8ee3-d5d059ff63e0
Frodo Looijaard