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
aweful happens to me (I get hit by a bus, lose my mind, get hired
by Microsoft, etc.), then somebody else can easily take over.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@428 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
