#4616 NORM Update.: Mesh doesn't resume from suspend on reciept of multicast packets

[Zarro Boogs per Child]

#4616: Mesh doesn't resume from suspend on reciept of multicast packets
----------------------------------+-----------------------------------------
  Reporter:  gnu                  |       Owner:  cjb                              
      Type:  defect               |      Status:  new                              
  Priority:  normal               |   Milestone:  Update.1                         
 Component:  power manager (OHM)  |     Version:  Development build as of this date
Resolution:                       |    Keywords:                                   
  Verified:  0                    |  
----------------------------------+-----------------------------------------

Comment(by gnu):

 Another way to think about automatic suspends is that the system is in
 full operation, and it wants to wake up from any interrupt that comes
 along, from any source.  The suspend is just a behind-the-scenes way to
 save power.

 Now if we had an interrupt controller that was powered during suspend, and
 if our USB host controller didn't require constant DMA that doesn't work
 during suspend in order to process interrupts, and our network chip wasn't
 on the wrong side of a powered-down USB bus, then the chip could just
 signal an interrupt in the usual fashion, and the system would wake up and
 (eventually) take the interrupt.  That's the model we'd like to shoot for
 -- simple and straightforward.  (Maybe for Gen2.)

 In the meantime, the convolutions that we have to do to bypass dead
 hardware shouldn't obscure the ultimate goal, which is to make this be a
 lot like a normal interrupt.  So the kernel and the firmware could use the
 normal interrupt enables in the chip to turn various sources on and off.
 And if an interrupt should happen and it's enabled, but we're suspended,
 then tickle the system to wake up, using the special secret un-suspend
 wire.  Eventually it will come back, and turn on the USB bus, and
 enumerate the network chip, and... then... it can take the interrupt.

 Does that model work better for the firmware than the "four bits" model?
 It should handle a bunch of interruptible conditions better -- like loss
 of AP connection, and other interrupts that don't involve a packet
 arriving.

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