XO-1.5 wifi wakeup mechanics

[Mitch Bradley]

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.