#12568 NORM Not Tri: mwifiex/8787 hang on suspend, recognized by EC 0.3.12 as needing rescue, but rescue fails to work

[Zarro Boogs per Child]

#12568: mwifiex/8787 hang on suspend, recognized by EC 0.3.12 as needing rescue,
but rescue fails to work
--------------------------+-------------------------------------------------
 Reporter:  shep          |                 Owner:  pgf                               
     Type:  defect        |                Status:  new                               
 Priority:  normal        |             Milestone:  Not Triaged                       
Component:  not assigned  |               Version:  Development source as of this date
 Keywords:                |           Next_action:  never set                         
 Verified:  0             |   Deployment_affected:                                    
Blockedby:                |              Blocking:                                    
--------------------------+-------------------------------------------------
 Testing with kernel a92e022840e7e044fc9a45003f0772314a308191 and firmware
 Q7B15 I was seeing occasional hangs while suspending (power LED never goes
 off) which seemed to be similar to the #12541 problem.   EC 0.3.12 has a
 hack to rescue the SoC from this problem by recognizing it has happened
 and whacking it with an interrupt if appropriate.   While this rescue from
 the EC included in 0.3.12 apparently works for the keyboard events
 described in #12541, I tried testing mwifiex/8787 wake-on-lan with EC
 0.3.12 and found that the hang still happens, I've seen it several times.
 The last things to appear on the EC console when it happens are:

 {{{
 233392966:ec_irq: rescuing
 233393967:ec_irq: asserting
 }}}

 but the system just sits there with the power LED remaining on.

 I wonder if there's some reason the asserted wakeup signal on the SDIO
 interface from the wireless card is blocking the interrupt from the EC.
 Is there some priority relationship between the two interrupt sources that
 can be tweaked?

 It would also be interesting to know if this same problem can be
 demonstrated with libertas/8686.

 Note, this is with a gap value of 0xff in the mwifiex/8787 host sleep
 parameters sent to the 8787 firmware.    This problem seemed to happen
 less with a gap value of 0xfa (but that adds 0.25 second delay in the
 wakeup happening), presumably because it gives the system a 0.25 head
 start in the race to get fully asleep before the wakeup condition is
 asserted.

 We could perhaps work around the race condition with a non-zero and non-
 0xff gap value, but then we'd have to decide how to tune this and would
 suffer this needless delay on every wakeup from wake-on-lan.  (Too bad the
 firmware doesn't have a parameter that only starts a timer running from
 when the host sleep parameters are sent to the firmware, and only delays
 the wakeup signal if it should come in that initial period while the host
 is going to sleep.)

 Best would be if we could make the EC rescue from #12541 that is in EC
 0.3.12 also work for the mwifiex/8787 wakeup condition too.

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