CAFE SD controller doesn't wake up fast enough

[PierreOssman]

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.

[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?

[jg]

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

[jg]

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

[jg]

needs testing in master.

[cjb]

Moving out to FRS.

[jg]

Correctness first, then speed...

[gnu]

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

[dwmw2]

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.

[dsaxena]

Pierre,

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.

[PierreOssman]

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.

[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.

[PierreOssman]

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