This driver is a copy of vt1211, which is almost identical.
The vt1211 is a super i/o chip and the vt8231 is a PCI chip.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1501 7894878c-1315-0410-8ee3-d5d059ff63e0
indication will always be valid; it won't be cleared forever by
reading the register. Do this by setting temp1_hyst to 127
and programming register 4C which sets it for temps 2 and 3.
Don't print hyst. value for temp1 in 'sensors' if == 127.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1407 7894878c-1315-0410-8ee3-d5d059ff63e0
From: Aurelien Jarno <aurelien@aurel32.net>
Hello,
I have to use the pcf8574 chip with my I2C interface, however, the pcf8574
drivers in lm-sensors is a bit basic. It supposes the pin P1 is used as an
input and the others pin as outputs.
Attached is a patch which corrects that, providing to files in /proc
interface, one for writting, the other for reading. It also modifies a bit
the driver to support the pcf8574a (it is a pcf8574 with a different address
range), and add a documentation file in doc/chips.
The patch also includes some cosmetic changes in the pcf8591 driver I wrote
previously, that is to say it modify the chip name in some places I had
forgotten to change when I made a copy/paste from another driver.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1318 7894878c-1315-0410-8ee3-d5d059ff63e0
to different addresses; this allows initialization of two
clients on the same i2c bus by preventing subclient address
conflicts at 0x48 and 0x49.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1312 7894878c-1315-0410-8ee3-d5d059ff63e0
Use 'init=0' to skip initialization, this should fix
those pesky PC's that crash when you load w83781d.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1209 7894878c-1315-0410-8ee3-d5d059ff63e0
The following patch does the following:
Fixed bug with not all alarms enabled.
Added ability to read battery voltage
Select temperature sensor type at module load time.
Added setting for Inside Technologies 786LCD board to example config file
I also fixed what looked like a typo in the existing it87 section where
in6_min/max was set twice and in7 was not set. As commented I think
the equation for the negative voltages are wrong but without that motherboard
I can't verify.
With the 786LCD board sensors-detect reports a lm78 which doesn't
exist and a sis5595 which may be part of the SIS630 chip but doesn't
perform the monitoring. The it8705F/SIS950 which is on the board is
reported as a misdetect. I didn't know enough about the various chips
to figure out how to get correct detections.
David Gesswein
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1146 7894878c-1315-0410-8ee3-d5d059ff63e0
patch from Christian Zuckschwerdt:
Hi,
On Fri, 15 Jun 2001, Mark D. Studebaker wrote:
> I looked at the patch and I see there are separate
> /proc entries for the 9 and 12 bit outputs.
> Why not just make the 12 bit output the only output using "temp"??
> I don't understand the need for all the new /proc entries,
> except perhaps for debugging inside #ifdef DEBUG.
> Would you or Jan be willing to develop a patch that way?
> I'm all for increased accuracy as a standard feature - why not?
Ok. I rewrote the patch to support standard (9bit) and enhanced (12bit)
accuracy via the "temp" entry. The "raw" interface is also gone.
There are some quirks needed for the sensors app. It seems that
prog/sensors/chips.c fixes the output to %+3.1f
Thats not good for 12bit mode which gives you 2 decimals and therefor
wrong scaling.
Precision is .062 with 12bit (4 decimal bits) instead of .5 with 9bit (1
decimal bit). That way 2 decimals seem a natural choice.
On the other hand I see no obvious reason not to fix decimals to 1...
I'm lost there -- suggestions anyone?
Another problem is that 12bit is slow and laggy. I don't recommend making
it the default mode.
cu.
:
Christian
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1145 7894878c-1315-0410-8ee3-d5d059ff63e0
Alexander Malysh