I am a BIOS developer and need assistance with an ACPI support issue. I am trying to add a thermal zone for an I2C HW Monitor/Fan Controller device (MAX6639). This device does not provide any Windows driver support.
To create an ACPI method to read temperature (_TMP), I need to read the temperature register on this I2C device. There is no existing ACPI support for the I2C controller on the CPU and I would prefer not to create it. I cannot be the first person with this need.
Is it possible for the ACPI code to use the existing Windows I2C driver (iaLPSS2_I2C_TGL.sys) to access this device? Are there any hooks built into the driver for this purpose?
Do I need to develop a function driver according to the Microsoft website?
This section describes how a vendor can use a WDM function driver in Windows to enhance the functionality of an Advanced Configuration and Power Interface (ACPI) device.
You’re really going the wrong direction here. Windows can assume and use the presence of ACPI, but ACPI cannot assume that Windows is running. It has to exist in a completely isolated world. Remember that people are going to be booting LInux on your system as well.
How does the I2C controller get exposed if ACPI doesn’t know about it?
Not a surprise. I have declared the I2C device in the ACPI (below). I am unsure how to communicate with the device in the ACPI space. How do I access specific registers in the device.
I guess I will have to create the required ACPI methods with a _DSM call. I hoped I would find some kind of reference code for this type of application.
Scope(\_SB.PC00.I2C2) {
// Current Resources Settings
Method(_CRS, 0x0, NotSerialized)
{
Name(RBUF, ResourceTemplate()
{
I2CSerialBus(0x60, // 7-bit Slave Address
ControllerInitiated, // Slave or master?
400000, // Connection Speed in hz
AddressingMode7Bit, // 7-bit or 10-bit addressing?
"\\_SB.PC00.I2C2", // I2C Controller to which MAX6693 is connected
0, // Resource Index
ResourceConsumer) // Consumer or Producer?
})
Return(RBUF)
}
}
I wish there were better descriptive information available about ACPI. There’s a fair amount of reference material, but that doesn’t tell you how to approach specific tasks. I’ve dabbled in ACPI a few times, and finding a result always seemed like luck more than engineering. It seems like the practical knowledge is all embedded in BIOS teams like yours.
That’s really helpful for you, isn’t it? “Go ask a BIOS developer.”
I’m not sure HOW this is supposed to work, to be honest. I’m not even entirely sure if you need to wire-this up in ACPI, beyond simply exposing the device (as you apparently have) as a peripheral on the I2C bus. Then, maybe, you write a kernel-mode driver for it, declaring a Device Interface GUID of GUID_DEVICE_THERMAL_ZONE? And then, maybe, you get thermal management IOCTLs from Windows? And then, maybe, the rest takes care of itself??
That’s how the advanced power monitoring stuff works, for example (I know this from experience).
As a system integrator, you’re going to need to reach-out to your contacts at MSFT and have them tell you how this should work. That, AND… perhaps throw together a quick Windows driver that enables that Device Interface GUID and see if you get any IOCTLs from the OS.
But I’d be surprised if the answer is “write an all-singing and dancing ACPI method”…
Peter
ETA:
And then, maybe, you get thermal management IOCTLs from Windows? And then, maybe, the rest takes care of itself??
Yup. That looks like exactly how it’s supposed to work. I’d definitely prototype that, if I were you. No matter what, it’ll be worth the hour or so it takes you to check this out.
