#12490 HIGH 13.1.0: Fix XO-4 8686 wake-on-WLAN

[Zarro Boogs per Child]

#12490: Fix XO-4 8686 wake-on-WLAN
---------------------------------+------------------------------------------
           Reporter:  dsd        |       Owner:  pgf          
               Type:  defect     |      Status:  new          
           Priority:  high       |   Milestone:  13.1.0       
          Component:  kernel     |     Version:  not specified
         Resolution:             |    Keywords:               
        Next_action:  never set  |    Verified:  0            
Deployment_affected:             |   Blockedby:               
           Blocking:             |  
---------------------------------+------------------------------------------

Comment(by pgf):

 i installed a libertas module in my B1, os26, EC 3.0.9 -- without
 exception, w-o-l will cause the machine to hang on resume.

 i put a scope on it, and i don't see anything very wrong.  at wakeup time,
 the libertas one-wire-mode line (SoC gpio 39) drops, and stays low.
 EC_IRQ drops roughly 25ms later, as expected, trying to wake the SoC.  (i
 didn't scope SOC_SLEEP, but given the timing between the wlan wake signal
 and EC_IRQ, i'm confident SOC_SLEEP did its usual thing.)

 i tried giving sdhci-pxav3.c an interrupt handler for the wakeup signal
 (it's currently just configured as a wakeup, not as an interrupt), but
 that kind of blew up in my face with lots of mmc errors -- i'm not sure
 what i did wrong -- so i beat a hasty retreat.  i think that's worth
 trying, though, since marvell claims we need to have the gpio interrupt
 enabled in order for a wakeup to complete. (in order to take the interrupt
 i was expecting to take, we might need to switch the pin function to gpio
 during suspend. i don't think that's happening now -- if all we needed was
 the pin wakeup, we shouldn't need to change the pin's role.)  otoh, i'd
 think our EC_IRQ fallback would save the day.  but no one fully
 understands all this yet.

 curious, i tried my libertas-equipped C1, again with os26.

 it's better, but not great.  here's a typical sequence:

 {{{
     bash-4.2#
     bash-4.2# ethtool -s eth0 wol um
     bash-4.2# rtcwake -s66 -mmem
     rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:04:23 1970
     [  154.046579] PM: Syncing filesystems ... done.
     [  154.053522] Freezing user space processes ... (elapsed 0.02
 seconds) done.
     [  154.079467] Freezing remaining freezable tasks ... (elapsed 0.01
 seconds) done.
     [  154.102052] Suspending console(s) (use no_console_suspend to debug)
     [  154.117522] dcon_source_switch to DCON
     [  154.155459] olpc-dcon: The DCON has control
     [  154.219640] mmp3_usb_phy_deinit_internal: Deinit usb phy!!!
     [  154.259486] mmc2: configuring for no WOL wakeups: c1
     [  154.259524] mmc1: configuring for no WOL wakeups: c1
     [  154.260571] libertas_sdio mmc0:0001:1: mmc0:0001:1: suspend: PM
 flags = 0x3
     [  154.261706] mmc0: keeping power over suspend
     [  154.261733] mmc0: setting up for WOL wakeups: 40a1
     [  154.261807] PM: suspend of devices complete after 159.680 msecs
     [  154.261939] PM: late suspend of devices complete after 0.124 msecs
     [  154.262200] PM: noirq suspend of devices complete after 0.001 msecs
     [  154.262298] mmp3_pm_enter_d2
     [  154.262332] mmp3_pm_enter_d2 1
     [  154.262336] mmp3_pm_enter_d2 2
     [  154.262336] mmp3_pm_enter_d2 3
     [  154.262338] mmp3_pm_enter_d2 5
     [  154.262343] before suspend
 ...suspend happens here and we wait, but then (presumably) a packet
 arrives...
     [  154.263907] mmp3_pm_enter_d2 10
     [  154.281959] after resume
     [  154.282768] PM: noirq resume of devices complete after 0.110 msecs
     [  154.282854] ec_irq
     [  154.283004] PM: early resume of devices complete after 0.012 msecs
     [  154.285518] ec_irq
 ...note 10 second delay and timeout here...
     [  164.299277] mmc0: Timeout waiting for hardware interrupt.
     [  164.299314] libertas_sdio: problem fetching packet from firmware
     [  164.299748] libertas_sdio mmc0:0001:1: mmc0:0001:1: resume: we're
 back
     [  164.439209] mmp3_usb_phy_init_internal: Init usb phy!!!
     [  164.460060] dcon_source_switch to CPU
     [  164.486809] olpc-dcon: The CPU has control
     [  164.659161] usb 1-1: reset high-speed USB device number 2 using
 pxau2o-ehci
     [  164.920334] PM: resume of devices complete after 10637.257 msecs
     [  165.060919] Restarting tasks ... done.
     bash-4.2#

 }}}

 it always seems to wake, but it's never happy when it does.  there are a
 couple of variations on the error, but they both involve a missed
 interrupt.

-- 
Ticket URL: <http://dev.laptop.org/ticket/12490#comment:1>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system