Fans, Temperatures, ACPI EC and I2C

I would like to raise several questions on the topic, the answers (from the people more informed then me) will be archived and useful in the future.

First some background:

A) I have an open-source OpenHardwareMonitor app. It is a .NET app, and, according to the source, it uses the PortIO driver (embedded to resources), then loads it by p/Invoke to CreateService, then uses it to peek/poke the ports of SuperIO chip. It supports several kinds of SuperIO chips like Winbond.

Question: is it the same SuperIO chip which implements the legacy stuff like PS/2+COM+LPT+Floppy?

B) Also, in BIOS settings, I have “Asus Q-Fan Control”. This feature really adjusts the CPU fan speed according to temperature/load, and works even if no Asus software is installed in Windows. Looks like the feature is OS-agnostic. Surely not only Asus provides this, and surely this is even more popular in laptops.

Now question:

  1. how is I2C related to all of this? is Winbond SuperIO a bus master for I2C, while fan/temp/voltage probes and controls - the slave devices on I2C bus?
  2. how is OS-agnostic stuff working? Is ACPI EC involved in this? Is ACPI EC a separate chip or is it embedded to SuperIO? Can ACPI EC be implemented by executing BIOS SMM code on a main CPU? Am I correct that ACPI EC, being a master, sends IN/OUT transactions to SuperIO?
  3. can there be conflicts between the OS-agnostic BIOS stuff controlling the fan speed and the app like OpenHardwareMonitor doing the same?
  4. regardless of WMI schema having classes for fans, temperatures etc, they are nearly never implemented by BIOS’s ACPI table (even on a brand-name machines like Dell PowerEdge). Am I correct that, in a lucky case if WMI controls for fan/temp/voltage are actually supported, they are conflict-free with the OS-agnostic BIOS stuff?
  5. Windows has the acpiec.sys driver. What is its purpose? is it related to exposing fans/temps/voltages to WMI?


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

I haven’t examined the application, but typically, yes. SuperIO or ICH/PCH.

That’s typically how it works, yes. See more below.

That’s quite a lot of questions.

It COULD be done by the EC, but it’s not necessarily done that way depending on the level of sophistication of control provided.

The EC is an actually controller chip, with firmware. It’s most commonly used to control things like the PS/2 keyboard or the like. The EC *itself* can’t just be a bunch of BIOS Code (ACPI Source Language, aka ASL)… by definition it’s an EC. However, it *is* certainly possible to *just* use ASL to do basic fan control on the system, without having to bother the EC.

Typically, the SuperI/O (or ICH/PCH) provides the master control logic for one or more attached I2C or SMBUS buses. You can usually see these registers reported in the system with NODRV loaded. The fans and thermal sensors are attached to one of these buses.

Whether the BIOS-supplied methods are “conflict free” with the ASL or EC-implemented methods depends on the quality of the EC firmware and/or BIOS code that’s written. They certainly SHOULD be conflict free, and making that happen isn’t extremely difficult.

Note that there are two levels of “conflict free” that we need to consider: “Conflict free” in terms of using the SuperIO/ICH/PCH registers which implement the control of the I2C or SMBUS. And also there’s “conflict free” in terms of interactions with the fan methods (that is, the host-based fan control tries to set the fan to HIGH while the BIOS-based fan control tries to set the fan to LOW). The SuperIO/ICH/PCH usually provide mechanisms to aid in preventing the first category of conflict (conflict over the use of the master controller). But these mechanisms rely on BOTH the host-based code and the BIOS-based code using the coordination mechanisms properly. Similarly, conflicts over fan settings: The BIOS (or EC) based code would need some way to be informed that “the host is controlling the fan speed now… please set aside.”

Hope that helps,

Peter
OSR

> The EC is an actually controller chip, with firmware. It’s most commonly used to control things like

the PS/2 keyboard or the like.

PS/2 kbd (driven by i8042prt) is for years in SuperIO.

It this called “EC”?

Am I right that EC runs even if the main power is off?

The EC *itself* can’t just be a bunch of BIOS Code (ACPI Source Language, aka ASL)…

No ASL.

I mean the picture of: main CPU == EC, and the code which executed on it to make it a EC is in the BIOS. The CPU runs in SMM during this, so, this can be done in OS-transparent way. The system just needs to run the main CPU fan-less on reduced clock with the main power off (with only the standby power).

Is this a possibility?

Typically, the SuperI/O (or ICH/PCH) provides the master control logic for one or more attached I2C
or SMBUS buses.

Is SMBUS based on I2C or such?


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

I have no idea if that’s possible.

That’s not what’s classically envisioned by ACPI, in any case.

They’re VERY similar, and mostly compatible in their implementation, with a few small differences:

http://www.maximintegrated.com/app-notes/index.mvp/id/476

Peter
OSR