Identifying i2c devices on Asus P8P67 sandybridge motherboard

Identifying i2c devices on Asus P8P67 sandybridge motherboard

[Phillip Susi]

I recently got a new Asus P8P67 Pro motherboard with a sandybridge core
i5 2500K.  After checking the Intel chipset docs, I found that it has an
i2c controller and it was enumerated on the pci bus, but no driver was
loaded for it.  I found the i2c-i801 module and the comments in the
source say it supports the Cougar Point (PCH) and matches the PCI ID.
I'm not sure why it wasn't auto loaded, but after loading it, it seemed
to work.

At that point I ran sensors-detect, which failed to recognize any known
controllers on the bus, but i2c-detect found several addresses that
responded.  How can I proceed with identifying what these devices are,
so that I can hopefully find or write a driver to communicate with them?

Re: Identifying i2c devices on Asus P8P67 sandybridge motherboard

[Jean Delvare]

Hi Phillip,

On Tue, 25 Jan 2011 11:05:20 -0500, Phillip Susi wrote:
> I recently got a new Asus P8P67 Pro motherboard with a sandybridge core
> i5 2500K.  After checking the Intel chipset docs, I found that it has an
> i2c controller and it was enumerated on the pci bus, but no driver was
> loaded for it.  I found the i2c-i801 module and the comments in the
> source say it supports the Cougar Point (PCH) and matches the PCI ID.
> I'm not sure why it wasn't auto loaded, but after loading it, it seemed
> to work.

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.

> At that point I ran sensors-detect, which failed to recognize any known
> controllers on the bus, but i2c-detect found several addresses that
> responded.  How can I proceed with identifying what these devices are,
> so that I can hopefully find or write a driver to communicate with them?

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.

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.

-- 
Jean Delvare

Re: Identifying i2c devices on Asus P8P67 sandybridge motherboard

[Phillip Susi]

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.

Re: Identifying i2c devices on Asus P8P67 sandybridge motherboard

[Jean Delvare]

Philip,

On Tue, 25 Jan 2011 18:52:11 -0500, Phillip Susi wrote:
> 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.

It would show up as:

/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03/ATK0110:00
/sys/bus/acpi/devices/ATK0110:00

or similar.

BTW, what kind of hardware monitoring and/or fan control features does
your BIOS offer?

> > 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,

Correct.

> but what could the others be?

08 and 44 are SMBus internal addresses, i.e. not real chips. This
leaves 15 and 6e, which do not correspond to anything I know.
Sensors-detect does not even scan them.

> 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.

This is strange. Can you please send me a dump of these SPD EEPROMs?

# modprobe i2c-dev
# rmmod eeprom
# i2cdump <bus_nr> 0x50 b > /tmp/eeprom-0x50.dump
# i2cdump <bus_nr> 0x52 b > /tmp/eeprom-0x52.dump

where <bus_nr> is the I2C bus number of your Intel SMBus.

Back to your hardware monitoring issue, Asus tends to use the
integrated sensors in the Super-I/O on desktop boards. So odds are that
you have a very recent Super-I/O chip sensors-detect doesn't know. From
pictures found on the web, it seems to be a Nuvoton NCT6776F, for which
we indeed have no support yet.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

Re: Identifying i2c devices on Asus P8P67 sandybridge motherboard

[Phillip Susi]

On 1/26/2011 3:22 AM, Jean Delvare wrote:
> It would show up as:
> 
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:03/ATK0110:00
> /sys/bus/acpi/devices/ATK0110:00

That's what I thought.  Don't have it.

> BTW, what kind of hardware monitoring and/or fan control features does
> your BIOS offer?

Asus calls it Q-fan.  It does seem to automatically throttle the fan
speed in response to temperature.  It has two 4 pin PWM headers and two
3 pin headers on the board, and the bios config has options to enable
fan speed control on either of the 4 pin headers.

> This is strange. Can you please send me a dump of these SPD EEPROMs?

Will get it to you when I get back home tonight.

> Back to your hardware monitoring issue, Asus tends to use the
> integrated sensors in the Super-I/O on desktop boards. So odds are that
> you have a very recent Super-I/O chip sensors-detect doesn't know. From
> pictures found on the web, it seems to be a Nuvoton NCT6776F, for which
> we indeed have no support yet.

I began to suspect as much.  Do you know if anyone is working on a
driver for it, or if the data sheet is available so I could take a crack
at it?

