Voodoo3 I2C notes (or short commings):
* only one type of read supported: type 'byte' (no 'command')
* only one type of write supported: type 'byte_data'
(The two above are more the limitation of the BT869 rather than
the I2C bus.)
* I used the SMBus 'model' rather than the 'bit' model because
I thought it was easier this way.
* failed bus transactions yeild 0xFF, not an error! So, this means
that many drivers instantly latch onto this adapter because all
reads and writes succeed without error. Without the datasheet for
the chip, I can't do much to fix this. (Amazing I got this far!)
BT869/868 notes:
* the BT869 has lots and lots of registers (~50), but can
only read 3 (fairly uninteresting) status registers(!). Right
now all three status registers are read through the 'status' file,
but I haven't decided on the best method for writing to the rest
of the registers.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@448 7894878c-1315-0410-8ee3-d5d059ff63e0
Originally:
[...]
if (is_isa) {
data = (struct w83781d_data *) (((struct isa_client *) new_client)+1);
new_client->addr = 0;
((struct isa_client *) new_client)->isa_addr = address;
data->lock = MUTEX;
} else {
data = (struct w83781d_data *) (((struct i2c_client *) new_client)+1);
new_client->addr = address;
}
[...]
changed to this:
[...]
if (is_isa) {
data = (struct w83781d_data *) (((struct isa_client *) new_client)+1);
new_client->addr = 0;
((struct isa_client *) new_client)->isa_addr = address;
} else {
data = (struct w83781d_data *) (((struct i2c_client *) new_client)+1);
new_client->addr = address;
}
data->lock = MUTEX;
[...]
So, now the MUTEX is properly initialized for I2C chips, too. If the
mutex was knowly ignored for I2C devices (because the piix4 locks its
self), then the mutex should be ignored everywhere else in the code, but
it is not.
This seems to have solved my reproducable 'hanging' problem. But, other
drivers should be checked, too, just in case.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@433 7894878c-1315-0410-8ee3-d5d059ff63e0
This one was not nice at all. When /proc/bus/i2c-* is read, information is
put into a kernel buffer, which was declared to be the same size as the
final user-space buffer into which it should be copied. Information was
copied into the kernel buffer line by line (using sprintf). If the
buffer is smaller than the whole /proc/bus/i2c-*, only part of the file
was copied. But if the buffer did not break on a line-break, the sprintf
wrote beyond the kernel buffer. With devastating results. Solution: make
the kernel buffer a little longer, so that a single additional line would
fit into it.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@431 7894878c-1315-0410-8ee3-d5d059ff63e0
* The library can now read GL518SM revision 0x00 voltages (in the worst case,
it will read zeros if the module was not inserted with readall=1)
* The readall parameter is now documented through MODULE_PARM_DESC
* Note my remarks in the TODO file
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@403 7894878c-1315-0410-8ee3-d5d059ff63e0
* Readings for the ADM9240 are now updated every 0.5 seconds; for the
DS1780, every 2.0 seconds.
* I still think it likely that voltage readings will be far-off in the
current implementation
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@401 7894878c-1315-0410-8ee3-d5d059ff63e0
Now prints out what kind of sensor it is.
Also separated alarms for temp2 and temp3 for 782d/783s (they are
a single bit for 781d).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@400 7894878c-1315-0410-8ee3-d5d059ff63e0
it proves to be noxious. Added writes for rt table. Use at own risk.
Fixed 782d fan3 bug hopefully.
Added 16,32,64,128 fan_div values for 782d/783s.
Reformatted some > 80 col. lines.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@397 7894878c-1315-0410-8ee3-d5d059ff63e0
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
Whatever you cat to /proc/..../lm78-*/*, the result will now always be
sensible. No more overflows resulting in weird values.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@381 7894878c-1315-0410-8ee3-d5d059ff63e0
* sis5595.c now understand insmod parameters
* sis5595.c now uses sis5595_ prefix instead of lm78_ prefix
* sis5595.c now supports the correct subset of the LM78 features
(it only knows about 4 voltages, 2 fans and no vid)
* added SIS5595 defines to sensors.h
* fixed a small problem in compat.h
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@379 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
Detection is completely impossible, but sensors-detect now assumes with a
confidence of 1 (the lowest possible) that any chip in the LTC1710 address
range is a real LTC1710. Perhaps I should remove this again, as I don't
think this chip will be encountered 'in the wild' if your name is not Phil -
in which case you would have soldered it to your SMBus yourself, so you
should know what you are doing...
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@372 7894878c-1315-0410-8ee3-d5d059ff63e0
gl518sm module
Besides the usual parameters, eeprom.o understands insmod parameter 'checksum'.
Set it to one (ie. 'modprobe eeprom checksum=1') to make it ignore any
chips which do not come through the checksum.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@371 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
This new version also creates MODULE_PARM_DESC entries, which describe
what each parameter is used for.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@360 7894878c-1315-0410-8ee3-d5d059ff63e0
There are now two new insmod parameters, and the #define has disappeared
force: if set to anything but zero, this enables the PIIX4 as the old
#define did.
force_addr: This first sets a new I/O port address for the PIIX4, and
afterwards enables it. Supercedes 'force'.
Note that using force_addr is very, very dangerous if you do not know
what you are doing. On the other hand, it was very easy to add, and can
be a big help if your BIOS doesn't set correct addresses.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@353 7894878c-1315-0410-8ee3-d5d059ff63e0
* Removed unnecessary MOD_INC/DEC_USE_COUNT in host adapter drivers
(i2c-via bit-lp bit-velle)
You can now rmmod adapters even when they have registered clients.
Without this, you would have to detach the clients first. Only way of doing
this is to rmmod the client drivers, but the same drivers might be used to
access clients behind other hosts.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@347 7894878c-1315-0410-8ee3-d5d059ff63e0
is used but ignored (because the driver could not determine what
specific chip was there).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@342 7894878c-1315-0410-8ee3-d5d059ff63e0
Also fixed a small lm78 problem and synchronised the detect script with
the Winbond detection.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@341 7894878c-1315-0410-8ee3-d5d059ff63e0
Also fixed a few nasty sensors.c bugs, and a minor LM78 one. If the new
parameters give trouble, please recompile sensors.c with DEBUG=1 and
examine the dmesg output!
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@338 7894878c-1315-0410-8ee3-d5d059ff63e0
Added RT table read to 781d but then #undef'ed it since it was just
all 1's. Changed max entries in sensor.c to 32 bytes to handle RT table.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@335 7894878c-1315-0410-8ee3-d5d059ff63e0
Improved bounds checking for FAN_TO_REG in all files.
For lm78-compatible drivers, minimum speed is 2657 RPM when the
divisor is 2. Attempts to set lower than that now are set to 0.
Before was set to a random number.
Thanks Jeff Dairiki.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@330 7894878c-1315-0410-8ee3-d5d059ff63e0
Philip Edelbrock