So, in messing with this Pavilion m6_1935dx, I was able to get most of the EC running as expected. It seems that, at least the (ACPI) register layout is the same. We can get good battery _and_ AC indicators from it.
When we query the EC (say, doing a cat /sys/class/power/AC/online), it responds properly with an SCI whenever the status register changes, and the query goes well. And that's about it.
When an event happens, on the other hand, like a hotkey, or AC is removed, it does not generate an SCI that would lead to a query call (_Qxx). Instead it spits out an SMI. I know for a fact that the SCI and SMI GPEs are where we expect them to be.
I see google/parrot uses the same physical EC silicon, though the EC firmware may be a different beast. However, I'd like to ask of you gurus who have worked on parrot... what's your take on this?
Alex
More technical details: I've made ACPI print a debug message whenever GPE23 is triggered (_L17). This is the EC SMI event.
I'm also using linux supermagic to get an idea of what is going on:
On 05.04.2014 19:02, mrnuke wrote:
When an event happens, on the other hand, like a hotkey, or AC is removed, it does not generate an SCI that would lead to a query call (_Qxx). Instead it spits out an SMI. I know for a fact that the SCI and SMI GPEs are where we expect them to be.
What do you mean by "expected"? Same as vendor BIOS? My guess is that vendor BIOS handles SMI and then somehow triggers SCI in software. I'd try to route all GPE to SCI.
On Saturday, April 05, 2014 08:21:21 PM Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 05.04.2014 19:02, mrnuke wrote:
When an event happens, on the other hand, like a hotkey, or AC is removed, it does not generate an SCI that would lead to a query call (_Qxx). Instead it spits out an SMI. I know for a fact that the SCI and SMI GPEs are where we expect them to be.
What do you mean by "expected"?
EC SCI is hooked to GEVENT3 pin which is routed to GPE3 EC SMI is hooked to GEVENT23 which is routed to GPE23
Same as vendor BIOS?
Yep
My guess is that vendor BIOS handles SMI and then somehow triggers SCI in software. I'd try to route all GPE to SCI.
I can only route one GEVENT pin to a GPE, otherwise the SB craps up and no longer triggers an interrupt for that GPE.
I've tracked it down to bit5 of the EC status reg (inb 0x66). Normally, on an external event, it would be set, OS finds it set and queries the SCI source, uses that to call _Qxx. That bit5 is never set by EC in my case.
Alex
On Saturday, April 05, 2014 03:34:22 PM mrnuke wrote:
My guess is that vendor BIOS handles SMI and then somehow triggers SCI in software. I'd try to route all GPE to SCI.
Turns out that I needed to tell the EC to go into ACPI mode, as it boots up in APM mode. In APM mode, it causes SMIs instead of SCIs. Freaking dumb-ass ECs.
Alex
mrnuke wrote:
Turns out that I needed to tell the EC to go into ACPI mode, as it boots up in APM mode.
Blame MS-DOS and the 1990s.
//Peter
On Monday, April 07, 2014 04:55:05 PM Peter Stuge wrote:
mrnuke wrote:
Turns out that I needed to tell the EC to go into ACPI mode, as it boots up in APM mode.
Blame MS-DOS and the 1990s.
Damn you MS-DOS and the 1990s!!!
Signed, A disgruntled hardware hacker
-
mrnuke -
Peter Stuge -
Vladimir 'φ-coder/phcoder' Serbinenko