doesn't seem to have any sensors (I guess?), or the Windbond PDF is so
convoluted that I haven't understood it enough to get it working (another
good possibility). Oh, well. It builds and inserts, anyway.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@85 7894878c-1315-0410-8ee3-d5d059ff63e0
start for the LM80 driver. (Since 80-79=1, they must be very similar,
right? :') Oh, and I removed the ISA components from it since the LM80 is
an SMBus only chip, too.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@84 7894878c-1315-0410-8ee3-d5d059ff63e0
has no Winbond specific features implemented yet. Proper testing for
a Winbond also needs to be implemented. src/Module.mk and src/sensors.h
were modified slightly to support the new driver.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@83 7894878c-1315-0410-8ee3-d5d059ff63e0
* Turned the i2c noise level down, by setting the debug_level in algo-bit.c
and i2c-core.c to 0 instead of 1. This should stop it from polluting
the dmesg output, as it does at this moment.
* Renamed gl518-r?0-* entries to gl518sm-r?0-*
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@82 7894878c-1315-0410-8ee3-d5d059ff63e0
* Only first 64 bytes are read (enough for SDRAM EEPROM data) in 16 byte
blocks (separate proc files).
* No writing to EEPROMs. It's actually quite easy to add support for
writing, but I was being very paranoid about killing my DIMMs. I may add
write support, but make it only available when a #define is specified.
Now for a user app to decode the values...
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@71 7894878c-1315-0410-8ee3-d5d059ff63e0
IF the Winbond docs are right this time, a Winbond should now be
recognized; a warning is printed, and it is treated as a LM79.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@70 7894878c-1315-0410-8ee3-d5d059ff63e0
Strangly enough, both these devices use a high byte, low byte order for
word-sized reads and writes. The SMBus documentation specifies the
reverse (low, high) order, though. If all devices use the high,low order,
we should change this in smbus.c.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@64 7894878c-1315-0410-8ee3-d5d059ff63e0
* Alarms may now work (sound signal disabled, though)
* Revision 0x80 should be recognized and handled correctly
* If fan unconnected, it should show 0 instead of -1 now
Note that this driver will not support GL520SM chips; that chip is different
enough that it deserves its own driver.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@61 7894878c-1315-0410-8ee3-d5d059ff63e0
To be done: support for GL518SM revision 0x80 and GL520SM
Kyösti, if you have some time soon, could you please test it?
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@56 7894878c-1315-0410-8ee3-d5d059ff63e0
See doc/sysctl for an explanation why it is needed.
Also fixed two very small cleanup bugs in lm75/lm78, which would probably be
impossible to trigger anyway, but still.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@51 7894878c-1315-0410-8ee3-d5d059ff63e0
* LM75 temperature limits initializations were switched
* LM78 VID readings were off by a factor 100
* New bit-mask constants in sensors.h for LM78 alarm field
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@49 7894878c-1315-0410-8ee3-d5d059ff63e0
This fix will only work for kernels >= 2.1.58.
* lm75, lm78: {INC,DEC}_MOD_USE_COUNT called for {inc,dec}_mod_use hooks
* sensors: For new kernels, fill_inode is called, which in turn calls
{inc,dec}_mod_use for a certain client
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@46 7894878c-1315-0410-8ee3-d5d059ff63e0
driver (used as a template). It is completely non-functional at this
point, but it's a start. There is a lot of code still specific to the
lm75 in it, so don't try to use it yet. ;') Also note that there needs
to be some concern with using it because a 'write' and a 'read' to an
EEPROM on the SMBus are very similar. So, we need to be carefull not
to start crippling SDRAM DIMMs due to unfinished/buggy code.
This should (when working) be able to read EEPROMs:
* In SDRAM DIMMs which specify the type, clocking, etc. of the DIMM.
* the EEPROMs in the new Intel Xeon processors.
* Any other EEPROM connected to the SMBus conforming to the standard
SMBus comminucation methods for SMBus EEPROMs.
Since only eight possible addresses are available for EEPROMs (at
least from the spec I'm looking at from Atmel), the code will
only probe for eight. Notice that this can lead to some problems
for machines for which this is true: # of SDRAM DIMMs + # of Xeons > 8
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@45 7894878c-1315-0410-8ee3-d5d059ff63e0
* Changed test in lm75 setup code to 'read/write returns < 0' instead of
(old) 'read/write returns 0xff'. Nowadays, we can see the difference
between an error and a 0xff result, after all.
* Introduced constants used by PIIX4 for transaction types. These are
*not* the same as those in smbus.h.
* Some small code optimalizations in piix4.o.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@40 7894878c-1315-0410-8ee3-d5d059ff63e0
* PIIX4: better names in /proc files
* sensors.c: fixed bug which prevented registration of non-ISA clients
Status:
* lm75 inserts happily and interacts with the PIIX4 correctly
* lm75 readings are still wrong (all 0xff)
* lm75 insertion with ISA bus present causes oops
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@39 7894878c-1315-0410-8ee3-d5d059ff63e0
If your LM78/78-J/79 is still not detected, please recompile lm78.o with
DEBUG=1 and mail the output of dmesg. Same for Winbonds.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@33 7894878c-1315-0410-8ee3-d5d059ff63e0
Well, it should work. But until we have implemented the remaining parts of
piix4.o, we won't be able to test it. Anybody?
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@29 7894878c-1315-0410-8ee3-d5d059ff63e0
I moved a large part of the proc and sysctl call-back functions into
sensors.c. The result saved about 100 lines in lm78.c; it now uses only
2 pages according to lsmod, instead of 3! Also, other modules can use
the same functions, saving coding efforts and keeping them small.
I also fixed a fan_div display error.
Expect more code to be moved to sensors.c: I am writing lm75.c, and
most things which are in both modules (and so probably general purpose)
will be moved to sensors.c.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@28 7894878c-1315-0410-8ee3-d5d059ff63e0
* LM78, LM78-J and LM79 now all supported
* Chip type reflected in /proc/bus/i2c-?, /proc/.../sensors/* and
/proc/ioports.
* VID initialises IN0 and IN1, except if it is 3.50 V (then it falls back to
2.80 V)
* Slightly better ISA detection (but still not good enough)
* Temperature now in tenth of degrees, instead of whole degrees (for better
compatibility)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@27 7894878c-1315-0410-8ee3-d5d059ff63e0
Yes, our first chip driver is now fully operative. Some parts of it can
still be moved to sensors.o and reused by other drivers, but this can be
done later.
Bug fixes:
* i2c-core.c: Corrected previous patch (a client was now unloaded twice,
which caused problems, as could be expected).
* lm78.c, sensors.c: some minor typos, which caused the crashes
* lm78.c: FAN_DIV only has two fields (fan 3 is not changable)
* sensors.c: ISA/SMBus addresses are prefixed with zeros in directory names
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@20 7894878c-1315-0410-8ee3-d5d059ff63e0
* Some Makefile changes. doc/makefiles documents most of them.
* The lm78 module now compiles, but it will still crash.
* New module sensors, with general code usable by chip driver modules
* i2c-core: added function i2c_adapter_id(), which returns a (low)
unique i2c-bus ID.
* lm78.h stuff moved into lm78.c or sensors.h
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@19 7894878c-1315-0410-8ee3-d5d059ff63e0
* i2c-bus is renamed to i2c-proc
* small patch in i2c-core.c (see correspondence with Simon Vogl)
* sensors.h contains i2c constants
* It seems lm78.[ch] was not yet committed?!?
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@16 7894878c-1315-0410-8ee3-d5d059ff63e0
Frodo Looijaard