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
busses
The changes are large and tricky, so it is almost certain there are
many bugs. Please run sensors-detect and tell me whether it works
correctly or not.
All changes are in the routines that print the modprobe statements at
the end, so if it fails, it will fail there.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@720 7894878c-1315-0410-8ee3-d5d059ff63e0
* DDC only looked for on 0x50, as other addresses are treated as
sub-addrs;
* LM78-J again displays right driver (oops...)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@680 7894878c-1315-0410-8ee3-d5d059ff63e0
Changes in sensors.c:
sensors_detect now skips addresses which are already taken. Even a
force parameter can not override this, as it could lead to major
problems.
For ISA addresses, the same is done; but the client drivers still need
a check if they claim more than one ISA address (as all of the current
ISA clients do).
Changes in chip drivers:
Removed the comment about needing address registration
Changes in i2cdetect.c:
Marks addresses which are already claimed
Changes in sensors-detect:
Warns when an address is already claimed, and skips it.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@667 7894878c-1315-0410-8ee3-d5d059ff63e0
Could somebody with a LM78 or W83781D on both SMBus and ISA bus please test
this? It should say `Alias of the chip on I2C bus `...' address `...''
when scanning the ISA bus.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@664 7894878c-1315-0410-8ee3-d5d059ff63e0
sensors-detect detection is now complete; I think nothing else needs
to be done in the tree?!? (except documentation of course)
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@643 7894878c-1315-0410-8ee3-d5d059ff63e0
It now warns you about built-in drivers, and should always work. It will
still give a too long list of modules if some things are built into the
kernel. There is no real solution to this; the best thing to do would
probably be to ask the user where the kernel tree is located, and use
.config to determine what is built into the kernel. But not everybody
has such a kernel tree - especially once we get to the point where
people will distribute binary versions.
I also updated the list of undetectable adapter.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@589 7894878c-1315-0410-8ee3-d5d059ff63e0
Changed adm9240 confidence from 8 to 7 to let adm1022 win,
not sure about register 0x3F in adm1022.
Removed 0x69 from i2c range on all drivers, that address
looks entrenched for clock chips.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@540 7894878c-1315-0410-8ee3-d5d059ff63e0
* removed algorithm registration in i2c-isa
* renamed i2c-via2.o to i2c-viapro.o in the driver messages
* added detection for new drivers in sensors-detect script
* minor gl518sm fix
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@522 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
