Opened 10 years ago

Closed 7 years ago

#1339 closed defect (wontfix)

CAFE SD controller doesn't wake up fast enough

Reported by: PierreOssman Owned by: wad
Priority: high Milestone: Future Release
Component: hardware Version:
Keywords: power Cc: PierreOssman, dwmw2, dsaxena, aab@…
Blocked By: Blocking:
Deployments affected: Action Needed: never set
Verified: no


There are some problems with the time it takes for the CAFE SD controller to wake up. Basically, the problem is that the driver is alive and kicking way sooner than the hardware. And so far, we haven't found anything decent to wait on.

The two observed problems are:

1 The controller reports the slot as empty and detection as stable even though a card is in there. After about 400 ms (from when the driver resumes), the controller signals "card inserted".

2 Even after this, the controller doesn't seem to have everything up and running as it should. All commands sent to the card just timeout. Redetection a bit later works fine, so the weird state isn't permanent.

Change History (19)

comment:1 Changed 10 years ago by gnu

according to IRC chat between Pierre and Mitch Bradley, Mitch's code tests different status bits than the kernel. And Mitch seemed to find situations where he got an interrupt from CAFE but it didn't show "Ready" statusbits. Busy-waiting onthe status bits worked for Mitch. Perhaps the chip interrupts too soon?

comment:2 Changed 10 years ago by jg

  • Cc PierreOssman added
  • Milestone changed from Untriaged to BTest-4
  • Owner changed from mlj to dilinger
  • Priority changed from normal to blocker

comment:3 Changed 10 years ago by jg

  • Verified unset

Awaiting merge of Pierre's & Linus' tree, and finishing USB resume.

comment:4 Changed 10 years ago by jg

  • Milestone changed from BTest-4 to Trial-2

Merge will be after B4 (currently in our Master).

comment:5 Changed 10 years ago by jg

  • Keywords power added

comment:6 Changed 10 years ago by jg

needs testing in master.

comment:7 Changed 10 years ago by jg

  • Milestone changed from Trial-2 to Trial-3

comment:8 Changed 10 years ago by jg

  • Component changed from hardware to kernel

comment:9 Changed 10 years ago by cjb

  • Milestone changed from Trial-3 to First Deployment, V1.0

Moving out to FRS.

comment:10 Changed 9 years ago by jg

  • Milestone changed from First Deployment, V1.0 to V1.1
  • Priority changed from blocker to high

Correctness first, then speed...

comment:11 Changed 9 years ago by gnu

This bug may be a pre-duplicate of #4013 (SD is toast after waking from suspend).

comment:12 Changed 9 years ago by dwmw2

  • Cc dwmw2 added
  • Component changed from kernel to hardware
  • Owner changed from dilinger to wad

This is a hardware bug -- we need at least clarity on why it lies about the card state, and when we can start to trust it again, before we try to work around it in software.

comment:13 Changed 9 years ago by dsaxena

  • Cc dsaxena added

comment:14 Changed 9 years ago by dsaxena


Do you remember any details of what you were seeing here in terms of how the card responded? Adding a msleep(400) is the short-term solution I'm going to push for #6532, but it would
be really good to root cause this and see if we can add a quirk to workaround this.

comment:15 Changed 9 years ago by Andrew Burgess

  • Cc aab@… added

comment:16 Changed 9 years ago by PierreOssman

  • Action Needed set to never set

Not more than what's in the original report. The last time this was discussed, David Woodhouse was going to ask Mitch to try to reproduce it from OFW. At that point Marvell could get a test case so that they could properly diagnose it and provide a workaround.

comment:17 Changed 9 years ago by wmb@…

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.

comment:18 Changed 8 years ago by PierreOssman

That is interesting, but unfortunately doesn't explain the problem. The driver sets those bits before checking card presence.

comment:19 Changed 7 years ago by rsmith

  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.