You already know more about this than I do, so I can't be of any help here.
On 1/13/2011 3:47 AM, Daniel Drake wrote:
Hi,
Low priortity query...
I'm investigating the possibility of implementing _SWS (system wakeup
source) support in the XO-1.5 DSDT, along with _SWS support in Linux.
This seems like the most likely way to get XO-1.5 wakeup source
detection upstream.
I haven't fully wrapped my head around this part of the ACPI specs,
but from what I gather, it can only represent wakeup sources that
cause a bit in the PM1 or GPE0 status register to be set (with their
trigger as a wakeup source being in the PM1/GPE0 enable registers).
The ACPI specs seem to suggest that there should be no other way of
waking up the system.
On the XO-1.5, the FADT maps these registers to the following
registers, as documented in VX855 System Programming Manual Revision
1.0 (PM_VX855_VX875_100.pdf):
PM1 status mapped to PMIO 0x00 (page 281, Power Management Status)
PM1 enable mapped to PMIO 0x02 (page 281, Power Management Enable)
GPE0 status mapped to PMIO 0x20 (page 284, General Purpose Status)
GPE0 enable mapped to PMIO 0x22 (page 285, General Purpose SCI /
RESUME Enable)
All of our wakeup sources can be easily mapped to bits in those registers:
PM1: RTC, power button
GPE: ebook, lid, HDA, USB, and all EC-based wakeups
The one missing is wifi wakeups.
Currently, olpc-pm-1.5 detects wifi wakeups by reading PCI config
offset 0x84 of the SDHCI controller (Power Management Control and
Status, page 159). The documentation of this register links SDHCI
wakeups to PME events, and this is how it works on the Linux driver
level too.
Bit 5 in the GPE0 registers corresponds to PME wakeups, so I'm
thinking that we can use the GPE registers to detect this, meaning
that wifi (well, PCI) wakeups then fall within the realms of ACPI
wakeup sources.
By doing:
echo PCI0 /proc/acpi/wakeup
I can get ACPI to set bit 5 during suspend (e.g. its currently writing
0x826, enabling GP1, keyboard, lid, PME). However, on wifi-wakeup,
GPE0 status reads 0x8000, so my experiment has failed - the register
doesnt report that the wakeup happened because of a PME.
That leaves 2 questions:
1. Is there anything special about wifi wakeup, or is it just a regular PCI
PME?
2. Why does VX855 wake up on PME even when it is not enabled in GPE0
enable, and when its enabled there why doesn't it report the status?
(probably a question for VIA...)
cheers
Daniel
p.s. understanding would be nice, but even if this remains unknown, I
think we can still use _SWS.
_SWS can examine the SDHCI controller config space, and if wifi is
determined to be the wakeup reason, it can say that GPE5 was the
wakeup reason, even if thats not entirely true. Linux already knows
that GPE5 is PCI0.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
