Hi t...@!
acpiac(4) and acpibat(4) on my ASUS UL30A laptop are not working
correctly. On load, both devices return 'not present'. However, when the
embedded controller fires a GPE event on ac/battery insertion/removal,
they suddenly appear and apm(8) reports their status correctly.
Under Linux/FreeBSD, both devices work as expected without physically
removing or inserting the devices. My initial thought was that I had a
broken DSDT that Linux/FreeBSD had some magical workaround for. Looking
through their implementations, the only quirk I've found for ASUS
machines is for certain models that have a broken ECDT.
Looking through the control methods for the simplest device, the AC
adapter, I find this:
Scope(_SB_.PCI0) {
Device(AC0_) {
Name(_HID, "ACPI0003")
Method(_PSR) {
Return(^^SBRG.EC0_.ACAP())
}
Name(_PCL, Package(0x1) {
PCI0,
})
}
}
SBRG.EC0_.ACAP() looks like this:
Method(ACAP, 0, Serialized) {
Return(ACPF)
}
And ACPF is defined in:
OperationRegion(RAMW, SystemMemory, RAMB, 0x0100)
Field(RAMW, AnyAcc, NoLock, Preserve) {
--- SNIP
ACPF, 8,
--- SNIP
}
RAMB:
OperationRegion(ECMS, SystemIO, 0x72, 0x2)
Field(ECMS, ByteAcc, Lock, Preserve) {
EIND, 8,
EDAT, 8
}
IndexField(EIND, EDAT, ByteAcc, NoLock, Preserve) {
Offset(0x48),
IKFG, 8,
FRPN, 16,
RAMB, 32,
--- SNIP ---
}
Greping through a dmesg of a kernel built with ACPI_DEBUG, it turns out
that ACPF has a (garbage?) value of 0x8c. Is the OS responsible for
running control methods to populate these fields with the right values, or
is this something the BIOS handles?
As stated above, once the GPE event handler runs the query method (_QA0)
for the device, the fields get the right value (PSR_ONLINE, PSR_OFFLINE).
Any help at where to look next would be appreciated.
The full DSDT for this machine can be found at:
http://orskaug.org/acpidump.out