Then again, I wonder if it might be better to come up with an SSDT I can
dynamically load to define the ACPI FAN and TZ objects and let the
regular acpi driver manage it.

Re: Identifying i2c devices on Asus P8P67 sandybridge motherboard

[Phillip Susi]

On 1/26/2011 9:42 AM, Phillip Susi wrote:
>> Back to your hardware monitoring issue, Asus tends to use the
>> integrated sensors in the Super-I/O on desktop boards. So odds are that
>> you have a very recent Super-I/O chip sensors-detect doesn't know. From
>> pictures found on the web, it seems to be a Nuvoton NCT6776F, for which
>> we indeed have no support yet.
> 
> I began to suspect as much.  Do you know if anyone is working on a
> driver for it, or if the data sheet is available so I could take a crack
> at it?

I have gotten ahold of the data sheet for the chip so hopefully will be
able to write a driver for it, but maybe we should move this
conversation to the lm-sensors mailing list?

Before we do though, I sill have one more question about the i2c bus.
My understanding is that simple i2c devices use fixed addresses, like
the SPD EEPROMs, but SMBus devices initially respond to a broadcast
address where they can be detected and dynamically assigned an address.
 Is there a tool that can perform such a reset and enumeration that
could give better identification of those two unknown devices, should
they be smbus compatible and not just i2c?  When I tried reading them
with i2c-dump I just got a bunch of XXs.

Re: Identifying i2c devices on Asus P8P67 sandybridge motherboard

[Jean Delvare]

Hi Phillip,

On Wed, 26 Jan 2011 15:39:11 -0500, Phillip Susi wrote:
> I have gotten ahold of the data sheet for the chip so hopefully will be
> able to write a driver for it, but maybe we should move this
> conversation to the lm-sensors mailing list?

Yes, definitely.

> Before we do though, I sill have one more question about the i2c bus.
> My understanding is that simple i2c devices use fixed addresses, like
> the SPD EEPROMs, but SMBus devices initially respond to a broadcast
> address where they can be detected and dynamically assigned an address.

Things aren't that simple. SMBus devices _can_, optionally, reply to
the SMBus ARP address (0x61) for identification and/or dynamic address
allocation. They don't have to, and I've never seen any hardware
monitoring ASIC requiring this (all I've seen start with a suitable
static address.)

>  Is there a tool that can perform such a reset and enumeration that
> could give better identification of those two unknown devices, should

No, there is no such tool. Proper SMBus ARP support would be done by
the kernel, but it is not yet implemented on Linux.

> they be smbus compatible and not just i2c?  When I tried reading them
> with i2c-dump I just got a bunch of XXs.

Even for the EEPROMs? This would be strange. OTOH this would explain
why decode-dimms did not work. But OTOH it would be strange that
i2cdetect would have worked if the SMBus isn't properly supported...

Could you please try i2cdetect again? It is possible that the detection
somehow confused your SMBus (at an address >= 0x6e), in which case
i2cdetect will no longer work. This is usually fixed by a cold boot of
the system. You can also look for i2c-i801 related error messages in
your kernel logs.

-- 
Jean Delvare

Re: Identifying i2c devices on Asus P8P67 sandybridge motherboard

[Jean Delvare]

On Wed, 26 Jan 2011 09:42:20 -0500, Phillip Susi wrote:
> On 1/26/2011 3:22 AM, Jean Delvare wrote:
> > Back to your hardware monitoring issue, Asus tends to use the
> > integrated sensors in the Super-I/O on desktop boards. So odds are that
> > you have a very recent Super-I/O chip sensors-detect doesn't know. From
> > pictures found on the web, it seems to be a Nuvoton NCT6776F, for which
> > we indeed have no support yet.
> 
> I began to suspect as much.  Do you know if anyone is working on a
> driver for it, or if the data sheet is available so I could take a crack
> at it?

No, the device isn't even listed on lm-sensors.org's wiki, I am not
aware of anyone working on it.

The datasheet isn't available for download from Nuvoton, but can
probably be requested from them.

> Then again, I wonder if it might be better to come up with an SSDT I can
> dynamically load to define the ACPI FAN and TZ objects and let the
> regular acpi driver manage it.

What an horrid idea. The ACPI FAN and TZ interfaces are very limited.
If the ACPI BIOS doesn't block access to the NCT6776F's I/O ports,
you'll be much better with a native driver.

OTOH I admit I am surprised to see Asus move away from the ATK0110.

-- 
Jean Delvare