#1339 HIGH Future : CAFE SD controller doesn't wake up fast enough

[Zarro Boogs per Child]

#1339: CAFE SD controller doesn't wake up fast enough
----------------------------+-----------------------------------------------
   Reporter:  PierreOssman  |       Owner:  wad           
       Type:  defect        |      Status:  new           
   Priority:  high          |   Milestone:  Future Release
  Component:  hardware      |     Version:                
 Resolution:                |    Keywords:  power         
Next_action:  never set     |    Verified:  0             
  Blockedby:                |    Blocking:                
----------------------------+-----------------------------------------------

Comment(by wmb at firmworks.com):

 I discovered something that is probably related.

 In the CaFe SDHCI, the bit that reports card presence (bit 0 of register
 0x26) will not change state unless bits 6 and 7 of register 0x34 are set.
 Specifically, if 0x34/6 is clear, 0x26/0 will not change state from 0 to
 1, and if 0x34/7 is clear, 0x26/1 will not change state from 1 to 0.

 The 0x34/6 and 0x34/7 bits are supposed to control card insertion and
 removal interrupts.  I don't think they are supposed to affect the
 presence detect register.
 I believe that this behavior constitutes a bug in the CaFe chip design, a
 misinterpretation of the "Simplified SD Host Controller" specification
 (which is somewhat vague and poorly written, so it's not too surprising
 that someone would misinterpret it).  However, it seems unlikely that we
 will get a chip spin to correct the problem.

 If the Linux driver is testing 0x26/0 before setting the interrupt enables
 in register 0x34, the driver wouldn't see the card.  The 400 ms delay
 could be explained if, after some time delay, the driver goes through a
 deeper reinitialization and thus sets those interrupt enables.  (That is
 indeed the way the Windows XP driver works, so this scenario is at least
 plausible.)  I haven't traced the Linux SD driver in detail, so I'm not
 sure that this is what's happening.

 I have a firmware workaround that might be useful.  In a new version of
 OFW's resume-from-S3 code, I preset 0x34/6 and 0x34/7 before passing
 control back to the OS (which isn't quite as easy as it sounds because you
 have set up several other chip registers before the 0x34 setting will
 "take").  That fixes the wakeup problem with the Windows XP driver.  The
 first version of OFW that has this fix is q2e11x (unreleased).  The fix
 will probably be released in q2e12.

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