SMBus controller at a time. This is basically an insurance policy. The
kernel and the status from the SMBus controller should handle this but
observed behavior seems to indicate that the SMBus controller does not
ALWAYS mark itself as "busy" during a transaction especially if a trans-
action fails.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@920 7894878c-1315-0410-8ee3-d5d059ff63e0
to check the "command completed" flag before checking for error flags in
the status register. This will insure that when both conditions exist
(command not completed && error conditions present), a "kill" command will
be executed on the SMBus controller to clean up the bus. Also, added a
status register write after "kill" and "timeout" commands to insure that
the status gets cleaned up after a bad transaction. This change fixes
observed behavior in which a "command never completed" transaction was
always followed by an "idle wait timeout" on the next subsequent trans-
action.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@919 7894878c-1315-0410-8ee3-d5d059ff63e0
perfectly with the adm1023, but didn't take advantage of it's extra precision
for the remote temp sensor. Now, if an adm1023 is detected, it will.
For example, my adm1021 remote_temp looks like this:
phil@penn phil]$ cat /proc/sys/dev/sensors/adm1021*/remote_temp
60 20 23
My 1023 looks like this:
[root@penn lm_sensors2]# cat /proc/sys/dev/sensors/adm1023-i2c-2-2a/remote_temp
60.125 20.250 1.500 20.875
(Both from the same inserted driver)
Notice the extra 3 digit precision (actually, it's in increments of 0.125).
And, also notice the extra 'limit'. It's actually an offset register.
Right now it's adding 1.5 degrees to the reading for the remote_temp. This
same functionality could easily be done by editing /etc/sensors.conf, but
Analog Devices decided to put it into the chip instead. :')
Things to do: edit the default sensors.conf, and sensors-detect for this
new chip.
Oh, I also added SENSORS_INSMOD_7 into sensors.h. This was the first
driver to need it, apparently.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@904 7894878c-1315-0410-8ee3-d5d059ff63e0
does not support the extended fan_div bits like the w83782d
does. This should fix fan2 so it defaults to a divisor
of 2 instead of 32.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@871 7894878c-1315-0410-8ee3-d5d059ff63e0
I tested the new macros from a simple stand alone C app, but actual
system testing is still desired.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@852 7894878c-1315-0410-8ee3-d5d059ff63e0
It may be very close or very far from working. At this point, scanning a
bus gives a bunch of errors, but seems to do different things around
addresses which could very well have devices, so it seems promising.
Hopefully, it's just something silly I'm missing like an 'ack'.
Pretty good for not having *any* technical documentation on the driver,
except a partially written (and maybe not even working) example code
from Apple.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@813 7894878c-1315-0410-8ee3-d5d059ff63e0
what there is now. What's left is to use the registers of the keywest
to communicate with devices on the bus. (I.e., flesh out the 'access'
routine.)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@812 7894878c-1315-0410-8ee3-d5d059ff63e0
commit, the module can detect and read the registers from compatible
Keywest buss(es). (Note: there may be more than one bus, as I seem to have.)
Probing is done via Apple's 'New World' Open-Firmware rather than PCI. In
this way, this driver should work with any I2C bus (when it is completed)
which is Keywest 'compatible'. The down side is that this module won't
work on anything but a newer Apple PPC.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@811 7894878c-1315-0410-8ee3-d5d059ff63e0
Mark D. Studebaker