Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Fans, Temperatures, ACPI EC and I2C

Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
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

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,138
    <quote>
    Question: is it the same SuperIO chip which implements the legacy stuff like
    PS/2+COM+LPT+Floppy?
    </quote>

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

    <quote>
    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?
    </quote>

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

    <quote>
    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?
    </quote>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    > 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
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,138
    <quote>
    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.
    </quote>

    I have no idea if that's possible.

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

    <quote>
    Is SMBUS based on I2C or such?
    </quote>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 25 Feb 2019 OSR Seminar Space
Developing Minifilters 8 April 2019 OSR Seminar Space