on both platforms). LM87 support is very far along, and should work
for a majority of users, but some minor tweaks are still on the to-do list.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@963 7894878c-1315-0410-8ee3-d5d059ff63e0
I added the list we made some weeks ago, except for the maxilife driver
which is old and which I do not trust at all.
To do: add descriptions for Documentation/Configure (any volunteers?
It should be put in mkpatch.pl next to the other documentation)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@961 7894878c-1315-0410-8ee3-d5d059ff63e0
etc. from LM87... to lm87...; rename /proc entries to standard
in[0-5], etc.; also column 80 cleanup.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@952 7894878c-1315-0410-8ee3-d5d059ff63e0
kernels which need it. Also tweaked sensors-detect to work seemlessly
with the new driver. Driver is tested, and works as expected! (Yeah!)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@950 7894878c-1315-0410-8ee3-d5d059ff63e0
at Scali. Untested, but compiles cleanly. Seems to be very closely based
on the Intel PIIX4 SMBus driver.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@946 7894878c-1315-0410-8ee3-d5d059ff63e0
programmers' reference guide. This ensures that the input value
is latched in the 815 register. We assume this also applies
to the 810 or at least does no harm. Ticket 419.
Alan Chen <alp_chen@hotmail.com> reports that this fixes the
bug where i2c-algo-bit bit_test=1 fails the test.
We don't have any data that shows there was any problem in
normal operation (non bit_test) or that this fixes anything else.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@941 7894878c-1315-0410-8ee3-d5d059ff63e0
(also in prog/sensors/chips.c),
rename /proc entries to in[0-5] and temp[1-2], fix negative
temperature reporting.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@940 7894878c-1315-0410-8ee3-d5d059ff63e0
Fahrenheit patch so that it will print either limit/hysteresis
or min/max. Add a flag to each call to select the right one.
Change temp output to be %3.1f. Some chips are 1 degree accuracy,
some are .5, the 686a is less. For now since it is a common
routine use one decimal point. In future maybe add another
parameter to the routine to specify accuracy.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@939 7894878c-1315-0410-8ee3-d5d059ff63e0
the horrible
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,2,18)) || \
(LINUX_VERSION_CODE == KERNEL_VERSION(2,3,0))
They should now both work with 2.3 kernels (including 2.4 prepatches)
and very new 2.2 kernels (ie. 2.2.18 prepatches)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@933 7894878c-1315-0410-8ee3-d5d059ff63e0
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
