Alpha architecture. I've made compilation contingent on
the machine being an Alpha because the driver needs kernel
include files that are in <asm-alpha>, not <asm>, unless
you are set up as an Alpha.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1109 7894878c-1315-0410-8ee3-d5d059ff63e0
which ensures i2c Bus is tristated correctly. It isn't clear from
the datasheet if the 586's GPIO pins are open drain or not,
but if they aren't, then the driver was driving the pins high
rather than letting them get pulled high as the spec requires.
This is corrected by toggling the direction rather than the
data register to control the bus.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1093 7894878c-1315-0410-8ee3-d5d059ff63e0
Also automatically enable ACPI if it was disabled.
Forcing address doesn't work on my test system, but hey,
at least I tried to test it...
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1077 7894878c-1315-0410-8ee3-d5d059ff63e0
to match what mkpatch patches in patched kernel.
Affected only kernel patches; standalone build was fine.
Ticket # 492.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1026 7894878c-1315-0410-8ee3-d5d059ff63e0
Leave the files there for now.
Remove old installed sensors.o in kernel/Module.mk.
sensors.c was moved to i2c-proc.c in the i2c package.
i2c-isa.h was appended to i2c.h in the i2c package.
Delete all but the SYSCTL and ALARMS definitions in sensors.h,
as the rest of the file was moved to i2c-proc.h in the i2c package.
Remove #include "i2c-isa.h" lines in all chip drivers and
in bus driver i2c-isa.c.
This all probably breaks mkpatch.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1015 7894878c-1315-0410-8ee3-d5d059ff63e0
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
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
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
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
The i801 driver is for the standard I2C bus on an i810 board.
This driver adds the support for the DDC and TV-out busses.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@729 7894878c-1315-0410-8ee3-d5d059ff63e0
Wasn't used by bt869 so wasn't found before.
i2cdump now works and sensors_detect will find ddc monitor.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@711 7894878c-1315-0410-8ee3-d5d059ff63e0
Simultaneous DDC and I2C access may cause errors.
No support for multiple Voodoo3/Banshee chips, only first one
is handled.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@698 7894878c-1315-0410-8ee3-d5d059ff63e0
Mark D. Studebaker