On 01/25/2011 11:42 AM, Jean Delvare wrote:
Probably because you run a distribution where someone stupidly
blacklisted i2c-i801 because it caused trouble on one single machine
once. And you should report this as a bug.
Good call.
All recent desktop boards from Asus implement an ACPI device named
ATK0110 for hardware monitoring, which is supported by the asus_atk0110
driver. So if all you are interested in is hardware monitoring, that's
the way to go.
That would show up in /sys/bus/acpi/ATK0110 right? I don't seem to have
it, nor any mention of "ATK" in the DSDT. It also looks like the DSDT
does not define the smbus interface.
If you really want a complete analysis of what may be on your SMBus,
please share the output of i2cdetect with us. You can get register
dumps from most devices using i2cdump, however I would NOT recommend
doing this on all addresses randomly, as some devices are known to
misbehave when accessed in a way they do not expect.
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- 15 -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: 50 -- 52 -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6e --
70: -- -- -- -- -- -- -- --
I am guessing that 50 and 52 are the SPD eeproms on my dimms, but what
could the others be? Also sensors-detect did not identify them as SPD
eeproms. I loaded the eeprom module and looked at the data it pulled
out of them and it does appear to contain an ascii string that is the
part number of the dimms, but decode-dimms does not seem to like it.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
