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